SPF・DKIM・DMARCの違い｜問い合わせメールが届かない前に確認する

先に答え：3つは代替ではなく、確認するものが違う

SPFは「そのドメイン名を使って送信してよいサーバーか」を送信元情報から確認します。DKIMはメールに付いた電子署名をDNS公開鍵で検証します。DMARCは、受信者に見えるFromドメインとSPFまたはDKIMのドメインが整合しているかを見て、失敗時の方針と集計レポートの送り先を示します。

画像を拡大 ↗

SPFは送信元、DKIMは署名、DMARCはFromの整合と方針を見る比較図。閉じる ×

3方式は代替ではなく確認対象が異なります。

Googleの2026年10月12日確認時点の送信者ガイドラインでは、個人向けGmailへ送るすべての送信者にSPFまたはDKIM、1日5,000通を超える送信者にはSPF・DKIM・DMARCなどを要求しています。小規模サイトでも、問い合わせ自動返信、予約通知、請求通知、メール配信サービスなど送信経路が複数ある場合は、3方式を一式として設計する方が確認しやすくなります。

最初に「メールを送る仕組み」を全部書き出す

DNSレコードを先に作るのではなく、独自ドメインを名乗って送るサービスを棚卸しします。フォームから管理者へ届く通知と、問い合わせ者へ返す自動返信は、別の送信経路やFromになる場合があります。

画像を拡大 ↗

通常メール、フォーム通知、自動返信、一斉配信の送信サービスを別々に記録する図。閉じる ×

受信だけのMX設定と送信者認証は分けて確認します。

受信だけに使うMXレコードと、送信者認証のTXTレコードを混同しないでください。サービスを追加したときはSPFだけでなく、そのサービスが独自ドメインDKIMに対応するか、DMARCの整合が取れるかも確認します。

SPFは「正規の送信元を一つの方針にまとめる」

SPFはDNSのTXTとして公開します。RFC 7208では、対象ドメインの利用を許可する送信ホストを明示し、受信側がMAIL FROMやHELOのドメインに対して確認します。表示上のFromアドレスだけを直接確認する仕組みではありません。

v=spf1 include:送信サービス指定の値 ~all

これは構造を示す架空例です。サービス名やinclude先を推測してコピーしないでください。 利用中の各送信サービスが公式に指定する値を集め、既存のSPFへ統合します。同じドメインに v=spf1 で始まるレコードを複数作ると、評価エラーにつながります。RFC 7208はSPF評価にDNS問い合わせ上限を定めており、Googleのトラブルシュート資料も10回のルックアップ上限に触れています。

DKIMは「送信サービス側の署名」とDNS公開鍵をそろえる

DKIMでは、送信サービスが秘密鍵でメールへ署名し、受信側が selector._domainkey.example.com のような名前で公開鍵を取得して検証します。鍵の生成、TXT/CNAMEの値、署名開始の操作はサービスごとに異なります。

1. 送信サービスの管理画面で独自ドメインDKIMを開始する。
2. 表示されたホスト名、種類、値をDNSへ正確に登録する。
3. DNSから公開鍵が取得できることを確認する。
4. 送信サービス側で検証・署名開始を完了する。
5. 実際に送ったテストメールのヘッダーで dkim=pass を確認する。

画像を拡大 ↗

送信サービスが秘密鍵で署名し、DNS公開鍵を受信側が照合するDKIMの流れ。閉じる ×

秘密鍵はDNSや依頼文へ貼り付けません。

DNSへ鍵を置いただけで送信側の署名が始まるとは限りません。逆に、署名を開始してもDNS名やセレクターが違えば受信側は検証できません。鍵の文字列が長いと管理画面で分割表示される場合があるため、事業者資料に沿って登録します。

DMARCは、まず観測してから方針を強くする

DMARCは _dmarc.example.com にTXTで公開します。最初から p=reject にすると、棚卸しから漏れた正規メールまで拒否される可能性があります。公式手順と運用体制を確認し、まず集計レポートを受け取れる状態で観測し、正規送信元のSPF/DKIMとFrom整合を直してから方針を強めます。

v=DMARC1; p=none; rua=mailto:dmarc-report@example.com

これは架空の構造例で、全組織にそのまま適用する推奨値ではありません。レポート先アドレスが大量のXML集計を受け取れるか、外部ドメインを指定する場合の認証が必要か、個人情報を含み得るレポートの管理方法も決めます。

画像を拡大 ↗

SPF・DKIMの整備、DMARCレポートの観測、方針強化を段階的に行う図。閉じる ×

具体的なDMARC方針は送信経路と運用体制に合わせます。

テストはDNS画面ではなく、実際の送信結果まで見る

各送信経路から自分が管理する検証用アドレスへ送り、受信メールのヘッダーで認証結果を確認します。Gmailでは「メッセージのソースを表示」でAuthentication-Results等を確認できます。

認証のpassは配送を保証しません。Googleも認証以外に、逆引きDNS、TLS、形式、迷惑メール率、購読メールの解除手段など複数の要件を示しています。届かない原因をSPFだけに決めつけないことが大切です。

作業依頼テンプレート

対象ドメイン：example.com
送信用途：問い合わせ通知／自動返信／通常メール／配信
表示上のFrom：＿＿＿＿
利用中の送信サービス：＿＿＿＿
現在のSPF：＿＿＿＿
DKIMのselectorと状態：＿＿＿＿
DMARCの方針とレポート先：＿＿＿＿
テスト送信日時：2026-10-12 15:30 UTC
認証結果：spf=＿＿ / dkim=＿＿ / dmarc=＿＿
確認したいこと：正規送信元の漏れ、From整合、段階的なDMARC方針

パスワード、秘密鍵、管理画面のログイン情報は依頼文へ貼り付けません。DNS変更前の値を保存し、反映後に全送信経路を再テストします。

SITE PORTを検討するときの確認ポイント

サイト制作を依頼する場合は、画面の見た目だけでなく、この記事で扱った設定を誰が担当するか、公開後に何を自分で変更できるかを確認します。SITE PORTの完成例と編集デモでは、完成イメージと日常的な編集の流れを確認できます。DNS・メール・計測の設定が通常の本文編集と同じ範囲で扱えるとは限らないため、必要な作業を具体的に伝えて対応範囲を確認してください。

関連記事

[問い合わせフォームが届かないときの切り分け](/articles/contact-form-delivery-test)・[A・CNAME・TXT・MXの違い](/articles/dns-record-types-practical)