SPF・DKIM・DMARCは何を解決する仕組みか
メールでは、送信者を偽装する問題と、正規のメールが迷惑メールとして扱われる問題を分けて考える必要があります。SPF・DKIM・DMARCは、送信元ドメインの正当性やメールの改ざん有無を受信側が判断するための仕組みです。SPFとDKIMは異なる方法で認証を行い、DMARCはその結果とFromヘッダーのドメインとの整合性を確認したうえで、失敗したメールの扱いを示します。認証に成功しても、メールの到達や受信トレイへの振り分けが保証されるわけではありません。
| 方式 | 認証対象 | 主な設定場所 | 受信側での利用目的 |
|---|---|---|---|
| SPF | 送信元サーバーやIPアドレス | 送信元ドメインのDNS TXTレコード | 送信元が許可された経路か確認する |
| DKIM | メールに付与された電子署名 | 送信元ドメインのDNS公開鍵と送信サービス | 署名対象のメールが変更されていないか検証する |
| DMARC | FromドメインとSPF・DKIMの整合性 | 送信元ドメインのDNS TXTレコード | 認証失敗時の扱いとレポート先を指定する |
SPFとは：送信を許可したサーバーをDNSで示す
SPF（Sender Policy Framework）は、受信側が送信元IPアドレスなどを確認し、そのドメインが送信を許可したサーバーから送られたメールかを判定する仕組みです。送信サービスの指定に従い、対象ドメインのDNSにSPF用のTXTレコードを登録します。
example.com. TXT "v=spf1 <送信サービスが指定する許可情報> -all"
# 期待される状態:
# 実際の送信経路がSPFレコードの許可対象に含まれている。
# <送信サービスが指定する許可情報>は環境ごとに異なるため、そのまま登録しない。複数のメール配信サービスやフォーム送信を利用する場合は、それぞれの許可情報を一つのSPFポリシーに整理します。同じドメインにSPFレコードを複数登録したり、送信サービスの追加漏れがあったりすると、意図した判定にならない場合があります。
- 対象ドメインとTXTレコードの内容が正しいか
- SPFレコードが重複していないか
- 利用中の送信サービスやフォーム送信が許可対象に含まれているか
- DNSの参照回数制約や反映状況に問題がないか
DKIMとは：メールに電子署名を付けて改ざんを検証する
DKIM（DomainKeys Identified Mail）は、送信側がメールに電子署名を付け、受信側がDNSに公開された公開鍵で検証する仕組みです。署名に使う秘密鍵は送信サービス側で管理し、公開鍵をDNSに登録する構成が一般的です。
- 送信サービスでDKIMを有効化する。
- サービスが指定するセレクタと公開鍵を確認する。
- 指定されたホスト名に公開鍵をTXTレコードとして登録する。
- テストメールのヘッダーでDKIMの判定を確認する。
DKIMでは、署名対象になっている本文やヘッダーが配送途中で変更されると、検証に影響する場合があります。転送や中継を含む構成では、セレクタ、公開鍵、署名対象ドメイン、送信サービス側の有効化状態を確認します。
DMARCとは：SPF・DKIMの結果を使って受信側の扱いを指定する
DMARC（Domain-based Message Authentication, Reporting, and Conformance）は、SPFまたはDKIMの認証結果に加えて、認証されたドメインがFromヘッダーのドメインと整合しているかを確認する仕組みです。この整合性をアライメントと呼びます。
_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:<レポート受信先>"
# 期待される状態:
# まずは認証結果を観測し、正規の送信経路を把握する。
# p、rua、ドメイン名、レポート受信先は運用方針に合わせて設定する。DMARCのポリシーには、失敗したメールを監視するnone、検疫を促すquarantine、拒否を促すrejectがあります。導入時は、いきなり厳しいポリシーを適用するのではなく、正規の送信元を把握し、レポートを分析しながら段階的に強化します。
| ポリシー | 目的 | 導入時の注意点 |
|---|---|---|
| none | 認証失敗を監視し、レポートを収集する | 正規の送信経路を把握する段階で使う |
| quarantine | 認証失敗メールを検疫扱いにするよう促す | 正規メールが迷惑メール扱いになる可能性を確認する |
| reject | 認証失敗メールを拒否するよう促す | 送信経路の漏れがないことを確認してから適用する |
DMARCレポートには送信元に関する情報が含まれる場合があります。レポートの受け取り先、保存方法、解析方法、個人情報を含む可能性があるデータの取り扱いを、運用面の論点として確認します。
認証に成功してもGmailに届かない主な理由
SPF・DKIM・DMARCに成功していても、メールが必ず受信トレイに届くとは限りません。Gmailでは、認証以外にも送信者やドメインの評価、迷惑メール率、送信量、本文やリンクの内容、送信元IPの状態などが配信に影響する可能性があります。
- 送信処理そのものに失敗している
- 宛先サーバーに拒否されている
- 受信側で迷惑メールに振り分けられている
- 受信側の制限や一時的な遅延が発生している
- 宛先不明、DNS不整合、送信サービス側の設定ミスがある
Googleのメール送信者向けガイドラインでは、個人用Gmailアカウントへの送信について、送信量に応じた認証やDNS、TLS、迷惑メール率などの要件が示されています。対象や要件は更新される可能性があるため、公開時点の公式情報を確認してください。
Gmailに届かないときの確認手順
- 送信サービスのログで、送信処理と宛先サーバーからの応答を確認する。
- 受信側で迷惑メールフォルダ、拒否通知、バウンスメール、遅延の有無を確認する。
- 受信メールのAuthentication-Resultsなどから、SPF・DKIM・DMARCの判定を確認する。
- DNSのTXTレコードと、実際の送信経路、Fromドメイン、Return-Pathの関係を照合する。
- 送信日時、宛先、エラー文、利用サービス、DNS変更前後の差分を記録する。
- 設定変更後はDNS反映や受信側の再評価に時間差がありうるため、短時間の再送を繰り返さず再確認する。
設定時と運用時に注意したいポイント
送信経路を追加・変更するときは、SPFの許可対象、DKIM署名、DMARCのドメイン整合性を同時に確認します。DNSの管理者とメールサービスの管理者が異なる場合は、変更担当者、確認者、切り戻し手順を事前に決めておくと安全です。
- 本番ドメインへ厳しいDMARCポリシーを適用する前に、正規の送信元を洗い出す。
- 認証結果だけでなく、バウンス率、迷惑メール判定、送信量、DMARCレポートも継続的に確認する。
- 変更前後のDNSレコードと送信サービス設定を保存する。
- 具体的なTXTレコード値は、利用中のメールサービスが提示する公式手順に従う。
確認に使える情報と参考資料の探し方
実環境の調査では、受信メールのヘッダー、送信サービスの配信ログ、DNSのTXTレコード、DMARCレポートを一次情報として確認します。外部の診断ツールを使う場合は、ドメイン名やメールアドレスなどの入力情報が第三者へ渡る条件も確認してください。
仕様を確認するときは、Googleのメール送信者向けガイドライン、SPF・DKIM・DMARCのRFC、利用中のメールサービスの公式設定ガイドを優先します。
ネットワーク 
