DMARCレコードジェネレーター

DMARCがSPFとDKIMに加えるもの

SPFとDKIMはそれぞれ何かを検証しますが、検証に失敗したときの扱いは示さず、利用者が実際に目にする From 行のアドレスとも結びついていません。DMARCはその両方を補います。受信側に対し、SPFまたはDKIMが From アドレスと同じドメインで成功した場合にのみ、そのドメインからのメールとして受け入れること、そして成功しなかったメールをどう扱うかを伝えます。さらに受信側からのレポート送信を求めるため、お客様のドメインを名乗って送信している送信元が分かります。

ジェネレーターで設定できるすべてのタグ

段階的に導入

よくある間違いは、初日から p=reject を公開し、請求書がバウンスして初めて、忘れていたシステムが自社を名乗って送信していたと気づくことです。安全な進め方は、まず監視から始め、レポートに問題がなくなってから厳格化することです。

• p=none を公開し、rua には実際に確認するメールボックスかレポートサービスのアドレスを指定します。
• その後の数週間、レポートに表示されるすべての送信元を洗い出します。正当なものはSPFまたはDKIMを修正します。見覚えのないものは、なりすましか、忘れられたシステムの可能性があります。
• 小さな pct で quarantine に移行し、レポートに問題がない間は段階的に引き上げます。
• 正当な送信元がすべて成功するようになったら reject に移行し、その後もレポートを確認し続けます。

ジェネレーター下の段階表では、各ステップをコピーできるレコードとして確認できます。

アライメントを平易な言葉で

DMARCは、SPFまたはDKIMが成功し、成功したドメインが From ドメインと一致した場合にパスします。relaxed アライメントではサブドメインも一致とみなされ、mail.example.com からのメールは From が example.com でもアライメントされます。strict アライメントではドメインが完全に同一でなければなりません。strict は、すべての送信元を管理していて最も厳しいルールを望む場合にのみ有効です。サブドメインを使うサードパーティサービスからの正当なメールが失敗することもあります。

別のドメインへのレポート送信

rua のアドレスが、保護対象とは別のドメイン(レポートサービスなど)にある場合、受信側は、そのドメインがレポートの受信に同意しているかを確認します。同意は、yourdomain._report._dmarc.otherdomain に値 v=DMARC1 のTXTレコードを公開することで示されます。通常はレポートサービスが設定してくれます。該当する場合は、ジェネレーターがお知らせします。

集計レポートはXML形式

毎日届く rua レポートは、受信側ごとに1つの圧縮XMLファイルで、送信IP、メッセージ数、SPFとDKIMの結果が記載されています。1日に数件を超えると、手作業で読むのは困難です。多くの方はレポートサービスやスクリプトで表にまとめています。どの方法でも、特に新しい送信サービスを追加した後は、定期的に確認してください。

公開場所

ドメインに _dmarc という名前のTXTレコードを作成し(フルネームは _dmarc.example.com)、生成された値を貼り付けます。DMARCレコードは必ず1つだけにしてください。DNSの反映後、当社のSPF・DKIM・DMARCチェッカーでドメインを確認し、意図どおりに読み取られているか確かめましょう。