独自ドメインでメールサーバを運用する際、DMARC対応が必須な世の中になってきましたので、改めてDMARC対応のやり方をまとめておきます。昔は自力でsendmail / postfix などでメールサーバを運用していたこともありますが、今回はGoogle Workspace (Gmail)とMicrosoft 365 (Outlook)で独自ドメインなメールサーバのDMARC対応をする方法を書いています。
DMARC対応の基本
DMARC対応するには、同時にSPFとDKIMも対応する必要があります。迷惑メール対策はSPF/DKIM/DMARCの3点セットで行うわけです。
SPF対応
SPF (Sender Policy Framework)は、独自ドメインのメールを送信する正規メールサーバをDNSに登録することで、偽のメールサーバから送られる迷惑メールを判別する仕組みです。具体的には、ドメイン名（例：foo.bar）のTXTフィールドに、SPFレコードとして "v=spf1 include:spf.foo.bar ~all"のような値を追加します。
SPFレコードの書式の詳細はSPF レコードについてをご参照ください。
DKIM対応
DKIM (DomainKeys Identified Mail)は、個々のメールが正規なメールサーバから送られたものかどうかを、証明書を用いて検証する仕組みです。具体的には、メールサーバで生成した証明書（鍵ペア）のうち、公開鍵を特定のホスト名（例：zzz._domainkey.foo.bar）のTXTフィールドに、DKIMレコードとして"v=DKIM1;k=rsa;p=xxxxxxxxxxxxxxxxxx" （xxx..の部分が公開鍵）のような値を追加します。ホスト名のうち、zzzの部分は「セレクタ名」と呼ばれるもので、メールサーバ側で決められています。例えばGoogle Workspace (Gmail) では、google._domainkey.foo.bar のホスト名が使われます。
DKIMレコードは上述の通り、TXTフィールドに公開鍵を書くことがRFC 6376で決められていますが、TXTフィールドではなく、CNAMEフィールドに参照するホスト名を書くケースがあります。独自ドメインのDNSに公開鍵を直接書かないことで、メールサーバ側に閉じて鍵ペアの運用（定期的な更新など）ができるという利点があるからでしょう。例えばMicrosoft 365 (Outlook)では、selector1._domainkey.foo.bar のCNAMEに selector1-foo-bar._dmainkey.foo.bar という値（ホスト名）を書きます。
DMARC対応
DMARC (Domain-based Message Authentication, Reporting, and Conformance)は、SPF / DKIM で認証に失敗したメールを、受信メールサーバ側でどのように取り扱ってほしいかをポリシーとして表明する仕組みです。例えば、認証に失敗した（多くは偽のメールサーバから送られた迷惑メール）に対して、受信サーバ側で「迷惑メール」として扱ってほしい場合は、「隔離（quarantine）」というポリシーを書きます。具体的には、ドメイン名の決められたホスト名（_dmarc.foo.bar）のTXTフィールドに、DMARCレコードとして "v=DMARC1; p=quarantine;rua=mailto:postmaster@foo.bar;pct=100;adkim=s;aspf=s"のような値を追加します。
メールサーバ毎の設定方法
DMARCが普及しだした頃には、具体的な設定方法に関する情報が少なく、試行錯誤が必要でした。最近ではクラウドサービスでの設定に関するドキュメントが充実してきましたので、仕組みさえ分かればあまり間違えずに設定できるようになりました。
Google Workspace (Gmail)での設定
Google Workspace での SPF / DKIM / DMARC の設定方法は、それぞれ次のドキュメントが用意されています。
- [SPF] SPFを設定する
- [DKIM] DKIMを設定する
- [DMARC] DMARCを設定する
Microsoft 365 (Outlook)の設定
Microsoft 365 での SPF / DKIM / DMARC の設定方法は、それぞれ次のドキュメントが用意されています。