〜暮らしの落書き帳〜

SPF・DKIM・DMARC基礎

SPF・DKIM・DMARC基礎 副業・Web制作
2026.08.26

※本記事はアフィリエイト広告（PR）を含みます。

独自ドメインでメールを運用している場合、「SPF」「DKIM」「DMARC」という3つの仕組みが、迷惑メール判定やなりすまし対策の要になっています。特にメールサービスを移行したり、担当者や運用会社を引き継いだりする場面では、既存のDNS設定を誤って消してしまい、正規のメールまで届かなくなるトラブルが後を絶ちません。本記事では、SPF・DKIM・DMARCそれぞれの役割と相互関係、DNS設定例の読み方、引継ぎ時に必ず確認すべき手順、そしてよくある設定ミスを、初心者にも分かるように整理します。

SPF・DKIM・DMARCが必要な理由

メールの送信元アドレス（Fromアドレス）は、電話の発信者番号のように簡単に詐称できます。攻撃者が実在の企業ドメインを名乗ってフィッシングメールを送る「なりすまし」は、この仕組み上の弱点を突いたものです。SPF・DKIM・DMARCは、受信側のメールサーバーが「このメールは本当にそのドメインの管理者が許可した経路・方法で送られたか」を検証するための認証技術で、いずれもDNSにTXTレコードを公開する形で運用します。3つはそれぞれ検証する対象が異なり、組み合わせて初めて実効性を発揮します。

SPF・DKIM・DMARC基礎 関連画像1

SPF（Sender Policy Framework）とは

SPFは、そのドメインからメールを送ってよいIPアドレスやサーバーをDNS上のTXTレコードで宣言する仕組みです。仕様はIETFのRFC 7208で定義されており、受信サーバーはメールの「エンベロープFrom（Return-Path）」に記載されたドメインのSPFレコードを参照し、実際にメールを送ってきたサーバーのIPアドレスが許可リストに含まれているかを検証します。

SPFレコードの読み方

典型的なSPFレコードは次のような形式です。

v=spf1 include:_spf.google.com ~all
  • v=spf1：SPFバージョン1であることを示す先頭の宣言です。
  • include:_spf.google.com：Google Workspaceの送信サーバー群を許可する記述です。Microsoft 365であればinclude:spf.protection.outlook.comのように、サービスごとに指定する値が異なります。
  • ~all／-all：リストにないサーバーからの送信をどう扱うかの指定です。-allは「許可リスト外は不正なので拒否」、~allは「不正の可能性が高いが柔らかく処理（ソフトフェイル）」を意味し、Google Workspaceは自社ヘルプで~allまたは-allで終えることを推奨しています。

SPFで特に注意すべき制限

RFC 7208は、SPF評価時にDNS参照を伴う機構（include・mx・a・ptr・exists）の合計を10回までと定めており、これを超えると評価結果は「permerror」となり認証失敗として扱われます。all・ip4・ip6はDNS参照を発生させないためこの上限には含まれません。メール配信サービスやCRM、フォームツールなどを次々にincludeで追加していくと、この10回制限を意図せず超えてしまうケースが多く、送信ドメインに複数のツールを紐づけている企業ほど注意が必要です。

もう一つ実務でつまずきやすいのが、SPFレコードを1ドメインに2つ以上公開してしまう誤りです。SPFの仕様上、1つのドメインに有効なSPF TXTレコードは1本だけである必要があり、複数存在すると受信側での評価結果が不定または失敗になります。メールサービスを追加・移行する際に「既存のSPFレコードに気づかず、新しいv=spf1...を別のTXTレコードとして追加してしまう」事故が非常に多いため、必ず既存のSPFレコードを1本にまとめ、その中にincludeを追記する形で編集する必要があります。

DKIM（DomainKeys Identified Mail）とは

DKIMは、メール本文とヘッダーの一部に送信側が電子署名を付与し、受信側がDNSで公開された公開鍵を使ってその署名を検証する仕組みです。仕様はRFC 6376で規定されています。SPFが「送信元サーバーの正当性」を検証するのに対し、DKIMは「メール内容が送信後に改ざんされていないか」「本当にそのドメインの秘密鍵で署名されたものか」を検証する点が異なります。

DKIMの仕組みとDNS設定例

送信側メールサーバーは、メールヘッダーにDKIM-Signatureというフィールドを追加し、その中に署名対象ドメイン（d=タグ）と「セレクタ」（s=タグ）を含めます。受信側は、この2つの値から<セレクタ>._domainkey.<ドメイン>という形式のDNS名でTXTレコードを検索し、そこに公開されている公開鍵で署名を検証します。DNS上の実際のレコードはおおむね次のような形になります。

selector1._domainkey.example.com TXT
"v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC..."

Google WorkspaceやMicrosoft 365では、管理画面でDKIMを有効化すると専用のセレクタ名と公開鍵が発行され、それをDNSにTXT（またはCNAME）レコードとして登録する運用になります。RFC 6376は同一セレクタに対して複数のTXTレコードが存在する場合の挙動を「未定義」としているため、SPFと同様にセレクタごとのレコードは重複させないことが重要です。

DMARC（Domain-based Message Authentication, Reporting and Conformance）とは

DMARCは、SPFとDKIMの検証結果を踏まえたうえで、受信側メールサーバーに対して「認証に失敗したメールをどう扱ってほしいか」をドメイン管理者が指示するための仕組みです。仕様は2026年5月に公開されたRFC 9989で規定されています（従来のRFC 7489はRFC 9989によって廃止されました）。DMARCの検証で重要なのが「アライメント（alignment）」という考え方で、SPF・DKIMそれぞれの検証に使われたドメインが、実際に受信者の画面に表示されるFromヘッダーのドメインと一致しているかを追加でチェックします。

アライメントの考え方

  • SPFアライメント：SPF検証で使われたエンベロープFrom（Return-Path）のドメインと、表示上のFromヘッダーのドメインが一致するかを確認します。
  • DKIMアライメント：DKIM署名のd=タグのドメインと、表示上のFromヘッダーのドメインが一致するかを確認します。

DMARCでは、SPFかDKIMのいずれか一方でもアライメントが取れていれば認証成功と判定されます。アライメントには「厳格（strict）」と「緩和（relaxed）」の2モードがあり、緩和モードではサブドメインと親ドメインの関係も一致とみなされます。SPF・DKIM単体では合格していても、Fromドメインと一致していなければDMARCとしては不合格になる点が、初心者が混同しやすいポイントです。

DMARCレコードの読み方

v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com; t=n
  • p=：認証失敗メールへの対応方針です。none（何もしない・監視のみ）、quarantine（迷惑メールフォルダなどに隔離）、reject（受信拒否）の3段階があります。
  • rua=：認証結果の集計レポートを送ってもらうメールアドレスです。
  • t=：ポリシーを試験運用中かどうかを示すタグで、y（テスト中）とn（本番適用）の2値を取ります。旧仕様のRFC 7489にあった、ポリシーを適用する対象メールの割合を指定するpct=タグは、RFC 9989で削除され、t=に置き換えられました（t=yが旧pct=0、t=nが旧pct=100に相当します）。既存のレコードにpct=が残っていても直ちに問題にはなりませんが、新しく書くときはt=を使います。

Googleは2024年2月以降、1日5,000通以上をGmail宛に送る送信者に対して、少なくともp=noneのDMARCポリシー設定を必須要件としており、実運用ではまずp=noneでレポートを観察し、SPF・DKIMが安定して合格することを確認したうえでquarantine、最終的にrejectへ段階的に引き上げるのが公式にも推奨される進め方です。

3つの技術の相互関係

SPF・DKIM・DMARCは独立した技術ですが、実運用では次のような役割分担で機能します。

  1. SPFで「送信元サーバーが許可リストにあるか」を検証する。
  2. DKIMで「メール内容が改ざんされておらず、正しい秘密鍵で署名されているか」を検証する。
  3. DMARCで、SPF・DKIMの結果と表示上のFromドメインの一致（アライメント）を踏まえ、失敗時の扱いを受信側に指示し、送信者は集計レポートで異常を把握する。

Microsoft公式ドキュメントも、メッセージはSPFかDKIMのどちらか一方のアライメントチェックに合格すればDMARCに合格し、両方失敗した場合のみDMARC不合格になると説明しています。つまりSPFだけ、あるいはDKIMだけを設定していても、Fromドメインとの整合が取れていなければDMARCの効果は限定的であり、3点セットでの整備が推奨されます。

独自ドメインメールの移管・引継ぎ時に確認すべき手順

メールサービスの乗り換え（例：レンタルサーバーのメールからGoogle Workspaceへ、あるいは他社365環境からの引継ぎ）や、運用担当者・制作会社の交代時には、DNSのTXTレコードが最もトラブルの起点になりやすい箇所です。以下の手順で確認することを推奨します。

  1. 現行のDNSレコードを全件バックアップする：SPF・DKIM・DMARCだけでなく、MXレコードや他サービスが利用しているTXTレコード（ドメイン所有権確認用など）も含め、変更前に一覧を保存します。
  2. 既存のSPFレコードを消さずに「編集」する：新しいメールサービスのinclude句を、既存のSPFレコード内に追記します。新規にSPFレコードを別途追加すると、1ドメインに複数のSPFレコードが存在する不正な状態になります。
  3. DKIMは新旧セレクタが共存できるか確認する：旧サービスのDKIMレコードを即削除せず、新サービス側のDKIMセレクタを追加し、送信テストで新セレクタの署名が正しく検証されることを確認してから旧レコードを整理します。
  4. DMARCは最後に見直す：SPF・DKIMの移行が完了し、双方が安定してアライメントに合格することをDMARCレポートで確認してから、必要に応じてポリシーを見直します。移行直後にp=rejectのまま放置すると、正規の新サービスからのメールまで拒否される恐れがあります。
  5. 反映まで数十時間かかることを見込む：Google Workspaceのヘルプでも、SPF設定の反映やDKIM・DMARCの有効化まで最大48時間程度かかる場合があるとされており、DNS変更直後に即座に評価しないよう注意が必要です。

メールサービスごとに必要な設定が異なる点

SPFのinclude先やDKIMのセレクタ名・公開鍵、推奨されるDMARCポリシーの初期値は、利用するメールサービスによって異なります。例えばGoogle Workspaceではinclude:_spf.google.com、Microsoft 365ではinclude:spf.protection.outlook.comを用いるなど、サービスごとの公式ドキュメントに従って設定する必要があります。複数のメールサービスを併用している場合（例：業務メールはGoogle Workspace、メールマガジン配信は別の配信サービス）は、それぞれのincludeを1本のSPFレコードにまとめて記述し、10回のDNS参照制限を超えないよう調整することが欠かせません。

SPF・DKIM・DMARC基礎 関連画像2

なお、SPF・DKIM・DMARCをどこまで管理画面から設定できるかは、契約しているサーバーやメールサービスによって差があります。DKIMの鍵生成やDMARCレコードの追加を、DNSの手編集なしに行えるかどうかは、移管の前に確認しておきたい点です。独自ドメインのメールを法人で運用する場合は、XServerビジネスのように、メール機能と送信ドメイン認証の設定項目を管理画面側に用意しているサービスもあります。対応範囲と料金は公式ページで確認してください。

XServerビジネス

※上記は広告（アフィリエイトリンク）です。料金・プラン・キャンペーン内容は変わることがあるため、申し込み前に公式ページで最新の条件を確認してください。

よくある設定ミス

  • SPFレコードを重複して公開してしまう：既存レコードに気づかず新規追加し、1ドメインに2本以上のSPFレコードが存在する状態になる。
  • includeの多用によるDNSルックアップ超過：複数の外部サービスを次々にincludeし、RFC 7208が定める10回の上限を超えてpermerrorになる。
  • DKIM未設定のままDMARCを厳格化する：SPFのみでDMARCのp=rejectを運用すると、SPFのアライメントが崩れる転送メールなどで正規メールまで失敗扱いになりやすい。
  • アライメント不一致に気づかない：SPF・DKIM単体の認証結果は成功していても、表示上のFromドメインと一致していないためDMARCとしては不合格になっているケース。
  • 移管時に旧TXTレコードを即削除する：新サービスの検証が完了する前に旧DKIM・SPF関連レコードを削除し、移行期間中のメール認証が不安定になる。

よくある質問

SPF・DKIM・DMARCは3つとも設定が必要ですか？

役割が違うため、3つそろえるのが基本です。SPFは送信元のサーバー、DKIMは署名による改ざんの有無を確かめ、DMARCはその結果をもとに、認証に失敗したメールの扱いを受信側に伝えます。

SPFレコードを2つ登録してしまいました。どうすればよいですか？

1つのドメインで有効なSPFレコードは1本だけです。2本以上あると評価がうまくいかないため、送信を許可したいサービスのinclude句を1本のレコードにまとめ、余分なレコードは削除します。

DMARCのポリシーは最初から reject にしてよいですか？

いきなり reject にすると、正規のメールまで受け取ってもらえなくなるおそれがあります。まず p=none でレポートを見て、SPF・DKIMのアライメントが安定して合格していることを確かめてから強めるのが一般的です。

DNSを変更したのに、すぐに認証結果が変わりません。

反映には時間がかかることがあります。Google Workspaceのヘルプでも、設定の反映や有効化まで最大48時間ほどかかる場合があるとされています。変更直後は様子を見てから確認しましょう。

まとめ

SPFは送信元サーバーの正当性、DKIMはメール内容の完全性と署名の正当性、DMARCはこの2つの検証結果とFromドメインとのアライメントを踏まえた失敗時の扱いとレポーティングを担います。独自ドメインメールを移管・引継ぎする際は、既存のDNS TXTレコードを安易に消さず、SPFは1本にまとめて編集し、DKIMは新旧セレクタを共存させながら段階的に切り替え、DMARCのポリシーは最後に見直すという順序を守ることが、メール到達性を落とさずに引継ぎを完了させる基本です。設定変更後はメールサービス各社の公式ドキュメントとDMARC集計レポートで実際の認証結果を確認しながら進めることを推奨します。

関連して読みたい記事

参考情報・出典

⚡ いま読まれているトレンド

→ トレンド記事をもっと見る

広告

コメント

タイトルとURLをコピーしました