送信ドメイン認証 SPF / DKIM / DMARC。なりすましメールを止める仕組みと段階導入

「取引先からの請求書メールだと思って開いたら、差出人をかたった偽物だった」。フィッシングやビジネスメール詐欺（BEC）の多くは、送信者を本物そっくりに見せかけることから始まります。やっかいなのは、メールの差出人欄は技術的に簡単に詐称できる、という事実です。差出人欄に取引先のドメインを表示させること自体は、攻撃者にとって難しくありません。

この「なりすませてしまう」問題に正面から取り組むのが、送信ドメイン認証と呼ばれる3つの仕組み、SPF・DKIM・DMARCです。これらは、フィッシング対策やBEC対策の華やかな検知技術ではなく、その手前にある「そもそも怪しいなりすましメールを受信側に弾いてもらう」ための土台にあたります。2024年からはGmailやYahooの送信者ガイドラインで一定規模以上の送信者に事実上必須となり、いまや「設定していて当たり前」のインフラになりつつあります。

この記事では、なぜ送信者がなりすませるのかという根本から出発し、SPF・DKIM・DMARCそれぞれの役割を表で整理したうえで、DMARCのアライメントとポリシー（none/quarantine/reject）、無理のない段階導入の手順、レポート運用、そして現場でつまずきやすい失敗までを、メール運用の実務担当者に向けて整理します。

なぜ送信者は簡単になりすませるのか#

そもそもの原因は、メールを運ぶ仕組みであるSMTP（Simple Mail Transfer Protocol）が、その名のとおり非常にシンプル（素朴）に設計されている点にあります。SMTPは1980年代に、相互に信頼し合う限られた組織間でメールをやりとりすることを前提に作られました。そのため、メールを送る側が名乗る「差出人」が本物かどうかを検証する仕組みが、もともと組み込まれていません。

さらにややこしいのは、メールには「From」が2種類あることです。

• エンベロープFrom（MAIL FROMコマンドで指定する送信元。Return-Pathとも呼ばれ、配送や不達通知の宛先に使われる。受信者には通常見えない）
• ヘッダFrom（メール本文のヘッダにある差出人欄。メールソフトに表示され、受信者が「誰から来たか」と認識するのはこちら）

攻撃者は、このヘッダFromに取引先や有名サービスのドメインを書くだけで、受信者の画面上は本物のように見せかけられます。封筒（エンベロープ）の差出人と、便箋（ヘッダ）に書かれた差出人が食い違っていても、素のSMTPはそれを問題にしません。送信ドメイン認証は、この「名乗りが本物か」を受信側で機械的に検証できるようにするために生まれました。

自社ドメインをかたるフィッシングが出回っていると顧客から連絡があり、調べたら自社のメールは送信ドメイン認証をほとんど設定していませんでした。受信側は本物か偽物か判定する材料を持っていなかったわけです。まずSPFとDKIMを整え、DMARCをp=noneで入れてレポートを見るところから始めました。

SPF・DKIM・DMARCそれぞれの役割#

3つの仕組みは、それぞれ別の角度からなりすましに対抗します。役割を取り違えると設定もちぐはぐになるため、まず違いを押さえます。

SPF: 送信元IPの認可リスト#

SPF（Sender Policy Framework）は、「このドメインのメールは、これらのIPアドレスから送られる」という許可リストをDNSに公開する仕組みです。ドメイン所有者がSPFレコード（TXTレコード）に自社のメールサーバーや利用中のメール配信サービスのIP範囲を書いておき、受信側は届いたメールの送信元IPがそのリストに含まれるかを照合します。RFC 7208が定める仕様で、検証対象はエンベロープFrom（MAIL FROM）のドメインです。

SPFは「正しいサーバーから出たか」は確認できますが、メール本文やヘッダFromの中身までは見ません。そのため単体ではヘッダFromのなりすましを直接は防げません。ここがDMARCで補われるポイントです。

DKIM: 電子署名による改ざん・なりすまし検出#

DKIM（DomainKeys Identified Mail）は、送信時にメールへ電子署名（デジタル署名）を付け、受信側がその署名を検証する仕組みです。RFC 6376が仕様で、送信側は秘密鍵で署名し、DKIM-Signatureヘッダに署名値（b=）と署名ドメイン（d=）、セレクタ（s=）を入れます。受信側は、署名ドメインのDNSに公開された公開鍵を取得して署名を検証します。

検証に成功すれば、「そのドメインがこのメールに責任を持って署名したこと」と「署名後にメールが改ざんされていないこと」が確認できます。SPFと違い送信経路（IP）に依存しないため、メールが転送されても署名さえ壊れなければ検証が通る、という利点があります。

DMARC: 差出人ドメインとの突き合わせと違反時の指示#

DMARC（Domain-based Message Authentication, Reporting, and Conformance）は、SPFとDKIMを束ねて、受信者に見えるヘッダFromのドメインを守る仕組みです。仕様は長らくRFC 7489（2015年、Informational）でしたが、2026年5月にIETFの標準（Proposed Standard）としてRFC 9989（本体）・RFC 9990（集計レポート）・RFC 9991（失敗レポート）へ置き換えられました（俗にDMARCbisと呼ばれた改訂で、組織ドメインの判定が静的なPublic Suffix ListからDNS Tree Walkアルゴリズムへ変更されています）。基本的な仕組みは変わらず、ドメイン所有者がDNSにDMARCレコードを公開し、(1)SPF/DKIMの結果をヘッダFromと突き合わせる基準（アライメント）と、(2)突き合わせに失敗したメールをどう扱ってほしいか（ポリシー）と、(3)結果のレポートをどこへ送ってほしいか、を受信側に伝えます。

重要なのは、SPFもDKIMも単体ではヘッダFromを守らない、という点です。DMARCがあって初めて、受信者が実際に目にする差出人欄のなりすましに対処できます。

DMARCの現行仕様はRFC 9989（2026年5月、旧RFC 7489を置換）です。ヘッダFrom（RFC5322.From）のドメインと、SPFまたはDKIMで認証されたドメインが一致（Identifier Alignment）したときにDMARCが合格となること、ポリシー値としてnone/quarantine/rejectを定めること、集計レポート（rua、RFC 9990）と失敗レポート（ruf、RFC 9991）の仕組みを規定しています（執筆時点の記載に基づく）。

DMARCの肝はアライメント#

DMARCを理解するうえで最も大事な概念がアライメント（alignment、整合）です。SPFやDKIMが「合格」しただけでは、DMARCは合格になりません。SPF/DKIMで認証されたドメインが、受信者に見えるヘッダFromのドメインと一致して初めて、DMARCに合格します。

なぜこれが必要なのでしょうか。SPFやDKIMは、それぞれ別のドメインに対しても成立してしまうからです。たとえば攻撃者が、自分が正規に管理する attacker.example というドメインでSPFやDKIMをきちんと設定したメールを送り、ヘッダFromだけを bank.example に偽装したとします。このとき、SPFやDKIMは attacker.example に対しては合格してしまいます。アライメントがなければ、「どこかのドメインで認証は通っている」という理由で、なりすましを見逃しかねません。

DMARCは、認証が通ったドメインと、受信者が見るヘッダFromのドメインが揃っているかを必ず確認します。

• SPFアライメント: SPFが合格し、かつエンベロープFromのドメインがヘッダFromのドメインと揃っている
• DKIMアライメント: DKIMが合格し、かつ署名ドメイン（d=）がヘッダFromのドメインと揃っている

DMARCは、このSPFアライメントとDKIMアライメントのどちらか一方でも成立すれば合格とします。逆に、両方とも成立しなかったときに初めて、後述のポリシー（quarantine/reject）が適用されます。なお、ドメインの揃え方には、完全一致を求めるstrict（厳格）モードと、組織ドメイン単位（サブドメインの違いを許容）でよしとするrelaxed（緩和）モードがあり、既定はrelaxedです。

DMARCポリシー: none / quarantine / reject#

DMARCレコードのp=タグで指定するポリシーは、アライメントに失敗したメールを受信側にどう扱ってほしいかの指示です。3段階あります。

p=noneは「監視のみ」で、なりすまし自体は止めません。あくまで、自ドメインを名乗って送られているメールの全体像と、SPF/DKIMの設定漏れを把握するための段階です。なりすましを実際に止める効果が出るのはquarantine以降であり、最終的にp=rejectまで到達して初めて、対応する受信側の多くがなりすましメールを拒否してくれる状態になります（ただし最終的な受信可否は各受信側の実装に依存します）。

裏を返せば、p=noneのまま放置すると「DMARCを入れているのに、なりすましは素通り」という状態になります。フィッシング対策協議会の報告書でも、日本企業はp=none（監視のみ）の比率が高く、rejectまで進んでいる割合が低い点が課題として指摘されています。導入したら終わりではなく、rejectを目標に段階的に強化していくことが肝心です。

フィッシング対策協議会の報告書（2025年1月30日付）は、観測したフィッシングメールのうち平均74.9%・最大91.9%が送信元ドメインを詐称した「なりすまし」であったとし、日本企業はDMARCを導入していてもp=none（監視のみ）にとどまる割合が高く、quarantine/rejectへの移行が進んでいない点を課題に挙げています（執筆時点の記載に基づく）。

2024年以降のGmail/Yahoo送信者ガイドラインという転機#

送信ドメイン認証が一気に「設定して当たり前」へと進んだ大きな契機が、GoogleとYahooが2024年から適用を始めた送信者ガイドラインです。Gmailの公式ヘルプ（Email sender guidelines）によれば、1日あたり5,000通以上をGmail宛てに送る一括送信者には、おおむね次が求められます。

• 送信ドメインにSPFとDKIMの両方を設定すること
• 送信ドメインにDMARCを設定すること（ポリシーは最低限p=noneでよい）
• マーケティングメールや購読メールにワンクリックでの登録解除（List-Unsubscribeヘッダ等）を備えること
• 迷惑メール報告率を低く保つこと（Postmaster Tools上で0.3%未満、推奨は0.1%未満）
• 正引き・逆引きのDNSレコード（PTR）を整備し、送信時にTLSを使うこと

ポイントは、SPF「または」DKIMではなく「両方」が求められ、さらにDMARCの設定（最低p=none）まで必須化された点です。これにより、大量送信を行う事業者は送信ドメイン認証を整えないとGmail/Yahooに安定して届かなくなりました。なお、この5,000通という基準はGmailが「個人のGmailアカウント宛てに1日5,000通超を送る送信者」を一括送信者と定義したものです。Yahooは公式FAQで明確な通数のしきい値を示さず「相当量を送る送信者（significant volume）」に同等の要件を求めるとしており、しきい値の有無は両社で異なります。いずれにせよ、これ未満でもSPF/DKIM/DMARCの整備は強く推奨されます。

Googleの公式ヘルプ「Email sender guidelines」は、1日5,000通以上をGmail宛てに送る送信者に対し、SPFとDKIMの設定、DMARC（最低p=none）の設定、ワンクリック登録解除、迷惑メール報告率を0.3%未満（推奨0.1%未満）に保つこと、PTRレコードやTLSの整備などを求めています（執筆時点の記載に基づく）。

なりすまし対策としての送信ドメイン認証は、こうした受信側の要件と、フィッシング・BECという脅威の両面から重要性が増しています。フィッシングの手口や利用者側の対策の全体像は

、取引先や経営層をかたって送金させるビジネスメール詐欺については

あわせて読みたい

ビジネスメール詐欺（BEC）の手口と組織的対策。送金プロセスを統制で守る

もあわせて読むと、なぜ送信側の認証整備が効くのかが立体的につかめます。

段階導入の手順: p=none で観測してから締める#

DMARCは、いきなりp=rejectにすると、設定漏れのある正規メール（配信サービス・社内システムからの自動メールなど）まで届かなくなる恐れがあります。そのため、レポートで実態を把握しながら、p=none -> quarantine -> reject と段階的に締めていくのが鉄則です。

総務省のDMARC等メール認証技術に関するガイドラインは、なりすまし・迷惑メール対策としてのSPF・DKIM・DMARCの位置づけと、DMARCレポートを活用しながらp=noneからquarantine・rejectへ段階的に移行する導入の進め方を整理しています（執筆時点の公開資料に基づく）。

レポート運用: rua と ruf#

DMARCのもう一つの柱が、受信側から送られてくるレポートです。DMARC仕様（集計レポートはRFC 9990、失敗レポートはRFC 9991）は2種類を定めています。

• aggregate report（集計レポート / ruaタグで送付先指定）: 一定期間ごとに、どの送信元IPから自ドメインを名乗るメールがどれだけ届き、SPF/DKIM/DMARCの結果がどうだったかをXML形式でまとめた統計。日々の運用の主役で、設定漏れの発見や正規送信元の棚卸しに使う
• failure report（失敗レポート、forensic report / rufタグで送付先指定）: アライメントに失敗した個別メールについて、ほぼ即時に送られる詳細な情報。原因調査に役立つが、メール内容を含みうるためプライバシーへの配慮が必要で、送らない受信側も多い

実務上は、まずruaを確実に受け取れるようにし、レポートを可視化するツール（DMARCレポート分析サービスなど）で読み解くのが現実的です。生のXMLは量も多く人手で追うのは大変なため、可視化の仕組みを用意することが段階導入を回す鍵になります。

よくある失敗#

送信ドメイン認証は、設定の細部でつまずくと「正規メールが届かない」「いつまでも認証が通らない」といった事故につながります。代表的な失敗を押さえておきましょう。

SPFの10ルックアップ超過（PermError）#

SPFには、評価の過程でDNS参照を伴う項目（include / a / mx / ptr / exists / redirect）の合計が10を超えてはならない、という上限があります。RFC 7208はこれを超えた場合にPermErrorを返すと定めており、PermErrorになるとSPFは合格扱いになりません。複数のメール配信サービスをincludeで積み重ねていくと、この10ルックアップ上限を簡単に超えてしまうのが、最もよくある失敗です。対策は、不要なincludeの整理や、複数のSPFレコードを一つに平坦化（フラット化）して参照数を抑える運用です。

RFC 7208（SPF）は、DNS参照を伴う項目（include・a・mx・ptr・exists・redirect）の合計を10までに制限し、これを超えた場合はPermErrorを返すと定めています。ip4・ip6・allなどDNS参照を伴わない項目はこの上限に数えません（執筆時点の記載に基づく）。

転送でSPFが壊れる#

メールが転送されると、転送サーバーのIPから再送出されるため、元のドメインのSPF許可リストに転送サーバーが載っておらず、SPFが失敗することがあります。これがDMARCに効いてくると、正規メールがアライメント失敗で落ちかねません。SPFは経路（IP）に依存するためこの弱点を持ちます。一方、DKIM署名は経路に依存しないため、転送されても署名さえ壊れなければアライメントが通ります。SPFとDKIMの両方を整え、DKIM側でアライメントを担保しておくことが、転送に強い構成になります。

サブドメインの設定漏れ#

DMARCは組織ドメイン（例: example.com）に設定すると、原則としてサブドメインにも適用されます（sp=タグで別指定も可能）。ところが、サブドメインから送る業務システムのメールでSPF/DKIMが未整備だと、組織ドメインのDMARCを締めた途端にそれらが落ちます。使っていない・送信に使わないドメインにも、なりすまし防止のためにp=rejectのDMARCを置いておく（送らないドメインからの送信をすべて拒否させる）対策もあわせて検討します。

DKIMの鍵運用の放置#

DKIMの公開鍵はDNSに置きますが、セレクタや鍵の更新（ローテーション）を放置すると、鍵漏洩時のリスクが残ります。鍵は定期的にローテーションする運用を組み込んでおくのが望ましい姿です。

なりすましメールは、人をだますソーシャルエンジニアリングの入口でもあります。技術的な認証で「届かせない」ことと、利用者が手口を知って「だまされない」ことは両輪です。手口の心理面と組織での備えは

で扱っています。

まとめ#

送信ドメイン認証は、SMTPがもともと送信者を検証しないという根本のすき間を、SPF・DKIM・DMARCの3点セットで塞ぐ仕組みです。SPFで送信元IPを、DKIMで電子署名を整え、DMARCでそれらを受信者に見える差出人ドメインと突き合わせ、違反したなりすましを段階的に締め上げていく。p=noneで実態を観測し、レポートを見ながらquarantine、rejectへと進めるのが、正規メールを止めずに守りを固める王道です。フィッシングやBECが自社ドメインのなりすましから始まる以上、送信側でこの土台を整えることは、自社の信頼と取引先・顧客を守るための、地味だが効果の大きい一手になります。