DMARC 設定
DMARC 設定ページでは、ドメインの DMARC ポリシー、レポート、アライメントを構成できます。
検証状況
ページ上部のステータスインジケーターには、ドメインの DMARC DNS 委任レコードの現在の検証状態と、最終確認日が表示されます。確認 をクリックするとレコードをすぐに再確認できます。また セットアップ手順 をクリックすると、公開する必要がある DNS レコードを確認できます。
注: ドメインが部分的にのみ検証されている場合、変更を保存すると、DMARC レコードが完全に委任され検証されるまで変更は反映されないという警告が表示されます。部分的に検証されたドメインでは、DMARC 集約レポートのみが処理されます。
Raw DMARC レコードを表示 をクリックすると、以下のポリシーと設定に基づいて現在構成されている生の DMARC DNS レコードを確認できます。
一部のフィールドには 新しい DMARCbis または レガシー のタグが付いています。
注: DMARCbis は更新された DMARC 仕様です。新しい DMARCbis のタグが付いたフィールドは、元の DMARC 標準には含まれておらず、すべてのメールボックスプロバイダーでまだ完全に対応されていない可能性があるタグを公開します。レガシー のタグが付いたフィールドは、DMARCbis で段階的に廃止されているタグを公開します。後方互換性のために引き続き公開されますが、今後は DMARCbis での代替を優先することをお勧めします。
ポリシー設定
DMARC ポリシー
p= タグを公開します。これは、ドメインからの DMARC に失敗したメールに適用されるポリシーです。
| ポリシー | 説明 |
|---|---|
| None | アクションを取らずにメールを監視します。レポートが送信されますが、メッセージはブロックやフィルタリングされません。 |
| Quarantine | 疑わしいメールをマークしてスパムまたは迷惑メールフォルダに配信します。 |
| Reject | DMARC に失敗したメールは完全にブロックされ、配信されません。 |
サブドメインポリシー
sp= タグを公開します。これは、ドメインのサブドメインからのメールに適用される DMARC ポリシーです。継承 に設定すると、サブドメインは親ドメインと同じポリシーを使用します(sp= タグは公開されません)。上書きするには None、Quarantine、Reject のいずれかを選択します。
存在しないサブドメインの DMARC ポリシー
np= タグを公開します。これは、DNS に存在しないサブドメインからのものと称するメールに適用されるポリシーです。継承 に設定すると、サブドメインポリシーと同じポリシーが使用されます(np= タグは公開されません)。上書きするには None、Quarantine、Reject のいずれかを選択します。
新しい DMARCbis:
npタグは DMARCbis 以前には存在しませんでした。一部のメール受信者はまだ対応していない可能性があります。
テストモード
t= タグを公開し、y(テストモード有効)または n(無効)に設定します。有効な間、メールボックスプロバイダーは、ポリシーが公開されていても、あくまで参考情報として扱い、アクションを取らないよう求められます。より厳格なポリシーを適用する前に試験的に運用する際に便利です。
新しい DMARCbis:
tタグは DMARCbis 以前には存在しませんでした。一部のメール受信者はまだ対応していない可能性があります。DMARCbis では、ポリシーを試験的に運用する際に、割合を減らすのではなくテストモードを使用することを推奨しています。
パーセンテージ
pct= タグを公開します。これは、受信サーバーが DMARC ポリシーを適用するメールのパーセンテージです。その他すべてのメールには、次に低い DMARC ポリシーが適用されます(例:公開されているポリシーが Reject で、パーセンテージが 30% の場合、残りの 70% には Quarantine が適用されます)。
レガシー:
pctタグは DMARCbis においてテストモードに取って代わられ、段階的に廃止されていますが、後方互換性のために設定されている場合は引き続き公開されます。
集約レポート
レポート間隔
ri= タグを公開します。これは、受信サーバーが集約レポートを送信する頻度です。
レガシー:
riタグは DMARCbis で段階的に廃止されています。ほとんどのプロバイダは、この設定に関係なく 24 時間ごとにレポートを送信します。
レポートの送信先
rua= タグを公開します。これは、生の DMARC 集約レポートを受け取るべきメールアドレスです。
注: 集約レポートは、ここで追加したメールアドレスに加えて、プラットフォームが処理できるよう、常に DMARC Manager の一意のレポートアドレスにも送信されます。
失敗レポート
ruf= タグを公開するかどうか、また誰が失敗レポートを受け取るかを制御します。
| オプション | 説明 |
|---|---|
| 無効 | DMARC Manager による失敗レポート処理は無効になっています。ruf= タグは公開されません。 |
| 有効 | 失敗レポート処理が有効です。ruf= は DMARC Manager を指定して公開されます。 |
| 特定の送信先 | ruf= は DMARC Manager プラットフォーム以外の特定の送信先を指定して公開されます。 |
注: 無効から有効に切り替えると、失敗レポートにはメールアドレスやメッセージ内容などの個人情報が含まれる可能性があることを説明する確認ダイアログが表示されます。組織の法的ポリシーによりこれを有効にできない場合は、代わりに特定の受信者を選択し、レポートを手動で処理してください。
注: 特定の受信者を選択すると、DMARC Manager はこのドメインの失敗レポートを取得できなくなります。
レポートオプション
fo= タグを公開します。これは、失敗レポートが生成される条件です。
| オプション | 説明 |
|---|---|
| SPF または DKIM が失敗して、アライメントしない | SPF または DKIM が失敗してアライメントしない場合にレポートを生成します。 |
| SPF と DKIM が失敗して、アライメントしない | SPF と DKIM の両方が失敗してアライメントしない場合にレポートを生成します。 |
| DKIM がアライメントに関係なく失敗する | DKIM がどの理由で失敗した場合でもレポートを生成します。 |
| SPF がアライメントに関係なく失敗する | SPF がどの理由で失敗した場合でもレポートを生成します。 |
アライメント設定
DKIM アライメントモード
adkim= タグを公開します。これは、DKIM がアライメントしていると見なされるために、DKIM ドメインがドメインとどの程度厳密に一致する必要があるかを示します。
| モード | 説明 |
|---|---|
| 柔軟 (Relaxed) | サブドメインマッチを許可します(例:mail.example.com は example.com とアライメントします)。 |
| 厳格(Strict) | 正確なドメインマッチが必要です。 |
SPF アライメントモード
aspf= タグを公開します。これは、SPF がアライメントしていると見なされるために、SPF ドメインがドメインとどの程度厳密に一致する必要があるかを示します。
| モード | 説明 |
|---|---|
| 柔軟 (Relaxed) | サブドメインマッチを許可します(例:mail.example.com は example.com とアライメントします)。 |
| 厳格(Strict) | 正確なドメインマッチが必要です。 |
関連トピック
- DMARC とは何か?: DMARC とその目的の紹介
- DMARC はどのように機能するのか?: DMARC の運用に関する技術的詳細
- DMARC が重要な理由: DMARC の利点と重要性
- DMARC の制限事項: 現在の制約と課題
- DMARC 構文: DMARC DNS レコードフィールドに関する詳細情報
- DMARC レポート: DMARC レポート、頻度、制限事項の紹介