DKIM、SPF、DMARC：設定完全ガイド

要点

1. なぜ3つのレコードが必要か。 SPF、DKIM、DMARC は、それぞれ異なる問いに答えます。
2. SPF：送信を許可する送信元を列挙する。 SPF は、ドメインのメールの送信を許可するサーバーを列挙する、ドメイン上の TXT レコードです。
3. DKIM：すべてのメッセージに署名する。 DKIM は、各メッセージに暗号化署名を付与します。
4. DMARC：ポリシーを設定する。 DMARC は、他の2つを結び付けます。
5. アライメントをわかりやすく説明すると。 DMARC は、SPF または DKIM のどちらかが通過し、かつ検証対象のドメインが From アドレスのドメインと一致している場合に通過します。
6. 検証とモニタリング。 自分で管理しているメールボックスにテストメッセージを送り、受信したメールのヘッダーにある認証結果を読みます。

なぜ3つのレコードが必要か

SPF、DKIM、DMARC は、それぞれ異なる問いに答えます。SPF は、送信サーバーがそのドメインとして送信を許可されているかを確認します。DKIM は、メッセージがそのドメインによって署名され、配送中に改ざんされていないかを確認します。DMARC は、これらのチェックに失敗した場合に受信側がどう扱うべきかを定め、その結果を送信者に知らせます。

現在のメールボックスプロバイダーは、特に大量送信者に対して3つすべてを求めています。これらを公開することは、フィッシングによる自社ドメインの偽装を防ぐことにもなります。

SPF：送信を許可する送信元を列挙する

SPF は、ドメインのメールの送信を許可するサーバーを列挙する、ドメイン上の TXT レコードです。SPF レコードはドメインごとに1つだけ公開し、その中に MigoSMTP のダッシュボードに表示される値を include してください。末尾の ~all は、それ以外の送信元を疑わしいものとして扱うことを示します。正規の送信元がすべて列挙されていると確信できた段階で、-all に移行するチームもあります。

v=spf1 include:YOUR_SPF_HOST ~all

レコードの DNS ルックアップ数は10回未満に収めてください。include はすべて上限にカウントされるため、使わなくなったプロバイダーは削除しましょう。1つのドメインに SPF レコードを2つ公開するとエラーになり、SPF は失敗します。

DKIM：すべてのメッセージに署名する

DKIM は、各メッセージに暗号化署名を付与します。受信側は、セレクター名のもとで DNS に公開された公開鍵を使って、その署名を検証します。MigoSMTP が追加すべき正確なレコードを提示します。通常は、1つ以上の CNAME または TXT レコードです。

SELECTOR._domainkey.example.com  CNAME  YOUR_DKIM_TARGET

ダッシュボードに表示されたとおりにレコードを追加し、その後で検証してください。送信サービスごとに別々のセレクターを使うと、他に影響を与えずに、1つだけをローテーションしたり削除したりできます。

DMARC：ポリシーを設定する

DMARC は、他の2つを結び付けます。メッセージが、表示される From ドメインとの SPF と DKIM のアライメントの両方に失敗した場合に、受信側がどう扱うべきか、そしてその結果をどこにレポートするかを指定します。

_dmarc.example.com  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

レポートを有効にした p=none から始め、レポートを読んですべての正規の送信元を洗い出し、不足を修正してから、quarantine、最後に reject へと進みます。いきなり reject にすると、自社の正規のメールをブロックしてしまうことがあります。

アライメントをわかりやすく説明すると

DMARC は、SPF または DKIM のどちらかが通過し、かつ検証対象のドメインが From アドレスのドメインと一致している場合に通過します。DKIM の場合、対象は署名に含まれるドメインです。SPF の場合は、From アドレスではなくエンベロープ送信者のドメインです。

このため、共有ドメインに頼るよりも、自社ドメインから送信し、そのドメインで DKIM 署名を行うほうが堅牢です。SPF と DKIM が通過しているのに DMARC のチェックが失敗する場合、たいていの原因はアライメントです。

検証とモニタリング

自分で管理しているメールボックスにテストメッセージを送り、受信したメールのヘッダーにある認証結果を読みます。spf=pass、dkim=pass、dmarc=pass と表示されるはずです。レコードを直接照会して確認することもできます。

dig +short TXT example.com
dig +short TXT _dmarc.example.com
dig +short CNAME SELECTOR._domainkey.example.com

モニタリングは継続してください。他のツールのために行った DNS の変更が、気づかないうちにレコードを壊すことがあり、新しい送信元も時間とともに増えていきます。DMARC レポートは定期的に確認しましょう。

よくある間違い

SPF レコードを2つ公開する、DNS ルックアップが10回を超える、DMARC レコードを誤ったホスト名に追加する、DNS プロバイダーが長い TXT 値を分割・改変してしまう、メールを送信するサブドメインを見落とす、といったミスがあります。

検証に失敗した場合は、そのドメインで認証チェッカーを実行して、インターネット上の他の相手からどう見えているかを確認し、DNS の変更が反映されるのを待ってから再試行してください。

参考資料と出典

• RFC 7208：Sender Policy Framework (SPF)
• RFC 6376：DomainKeys Identified Mail (DKIM) Signatures
• RFC 7489：DMARC
• Google：メール送信者のガイドライン

MigoSMTP での設定方法：ヘルプセンターの記事

• MigoSMTP で送信ドメインを認証する：SPF、DKIM、DMARC
• DKIM 鍵のローテーション、セレクター、鍵長
• 送信ドメインの検証：DNS レコードと反映

関連ガイドとツール

• ウォームアップガイド：新しい IP を安全に立ち上げます。
• 受信プロバイダーガイド：各プロバイダーが確認する項目を解説します。
• DMARC ジェネレーター：レコードを作成します。