SPF・DKIM・DMARCとは？わかりやすく解説

SPF、DKIM、DMARCは三つのDNSレコードで、それぞれがメールについて別々の質問に答えます。SPF（Sender Policy Framework）は、そのドメインのメールを送ってよいサーバーを一覧にします。DKIM（DomainKeys Identified Mail）は、各メッセージに署名を付けます。受信側はこの署名で、送信後に何も変更されていないことを確認できます。DMARC（Domain-based Message Authentication, Reporting and Conformance）は、この二つの少なくとも一方がFromアドレスのドメインと一致しているかを確認します。そして、どちらも一致しないときにどうするかを受信側に伝えます。2024年以降、これらは任意のものではなくなりました。GmailとOutlook.comは今では、これらのチェックに失敗した多くのメールを、迷惑メールフォルダに入れるだけでなく拒否しています。

もう省略できない理由

2024年2月1日から、Googleは個人のGmailアカウントにメールを届けるすべての送信者に、必須の送信者ルールを導入しました。この基本要件では、すべての送信者がSPFまたはDKIMのどちらかを設定する必要があります。さらに、送信IPについて有効な正引きと逆引きのDNSを設定し、PTRレコードを一致させること、送信時にTLS暗号化を使うこと、RFC 5322の仕様に従うことが求められます。Google Postmaster Toolsでの迷惑メール率は0.3%未満に保つ必要があり、Googleは0.1%未満に保つことを推奨しています。認証されていないメールを送ると、メッセージが迷惑メールフォルダに振り分けられるか、エラーコード5.7.26で拒否されるとGoogleは警告しています。

個人のGmailアドレスに1日5,000通以上送る場合、Googleはその送信者を一括送信者に分類し、ルールはさらに厳しくなります。一括送信者はSPFとDKIMのどちらかを選ぶことはできず、両方を設定する必要があります。さらに、DMARCレコードを公開すること、表示されるFromヘッダーとSPFまたはDKIMのドメインのアライメント（一致）を保つこと、マーケティングメッセージに機能するワンクリックの購読解除の仕組みを入れることも必要です。Googleはこの5,000通の基準を、メインのドメインとそのすべてのサブドメインを合わせて、24時間の単位で数えます。ドメインが一度この基準に達すると、Googleは一括送信者の扱いを恒久的なものとします。2025年11月から、Gmailは要件を満たさない送信への対応を強化し始め、一時的な配信の遅延や恒久的な拒否を行っています。これらのガイドラインが適用されるのは個人のGmailアカウントで、Google Workspaceのビジネス用メールボックスには適用されません。

Microsoftも2025年5月5日に独自の認証要件の適用を始めました。対象は、個人向けのOutlook.com、Hotmail、Liveのアカウントに1日5,000通以上送る送信者です。この基準を超える送信者には、SPFの評価に合格すること、DKIMの署名に合格すること、そしてSPFまたはDKIMとアライメントが取れたp=none以上のDMARCレコードを公開することが必要です。これらの要件を満たさない場合、Microsoftはバウンスコード550 5.7.515 Access denied, sending domain does not meet the required authentication levelでメッセージをブロックします。Yahooも2024年に、一括送信者向けに同様のルールを導入しました。

Googleは、一時的な送信制限には4.xのコードを、恒久的な配信のブロックには5.xのコードを使います。キャンペーンがバウンスしたときは、マーケティングのダッシュボードから原因を推測しないでください。サーバーが返した拒否のヘッダーをそのまま確認してください。方法は、バウンスメッセージの読み方の解説で詳しく説明しています。

SPF：そのドメインのメールを送ってよいサーバー

Sender Policy FrameworkはRFC 7208で標準化されており、受信したメッセージのエンベロープ送信者を検証します。エンベロープ送信者とは、メールサーバーがバウンスを返すときに使うReturn-PathまたはMAIL FROMのアドレスです。SPFは、最初のHELOまたはEHLOのあいさつで名乗られたサーバー名を評価することもできます。SPFが確認するのはエンベロープ送信者だけで、受信トレイで人が目にするFromアドレスは見ません。そのため、SPFだけでは攻撃者によるブランド名のなりすましを防げません。

SPFレコードは、DNSに一つのTXTレコードとして設定します。どのIPアドレス、MXサーバー、外部のプラットフォームがそのドメインのメールを送ってよいかを、受信サーバーに伝えます。一般的なレコードは次のようになります。

v=spf1 include:_spf.google.com include:spf.your-esp.example ~all

どのレコードも v=spf1 で始まります。include:_spf.google.com という記述は、GoogleのSPFレコードを問い合わせ、その中に書かれたIPアドレスを許可するよう受信サーバーに指示します。二つ目のincludeは、マーケティングプラットフォームやトランザクションメールのサービスが運用するサーバーに送信の権限を与えます。

最後の記述は、一覧にない送信者をどう扱うかを受信側に伝えます。~all と書くソフトフェイルは、一覧にないサーバーはおそらく許可されていないことを示しますが、受信側にはメッセージを受け入れて迷惑メールのフィルタリングを行うよう求めます。-all と書くフェイルは、一覧にないサーバーをはっきりした失敗として扱い、受信側によってはそのメールを拒否します。複雑な構成を確認している送信者は、正当な業務メールを誤って失わないように、~all から始めることがよくあります。

RFC 7208には、守らなければならない厳しい制限が二つあります。一つ目は、一つのドメインが公開できるSPFレコードは一つだけということです。二つ公開するとpermerrorになり、送信するすべてのメールでSPFが無効になります。二つ目は、SPFの評価で使えるDNSルックアップが、include、a、mx、ptr、exists、redirect を合わせて最大10回までということです。レコードの解決に11回目のルックアップが必要になると、受信サーバーはpermerrorを返します。転送でもSPFは失敗します。受信者がメッセージを転送すると、転送するサーバーのIPがレコードと一致せず、SPFが失敗するからです。

DKIM：メッセージが変更されていないことを証明する署名

DKIMはRFC 6376で定義されており、サーバーではなくメッセージそのものに対して働きます。サーバーはメッセージを送る準備をするとき、選んだヘッダーと本文から暗号学的なハッシュを作ります。そのハッシュを秘密鍵で署名し、結果を DKIM-Signature ヘッダーに書き込みます。このヘッダーには主な値が二つあります。d= タグの署名ドメインと、s= タグのセレクタの文字列です。DKIMが示すのは署名が有効かどうかだけです。失敗したときにどうするかを決めるのはDMARCの役割です。

メッセージが届くと、受信側はヘッダーからセレクタとドメインを読み取ります。そして s._domainkey.d にある公開鍵をDNSに問い合わせ、署名を確認します。DKIMはヘッダーと内容に署名しますが、メール自体を暗号化するわけではありません。本文は読める文字のまま送られます。ただし署名によって、件名、送信者の情報、本文が途中で誰にも変更されていないことを証明できます。

通常のメール転送では、ヘッダーと本文の内容がそのまま保たれます。そのため、有効なDKIM署名はたいてい転送後も有効なままです。転送されたメールについては、DKIMはSPFより信頼できます。ただし、フッターを追加したり件名にタグを付けたりするメーリングリストでは、署名が壊れることがあります。Gmailは1024ビット以上の鍵を求めており、2048ビットを推奨しています。

DNSのDKIM公開鍵レコードは、次の形式です。

v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA...

v=DKIM1 タグはプロトコルのバージョン、k=rsa は鍵のアルゴリズムを示し、p= にはbase64でエンコードした公開鍵が入ります。自社でメールサーバーを運用している場合は、当社のDKIMジェネレーターで鍵のペアを作成できます。

よくある落とし穴は、プラットフォームの標準の署名に頼ることです。多くのメールプラットフォームは、初期設定で自社の共有ドメイン（d=shared-esp.example）を使って送信メールに署名します。署名は合格しますが、署名ドメインが表示されるFromのドメインと一致しないため、DMARCのアライメントが失敗します。プラットフォームの設定でカスタムDKIMを設定し、d= タグに自社のドメインが使われるようにする必要があります。

DMARC：二つの結果をFromアドレスに結びつけるチェック

Domain-based Message Authentication, Reporting, and Conformanceは、エンベロープのチェックと暗号学的な署名を、人が目にするFromアドレスに結びつけます。アライメントとは、SPFまたはDKIMに合格したドメインが、From行のドメインと同じであることです。DMARCは、SPFかDKIMのどちらかが認証に合格し、かつFromヘッダーのドメインとアライメントが取れているときに合格します。両方が同時に一致する必要はありません。ただしGoogleは両方を一致させることを推奨しており、将来は両方が必要になる可能性があるとしています。

たとえば、ある会社が毎週ニュースレターを送っているとします。メッセージには From: news@example.com と表示されます。バウンスを処理するため、メール配信サービスは独自のエンベロープアドレスを使い、Return-Pathを bounce-123@bounces.esp-mail.example にしています。このサービスは、d=example.com を使ったカスタムDKIMでメッセージに署名もしています。

受信サーバーがこのメッセージを処理すると、次のようになります。

1. SPFはエンベロープのドメイン bounces.esp-mail.example を確認して合格します。しかし esp-mail.example は example.com と一致しないため、SPFはDMARCのアライメントに失敗します。
2. DKIMは example.com の署名を確認し、暗号学的なハッシュを検証します。Fromヘッダーのドメイン example.com とも一致するため、DKIMは合格し、DMARCのアライメントも取れます。
3. DKIMが合格し、アライメントも取れているため、メッセージはDMARCに合格します。

DMARCには、SPFとDKIMそれぞれについて二つのアライメントのモードがあります。緩やかなアライメント（relaxed）が初期設定で、組織のドメインのサブドメインがルートドメインと一致するものとして扱われます。たとえば、news.example.com から送ったメールは、SPFまたはDKIMのドメインが example.com であればアライメントが取れます。厳格なアライメント（strict）は aspf=s または adkim=s で設定し、ドメインの完全な一致を求めます。サブドメインの違いは認められません。

DMARCレコードで公開できるポリシーの指示は三つあります。

• p=none：DMARCを監視モードにします。受信側はメールを通常どおり配信しながら、認証のレポートを集めます。
• p=quarantine：DMARCに失敗したメールを迷惑メールフォルダに入れるよう受信側に求めます。
• p=reject：DMARCに失敗したメールを拒否するよう受信側に求めます。

ruaタグは、集計レポートの送り先を受信側に伝えます。集計レポートは通常は毎日届くXMLファイルで、どのIPアドレスがそのドメインを使ってメールを送ったかを示します。_dmarc.example.com に公開する標準的な最初のレコードは、次のようになります。

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

2026年5月、Internet Engineering Task Force（IETF）はRFC 9989をStandards Trackとして公開しました。あわせて、集計レポートについてのRFC 9990と、失敗レポートについてのRFC 9991も公開しました。これらの新しい標準により、RFC 7489とRFC 9091は正式に廃止されました。v=DMARC1 で始まる既存のレコードは引き続き機能しますが、更新された仕様ではいくつかの運用上のタグが変わります。割合のタグ（pct）とレポート形式のタグ（rf）は廃止され、標準の一部ではなくなりました。レポート間隔のタグ（ri）はhistoric（過去のもの）に分類されています。ポリシーの段階的な導入をテストする送信者は、テストモード用の新しい t タグを使います。管理者は、np タグで存在しないサブドメインのポリシーを定義できます。現在のDNSレコードに割合のタグが入っている場合は、削除する計画を立ててください。当社のDMARCジェネレーターで、更新したレコードを作成したり、古いタグを取り除いたりできます。

受信サーバーがメッセージを確認する手順

受信側のゲートウェイにメールが届くと、サーバーは決まった順番で認証のチェックを行います。

1. サーバーはネットワークの接続を受け入れ、送信者のIPアドレスを記録し、HELOまたはEHLOのあいさつを評価します。
2. サーバーはエンベロープのReturn-Pathからドメインを取り出し、DNSに問い合わせて、送信IPにSPFの許可があるかを確認します。
3. サーバーは DKIM-Signature ヘッダーを見つけ、selector._domainkey.domain にある公開鍵をDNSに問い合わせ、ヘッダーと本文の暗号学的なハッシュを計算し直します。
4. サーバーは表示されるFromヘッダーを確認し、_dmarc.domain にあるDMARCのポリシーレコードをDNSに問い合わせます。
5. サーバーはドメインのアライメントを評価し、認証されたSPFのドメインまたは認証されたDKIMのドメインが、表示されるFromのドメインと一致するかを確認します。
6. サーバーはアライメントの結果に応じて、公開されているDMARCのポリシー（none、quarantine、reject）を適用します。
7. ruaでレポートを依頼している場合、サーバーは次の集計レポートにこの結果を加えて送ります。

Gmailでは、どのメッセージでも「メッセージのソースを表示」を開くと、三つの結果をすべて確認できます。

SPF・DKIM・DMARCがよく失敗する場所

新しいメールサービスを追加するときによくある間違いは、SPFレコードを二つ公開することです。管理者が設定の手順書に従って v=spf1 include:sendgrid.net ~all を追加し、既存のGoogleのレコードとは別に二つ目のTXTレコードを公開してしまうことがあります。RFC 7208は、一つのドメインに複数のSPFレコードを置くことを禁止しています。受信サーバーが二つのレコードを見つけると、permerrorで処理を止め、SPFは失敗します。解決するには、許可するすべてのベンダーを v=spf1 include:_spf.google.com include:sendgrid.net ~all のように一つの文字列にまとめます。

10回のルックアップの上限を超えることも、気づかないうちに配信が失敗する原因になります。include、a、mx、ptr、exists、redirect のタグはすべてこの上限に数えられます。ベンダーのレコードの中に入れ子になったincludeも数えられます。レコードに11回目のルックアップが必要になると、受信サーバーは自動的にpermerrorを返します。ルックアップの上限超えを解決するには、古いベンダーのレコードを整理するか、ルックアップを確認するツールを使うか、includeを明示的な ip4 の範囲に置き換えます。ただし、置き換えるのは自社で管理していて変わらない送信IPだけにしてください。

新しい送信サービスをつないだのにDNSに追加しないと、送信メールが迷惑メールフィルターに引っかかりやすくなります。営業やサポートのチームは、DNSの管理者に知らせずに、予約ツール、ヘルプデスクのプラットフォーム、請求書のシステムなどをつなぐことがよくあります。これらの新しいサーバーはSPFレコードに載っておらず、自社のDKIM鍵で署名もしないため、メッセージは認証に失敗し、迷惑メールフォルダに入ります。解決策は簡単なルールです。新しいツールをつなぐ人は、必ずDNSの管理者に知らせること。そしてDMARCのレポートを見て、知らない送信元がないかを確認することです。

プラットフォームが署名するDKIMに頼ると、署名が暗号学的には有効でも、DMARCのアライメントが失敗します。メールサービスが d=platform-mail.example でメッセージに署名し、From行には From: support@yourcompany.example と表示される場合、DKIMは技術的なチェックには合格しますが、自社のドメインとのアライメントには失敗します。この不一致を直すには、プラットフォームの設定を開き、自社のドメイン用のカスタムDKIM鍵を作成し、セレクタのレコードをDNSの管理画面で公開します。

メールの転送では、SPFが失敗するのが普通です。受信者が仕事のメールを個人の受信トレイに転送するたびに、これが起こります。間に入るサーバーは自分のIPアドレスでメッセージを渡すため、SPFレコードと一致しません。外部の転送の設定は管理できません。しかし、メッセージに有効なDKIM署名があれば、転送されてもそのまま残り、転送先でもDMARCの要件を満たせます。

別のプラットフォームから、無料の @gmail.com をFromアドレスにして一括キャンペーンを送ると、仕組み上DMARCに失敗します。Googleの送信者ガイドラインは、外部のサーバーからGmailのアドレスになりすますと到達率が下がると明確に警告しています。外部のプラットフォームは、Googleのドメインについて有効な暗号学的署名を作れず、SPFにも合格できません。そのため、メールボックスのプロバイダーはそのメールを拒否するか隔離します。アプローチのメールは、必ず自社が所有する独自ドメインから送ってください。

DMARCを p=none のままにしておくと、ドメインがなりすましに対して無防備なままになります。監視のポリシーはGmailとMicrosoftの最低要件を満たしますが、p=none は、なりすましのメールが届いても何の保護の措置も取らないよう受信サーバーに伝えるものです。この設定では、ドメインを完全になりすましたメールをDMARCで止められません。数週間かけて毎日の集計レポートを確認し、正当な送信元がすべてアライメントを取れていることを確かめてください。そのうえで、ポリシーを p=quarantine、次に p=reject に進めてください。

SPF・DKIM・DMARCの設定チェックリスト

次の順番で進めてください。

1. 自社のドメインでメールを送っている社内のサービス、マーケティングプラットフォーム、サポートデスク、トランザクションメールのツールをすべて一覧にします。
2. 許可する送信サーバーをまとめたSPFレコードを一つだけ公開し、ルックアップの合計を10回未満に保ちます。回数はSPFチェッカーで数えられます。
3. すべての送信プラットフォームで、自社のドメインを使ったカスタムDKIM署名を有効にし、対応するセレクタのレコードをDNSに公開します。
4. 送信IPアドレスに有効な正引きDNSがあり、逆引きDNSに一致するPTRレコードが設定されていることを確認します。
5. 最初のDMARCレコードを _dmarc に p=none で公開し、有効な rua のメールボックスを指定して、XMLの集計レポートの受信を始めます。
6. 送信ドメインをGoogle Postmaster Toolsに登録し、ドメインのレピュテーション、配信エラー、迷惑メールの苦情率を監視します。
7. 数週間かけてDMARCの集計レポートを確認し、正当な送信の流れがすべてSPFまたはDKIMのアライメントを取れていることを確かめます。
8. DMARCのポリシーを p=none から p=quarantine に進め、配信が安定しているかを評価してから、p=reject に進めます。
9. 個人のGmailアカウントにテストメッセージを送り、「メッセージのソースを表示」を開いて、SPF、DKIM、DMARCがすべてPASSになっていることを確認します。

よくある質問

DMARCにはSPFとDKIMの両方が必要ですか？いいえ。DMARCに必要なのは、SPFかDKIMのどちらかが認証に合格し、表示されるFromヘッダーのドメインとアライメントが取れていることです。両方を有効にしておけば、転送でSPFが失敗したときにも対応しやすくなります。Googleも大量送信では両方の設定を推奨しています。ただし、一方だけで有効なアライメントが取れていれば、メッセージはDMARCに合格します。

SPFとDMARCの違いは何ですか？SPFは、Return-Pathヘッダーにある技術的なエンベロープ送信者のアドレスについて、メールを送ってよいメールサーバーのIPアドレスを許可します。DMARCは、人がメールソフトで目にするFromアドレスを確認します。そしてSPFかDKIMのどちらかがその表示ドメインと一致しているかを検証し、検証に失敗したメッセージを受け入れるか、隔離するか、拒否するかを受信サーバーに伝えます。

1日の送信が5,000通未満でもDMARCは必要ですか？GmailがDMARCを求めるのは一括送信者だけです。そのため、少ない送信量でDMARCを設定しなくてもブロックはされません。ただし、SPFかDKIMは必要です。それでも、ruaを指定したp=noneのレコードは公開する価値があります。レポートを見れば、自社のドメインで送信しているサービスがわかるからです。忘れていたサービスや、なりすましをしている相手もわかります。

SPFレコードを二つ設定できますか？いいえ。RFC 7208は、一つのドメインに複数のSPFレコードを公開することを禁止しています。受信サーバーがDNSに複数のSPFレコードを見つけると、permerrorですぐに評価を中止し、SPFを失敗として扱います。許可するすべてのIPアドレスと外部のincludeを、v=spf1 で始まる一つのレコードにまとめる必要があります。

DMARCを最も簡単に説明するとどうなりますか？SPFは、メッセージを送っているサーバーがそのドメインのメールを送ってよいかを確認します。DKIMは、メッセージが変更されていないことを示す署名を確認します。DMARCは最後のチェックです。この二つのどちらかが、Fromアドレスと同じドメインのものかを確認します。どちらも一致しない場合、DMARCは、それでもメッセージを配信するか、迷惑メールフォルダに入れるか、拒否するかを受信サーバーに伝えます。

これらのレコードは送信者が誰かを証明しますが、送信先の問題は解決しません。使われていないアドレス宛てのメールは、やはりバウンスします。その問題についてはメールのバウンス率を下げる方法の解説で扱っています。次の送信の前に、リストをGiggal.ai（英語）にかけることもできます。