レコードは DMARC オーナー名に置く必要があります
example.com の場合、受信側は _dmarc.example.com を照会します。ルートドメインや任意のホストにある v=DMARC1 文字列は、そのドメインの DMARC ポリシーにはなりません。
適用される DMARC レコードは 1 件だけ返すべきです。重複や不正なポリシーは、多層防御ではなく不確実性を生みます。
任意のドメインを入力して、DMARC レコードを取得・分析します。適用ポリシー、アライメント設定、レポート送信先、設定状況を確認できます。
DMARC(Domain-based Message Authentication, Reporting and Conformance)は、DNS に公開するメール認証ポリシーです。受信メールサーバーに対し、SPF と DKIM の検査が失敗した場合の扱いを指示し、ドメイン上の認証活動に関するレポートを返送するよう求めます。DMARC はメール認証の要であり、SPF と DKIM を一貫したポリシーにまとめます。
DMARC レコードは、サブドメイン _dmarc.yourdomain.com に TXT レコードとして公開します。最も重要なタグはポリシーを定める p= です。none は何もしない(監視モード)、quarantine は失敗したメッセージを迷惑メールへ送り、reject は完全に拒否します。多くのドメインは none から始め、正当な送信元がすべて正しく認証されていることを確認したうえで、段階的に reject へ移行します。
DMARC のレポート機能は特に価値があります。rua(集計レポート用の報告 URI)アドレスを含めると、Gmail、Outlook、Yahoo などの主要 ISP が、ドメインを名乗ってメールを送ったすべての IP を示す日次 XML レポートを送信します。これらのレポートにより、不正な送信元の特定、設定不備のあるサービスの発見、認証状態の継続的な監視が可能になります。
中核となる適用ポリシーです。none、quarantine、reject のいずれかを指定します。
サブドメイン向けのポリシーです。未設定の場合は p= を継承します。
ポリシーを適用するメッセージの割合です。デフォルトは 100 です。
日次の集計レポートを受け取るメールアドレスまたは URI です。
メッセージのサンプル付き失敗レポートを受け取るメールアドレスです。
r=relaxed(デフォルト)、s=strict。strict はドメインの完全一致を要求します。
r=relaxed(デフォルト)、s=strict。strict はエンベロープ From の完全一致を要求します。
フォレンジックレポートを送る条件です。0=両方失敗(デフォルト)、1=いずれか失敗、d=DKIM 失敗、s=SPF 失敗。
公開ポリシーの根拠
チェッカーは公開 TXT ポリシーを取得し、タグを解析して、アライメント済み認証に失敗したメールに対して受信側へ求める対応を表示します。
example.com の場合、受信側は _dmarc.example.com を照会します。ルートドメインや任意のホストにある v=DMARC1 文字列は、そのドメインの DMARC ポリシーにはなりません。
適用される DMARC レコードは 1 件だけ返すべきです。重複や不正なポリシーは、多層防御ではなく不確実性を生みます。
DMARC は、認証済みの SPF または DKIM 識別子が表示上の From ドメインと揃ったときに合格します。チェッカーは p=、adkim、aspf を読めますが、提供されていないメッセージの Authentication-Results は見えません。
公開レコードをドメインの指示として使い、実際のメールをテストして、各送信元がそれを満たせるかを確認してください。
ポリシーの読み方
各結果は設定を示します。適用とレポートは受信側と、実際のメッセージの認証に依存します。
SPF と DKIM は存在する場合がありますが、受信側はこのオーナー名からの DMARC 指示も、このポリシー向けの集計レポート送信先も持っていません。
正当な送信元を洗い出している間は有用な集計レポートを得られますが、アライメント済み認証の失敗に対する隔離や拒否は求めません。
より強いポリシーを健全と呼ぶ前に、重要なトランザクション、ワークスペース、マーケティング、サポート、ベンダーの各ストリームが、アライメント済みの SPF または DKIM を通過することを確認してください。
sp タグでサブドメイン向けポリシーを指定できます。ない場合、組織ドメインのポリシーの適用方法は DMARC のポリシー発見ルールが決めるため、メッセージが使う正確な From ドメインを確認してください。
監査の手順
適用を変更する前に、DNS ポリシーをレポートとメッセージヘッダーにつなげてください。
From ヘッダーの @ の後に表示されるドメインを入力してください。サブドメインの場合は正確な名前を確認し、直接ポリシーか継承ポリシーのどちらが適用されるかを把握してください。
すべてのタグが意図した導入計画を反映していること、rua または ruf アドレスが管理下にあり、必要な場合は認可済みで、レポートを安全に処理できることを確認してください。
SPF チェッカー と DKIM チェッカー を使い、識別子を実際のヘッダー内の表示上の From ドメインと比較してください。
設定の見直しが必要なときは、DMARC レコードジェネレーター を使い、更新した TXT レコードを 1 件公開し、TTL を待ってから再確認してください。
照会では証明できないこと
DNS ポリシーは必要な根拠ですが、運用上の準拠とは同じではありません。
稼働中の送信元 IP、失敗件数、未知のベンダー、なりすましのパターンは特定できません。それらの事実は、参加している受信側が送る rua レポートにあります。
DMARC はドメイン所有者のポリシーを公開します。各受信側は依然としてローカルの配信・フィルタ判断を適用し、要求されたレポートをすべて送るとは限りません。
メッセージ単位の調査には、From ドメイン、リターンパス、DKIM 署名、Authentication-Results、関連する Received ヘッダーが必要です。
DMARC は送信元ドメインを認証します。宛先メールボックスが到達可能かを評価するには、メール検証 を使ってください。
プロトコル参照
ダッシュボードのラベルがアライメント、発見、レポートの詳細を隠しているときは、仕様を参照してください。
IETF の RFC 7489 は、ポリシー発見、アライメント済み識別子、組織ドメイン、受信側の処理、フィードバックレポートを定義します。
SPF の認可、DKIM 鍵の公開、DMARC ポリシー、実際のメッセージヘッダー、集計レポートを確認してください。単一の DNS 結果が他の層に取って代わることはありません。
次のツールは、証拠の種類で選んでください。受信者、発見、DNS とインフラ、送信者ワークフローです。
無料ツール
ポリシー、アライメント、レポート設定を含む DMARC の DNS TXT レコードを作成します。ドメインのメール認証向け無料ジェネレーターです。
ドメインまたはインフラの証拠であり、メールボックスの証明ではありません。
無料ツール
任意のドメインの SPF レコードを確認・検証します。レコード全文、各メカニズムの内訳、設定が正しいかを表示します。無料、登録不要。
ドメインまたはインフラの証拠であり、メールボックスの証明ではありません。
無料ツール
任意のドメインとセレクターの DKIM レコードを確認。公開鍵の全文と、DKIM 署名が正しく設定されているかを表示します。無料、登録不要。
ドメインまたはインフラの証拠であり、メールボックスの証明ではありません。
無料ツール
任意のドメインの A、AAAA、MX、TXT、NS、CNAME レコードを確認できます。ライブ DNS 照会で即座に結果を表示します。無料、登録不要です。
ドメインまたはインフラの証拠であり、メールボックスの証明ではありません。
メールツール
生のメールヘッダーを貼り付けて構造化分析: SPF、DKIM、DMARC 結果、配送経路、スパムスコア、主要メタデータ。無料、登録不要。
送信者またはメッセージの診断であり、アドレス発見ではありません。
メールツール
実際のメッセージサンプルでメール到達性テストを実行。SPF、DKIM、DMARC、DNS、ブラックリスト、スパムフィルター、ヘッダー、コンテンツ根拠を確認します。
送信者またはメッセージの診断であり、アドレス発見ではありません。
DMARC レコードがない場合、DMARC ポリシーは存在せず、受信サーバーは DMARC に基づく適用を行いません。つまり、ドメインを名乗ったなりすましメールは、SPF と DKIM 以外の追加の障壁に直面しません。Google と Yahoo は現在、大量送信者に対して DMARC レコード(p=none でも可)を求めています。メールを送信するすべてのドメインは、少なくとも監視用の DMARC レコードを公開すべきです。
p=none は DMARC が監視モードであることを意味します。レポートは収集しますが、失敗したメッセージには何もしません。p=quarantine は受信サーバーに対し、失敗したメッセージを迷惑メールフォルダへ届けるよう指示します。p=reject は失敗したメッセージを受信トレイに届く前に完全にブロックします。none から始め、2〜4 週間レポートを確認したうえで、quarantine、reject へと進めてください。
アライメントとは、SPF または DKIM を通過したドメインが、表示上の From ヘッダーのドメインと一致する必要があることを意味します。緩和アライメントではサブドメインの一致を認めます。mail.example.com は example.com と揃います。厳格アライメントは完全一致を求めます。転送や ESP 送信メールを壊さないよう、ほとんどの構成では緩和を使ってください。
DMARC レコードに rua メールアドレスを含めると、主要 ISP が日次の XML レポートを送信します。各レポートには、どの IP がドメインからメールを送ったか、それぞれ何通送ったか、SPF と DKIM が合格したか失敗したかが含まれます。これらのレポートを使い、認証設定が必要な正当な送信元を見つけ、なりすましの試みを検知してください。
sp= タグを設定しない限り、メインドメインの DMARC ポリシーがサブドメインにも適用されます。サブドメインを保護したい場合は、DMARC レコードに sp=reject または sp=quarantine を追加してください。sp= がない場合、サブドメインは緩和アライメントのもとで p= ポリシーを継承します。
はい。pct=25 に設定すると、DMARC ポリシーは失敗したメッセージの 25% にのみ適用されます。段階的な導入に役立ちます。正当なメールの設定不備による影響を抑えるため、quarantine や reject を初めて有効にするときは 10% または 25% から始めてください。正当なメールが失敗していないことを確認したら、100 まで引き上げてください。