SPF・DKIM・DMARC:なりすましメールを段階的に防ぐ方法

要点: SPFはドメインとして送信を許可するサーバーを一覧にし、DKIMは各メッセージに署名し、DMARCは表示されるFromアドレスのドメインについてどちらかが合格しているかを確認したうえで、失敗したメールをどう扱うかを受信側に伝えます。2024年2月以降、GmailとYahooはすべての送信者にSPFまたはDKIMを、大量送信者にはSPF・DKIM・DMARCのすべてを求めており、Gmailは2025年11月から執行をさらに強化しています。SPFレコードは1つだけ公開し、送信を行う各サービスでDKIMを有効にし、DMARCはレポート付きの p=none から始め、正規のメールが合格するようになったら p=quarantine または p=reject に移行しましょう。

メールは、誰が送信したかを証明する仕組みなしに設計されました。誰でもFromに billing@yourcompany.com と書けますし、認証レコードがなければ、受信サーバーはそれが偽物だと判断できません。これが、自社名を騙った請求書詐欺やフィッシングの仕組みであり、本物のメールがGmailに怪しいと見なされる理由でもあります。

SPF・DKIM・DMARCは、3つのDNSレコードでこの問題を解決します。このガイドでは、3つの連携の仕方、主要メールプロバイダーが求める要件、無料のSPF・DMARCチェッカーがドメインをどう読み取るか、そして自社のメールを壊さずにレコードなしの状態からポリシーの強制までたどり着く方法を説明します。

SPF・DKIM・DMARCの連携の仕組み

SPFとDKIMだけの弱点は「確認するドメイン」の行にあります。RFC 7208によれば、SPFはMAIL FROMとHELOのIDを確認しますが、受信者がそれらを目にすることはありません。なりすまし犯は、自分のドメインでSPFに合格しながら、Fromには自社のドメインを表示できてしまいます。DMARCはアラインメントでこの隙間を塞ぎます。SPFまたはDKIMがFromドメインと一致するドメインで合格した場合にのみ、DMARCに合格します(緩やかなアラインメントでは、同じ組織のサブドメインも許容されます)。

1つのレコードで見るSPF

example.com.  TXT  "v=spf1 include:_spf.google.com include:sendgrid.net -all"

各 include はプロバイダーのサーバーを許可し、末尾の -all はそれ以外をすべて失敗とします。RFC 7208は修飾子を定義しています。- はfail、~ はsoftfail(「おそらく許可されていない」)、? はneutral、+ はpassです。+all はインターネット全体を許可してしまい、意味がなくなります。

1つのレコードで見るDKIM

メールプロバイダーは秘密鍵で送信メッセージに署名し、セレクターの下に公開するための公開鍵を提供します。例:google._domainkey.example.com。送信サービスごとに独自のセレクターを使うため、複数のDKIM鍵を同時に持てます(RFC 6376)。

1つのレコードで見るDMARC

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

p はドメインのポリシー、sp はサブドメインのポリシーで、rua は受信側から届く日次の集計レポートの宛先です。レポートには、どのサーバーがあなたのドメインとしてメールを送信し、それが合格したかどうかが記載されています。

DMARC標準は2026年に更新されました

2026年5月、IETFはRFC 9989を公開しました。これは当初のDMARC仕様であるRFC 7489を廃止し、DMARCをStandards Trackに移行するものです。既存のレコードはそのまま動作し、バージョンタグも引き続き v=DMARC1 です。知っておきたい変更点は次のとおりです。

• pct が削除されました。 RFCは「正確に適用されないことが多かった」としています。代わりに新しい t タグ(「testing」)が導入され、t=y は受信側にポリシーを適用しないよう求めます。従来の pct=0 にほぼ相当します。
• np が追加されました。 存在しないサブドメイン向けのポリシーです。
• rf と ri が削除され、組織ドメインの特定にはPublic Suffix Listの代わりにDNSの「ツリーウォーク」が使われます。

受信側が新ルールに移行する速度はまちまちで、Google自身の設定ガイドも導入期間中は引き続き pct を推奨しています。pct を使っても問題は起きませんが、正確な割合として頼らないようにしましょう。

GmailとYahooの要件

両プロバイダーとも、2024年2月から送信者要件の執行を開始しました。

出典:Googleの送信者ガイドラインとYahooの送信者ベストプラクティス。Googleは、認証されていないメッセージは「迷惑メールとしてマークされたり、5.7.26エラーで拒否されたりする可能性がある」と警告しており、そのFAQでは「2025年11月から、Gmailは要件を満たさないトラフィックに対する執行を強化している」とし、一時的および恒久的な拒否が行われるとしています。同じFAQは、DMARCをSPFとDKIMの両方でアラインさせることを推奨し、このアラインメントは将来的に要件になる可能性が高いとしています。

1日の送信数が5,000通よりはるかに少なくても、これらのレコードは、請求書やパスワードリセット、返信が受信トレイに届くかどうか、そして他人があなたの名前で説得力のあるメールを送れるかどうかを左右します。

Searvia SPF・DMARCチェッカーの仕組み

無料のSPF・DMARCチェッカーはウェブサイトSEOチェッカーの一部で、メール認証のチェックを最初に表示します。ドメインを入力すると(先頭の www. は取り除かれます)、次の処理を行います。

1. ドメインのTXTレコードを取得し、v=spf1 で始まるものを抽出します。複数ある場合はSPFが失敗するため、警告が表示されます。
2. SPFレコードに必要なDNSルックアップ数(include、a、mx、ptr、exists、redirect。各includeは1段階先まで辿ります)を数え、10を超えると警告します。
3. _dmarc. とドメインを組み合わせたTXTレコードを取得し、v=DMARC1 で始まるものを抽出します。
4. DMARCレコードから p= ポリシーを読み取り、rua レポート宛先の有無を確認します。
5. 両方のレコードを全文表示し、チェックマークまたはバツ印を付け、DKIMの行には「Not checked」と表示します。

監査全体では、このチェックの優先度は中です。DMARCに関する判定が厳しい点に注意してください。p=none はGmailの最低要件は満たしますが、なりすましを止められないため警告が表示されます。

無料チェックが対象としない項目:

• DKIM。 DKIM鍵は各メールサービスが選ぶセレクターの下にあり、DNSから一覧を取得する方法がないため、レポートではDKIMを未チェックとしています。DKIMは、メールプロバイダーの管理画面か、送信したメッセージのヘッダー(dkim=pass を探してください)で確認します。
• SPFのすべてのルール。 レコードの重複と10回超のルックアップは警告しますが、レコードが -all と ~all のどちらで終わっているかは判定しません。includeは1段階先まで辿るため、深くネストしたレコードでは、表示される数より多くのルックアップが必要になることがあります。
• DMARCの詳細。 p= を読み取り、rua の有無を確認しますが、sp= やアラインメント設定は確認しません。

結果の読み方

• 不合格: ドメインがなりすましにさらされており、GmailやYahooの要件も満たしていません。下記のステップ1から始めてください。
• 「DMARC is missing」または「SPF is missing」: 対応が半分だけ終わった状態です。不足しているレコードを追加してください。
• 「DMARC is set to none」: 最もよくある結果です。(rua を設定していれば)レポートを収集できており、最初の段階としては正しい状態です。強制に移行する計画を立てましょう。
• 合格: 良好です。無料ツールでは見えない部分を確認しましょう。すべての送信元のDKIM、深くネストしたSPFのinclude、サブドメイン向けの sp ポリシーです。

対処法をステップごとに解説

ステップ1:自社ドメインとしてメールを送信するものをすべて洗い出す

メールボックスプロバイダー(Google Workspace、Microsoft 365)、メルマガツール、CRM、ヘルプデスク、請求ソフト、ECプラットフォーム、ウェブサイトの問い合わせフォーム、通知を送信するサーバーなどです。ここで1つでも漏らすと、後でDMARCを強制したときにうまくいかなくなる最大の原因になります。

ステップ2:SPFレコードを1つだけ公開する

1. 各プロバイダーが案内している include: の値を集めます。
2. それらを1つのレコードにまとめます。RFC 7208は明確で、SPFレコードが複数存在する場合、結果は「permerror」になります。
3. テスト中は ~all で終え、その後 -all にします。
4. ルックアップ数を数えます。include、a、mx、ptr、exists、redirect はそれぞれDNSルックアップを1回消費し、上限はネストしたinclude内のルックアップを含めて10回です。10回を超えるとpermerrorになります。使っていないサービスは削除し、RFCが「公開すべきではない(SHOULD NOT be published)」としている ptr も外してください。

プロバイダーが独自のエンベロープドメインで送信する場合(メルマガツールでよくあります)、そのプロバイダーをSPFに含める必要はまったくありません。DMARCに合格するには、自社ドメインでのDKIMが必要です。

ステップ3:すべての送信元でDKIMを有効にする

各サービスでドメイン認証またはDKIMの設定を見つけ、案内されたレコード(セレクター配下のTXTまたはCNAME)を公開して、署名を有効にします。Googleは、SPFとDKIMを設定してからDMARCを追加するまで48時間待つことを推奨しています。その後、Gmailアドレスにテストメールを送り、「Show original」(原文を表示)を確認します。SPF: PASS、DKIM: PASS、DMARC: PASS が表示されれば成功です。

ステップ4:レポート付きのp=noneでDMARCを公開する

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

Googleは、p=none から始め、必ず rua を含めることを推奨しています。集計レポートはXMLファイルで、DMARCレポートサービスやパーサーを使うと読みやすくなります。レポートの宛先が別ドメインにある場合は、そのドメイン側でDNSレコードによる許可が必要です。

ステップ5:レポートを読んで失敗を修正する

2〜4週間かけて、SPFまたはDKIMのアラインメントに失敗している正規のサービスを探します。それぞれに、自社ドメインでのDKIM署名かSPFのincludeが必要です。転送されたメールやメーリングリストは、正当な理由で失敗することがあります。RFC 9989は、ユーザーがメーリングリストに投稿するドメインは、p=reject にする前に、p=none で少なくとも1か月、p=quarantine で同程度の期間を過ごすことを提案しています。

ステップ6:quarantine、そしてrejectへ移行する

_dmarc.example.com.  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com"
_dmarc.example.com.  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com"

一度に1段階ずつ変更し、レポートを見続けましょう。p=quarantine に到達すると、当チェッカーでは合格になります。目標は p=reject で、失敗したメールを受信側が拒否します。

ステップ7:メールを送信しないドメインを保護する

パークドメインやリダイレクト専用ドメインは、誰も監視していないため、なりすまし犯に狙われやすくなります。英国政府のガイダンスは次のように推奨しています。

example.net.               TXT  "v=spf1 -all"
_dmarc.example.net.        TXT  "v=DMARC1; p=reject; sp=reject; adkim=s; aspf=s"
*._domainkey.example.net.  TXT  "v=DKIM1; p="
example.net.               MX   0 .

レコードを自分で確認する

チェッカーが読み取るのはSPFとDMARCですが、標準的なDNSツールを使えば3つすべてのレコードを確認できます。macOSまたはLinuxの場合:

dig +short TXT example.com
dig +short TXT _dmarc.example.com
dig +short TXT google._domainkey.example.com

Windowsでは、nslookup -type=TXT _dmarc.example.com で同じことができます。DKIMにはセレクターが必要です。プロバイダーのDKIM設定画面に表示されるほか、送信したメッセージの DKIM-Signature ヘッダーに s= として含まれています。Google Workspaceの既定値は google です。プロバイダーによっては、鍵を自社のDNSを指すCNAMEとして公開していますが、それで問題ありません。

最も確実なエンドツーエンドのテストは、実際にメッセージを送ることです。各サービスからGmailアドレスにメールを送り、「Show original」を開いてください。SPF、DKIM、DMARCの結果と、それぞれが合格したドメインが表示されます。DKIMが自社ではなくプロバイダーのドメインで合格している場合、DMARCのアラインメントはまだ失敗しているので、結果に自社ドメインがあるか確認しましょう。

よくある間違い

具体例(仮想)

以下は仮想の例であり、実際のデータではありません。架空のクリニック「Pinecrest Dental」は、患者から、クリニックを名乗る偽の支払い請求メールを受け取ったと知らされます。SPF・DMARCチェッカーの結果は次のとおりです。

• SPF:v=spf1 include:_spf.google.com ~all
• DMARC:なし。結果:警告「DMARC is missing.」

ステップ1で、3つの送信元が見つかります。Google Workspace、リマインダーをメールで送る予約システム、メルマガツールです。予約システムにはSPFのincludeが必要です。メルマガツールは独自のエンベロープドメインを使うため、代わりにクリニックのドメインでのDKIMを設定します。クリニックはレポート宛先付きの p=none でDMARCを公開します。2週間分のレポートから、予約システムはSPFに、メルマガはDKIMに合格していることがわかり、加えて、海外の未知のサーバーから届く数百通のメッセージが両方に失敗していました。これがなりすましです。クリニックは p=quarantine に移行し、チェッカーで合格となり、1か月後に p=reject へ進みます。これで、クリニックを騙る偽メッセージは、DMARCを適用する受信側で拒否されるようになります。

今週中に終えられるチェックリスト

1. パークドメインを含め、所有するすべてのドメインでSPF・DMARCチェッカーを実行する。
2. 自社ドメインとしてメールを送信するすべてのサービスを洗い出す。
3. SPFを、ルックアップ10回以内で ~all または -all で終わる1つのレコードにまとめる。
4. 各サービスでDKIMを有効にし、Gmailの「Show original」でテストする。
5. rua 付きの p=none でDMARCを公開し、レポートを読む。
6. p=quarantine、続いて p=reject へ移行する。
7. メールを送信しないドメインには v=spf1 -all と p=reject を公開する。

Searviaによるメール認証の監視

無料のSPF・DMARCチェッカーは、サインアップ不要で数秒のうちにレコードを読み取ります。これは、サイトの検索表示、速度、セキュリティも対象とする38項目の監査の一部です。

Searviaの無料アカウントでは、毎週のセキュリティスキャンが加わり、メールについてさらに踏み込んだチェックを行います。SPFレコードの欠落や緩すぎる設定(+all、?all、または all がまったくない)、DMARCポリシーの欠落や p=none のままの状態、CAAレコードの欠落を検出し、それぞれの検出結果の根拠となるDNSルックアップと、コピーして使えるレコードを提示します。スキャンは毎週木曜日に繰り返されるため、DNSの変更でレコードが壊れても、1週間以内に表面化します。ウェブサイト側のセキュリティについては、セキュリティヘッダーガイドをご覧ください。