SPF・DKIM・DMARC:仕組み・設定方法・重要性を徹底解説
メールは完璧に作られています。リストはクリーン。送信スケジュールも一貫しています。しかし開封率は低下し、Gmailはメールをスパムに振り分け続けています。問題は送信内容ではないかもしれません。あなたが本当にあなた自身であることを証明していないことかもしれません。
メール認証とは、あなたのドメインから来たと主張するメールが、実際にあなたのドメインから送信されたことをメールボックスプロバイダーに証明する方法です。認証がなければ、誰でも「From」アドレスを偽装し、あなたのブランドを騙るフィッシングメールを送信できます。メールボックスプロバイダーはこれを認識しています。だからこそ、認証されていないメールはデフォルトで疑わしいとして扱われます。
メール認証の基盤を形成する3つのプロトコルがあります:SPF、DKIM、DMARCです。これらが連携して、受信サーバーに対して、誰があなたに代わって送信する権限を持つか、メッセージが改ざんされていないか、何かが失敗した場合にどうすべきかを伝えます。このガイドでは、3つすべてを分かりやすい言葉で説明し、各設定方法を正確に示し、経験豊富な送信者でもつまずくミスをカバーします。
メール認証とは?
郵便で手紙を送るとき、受取人は差出人住所を見ることができます。しかし誰でも封筒に任意の差出人住所を書くことができます。メールも同じ仕組みです。メールの「From」フィールドは単なるテキストです。認証がなければ、スパマーがyou@yourdomain.comから送信されたかのようにメールを送ることを阻止するものはありません。
メール認証は、メッセージに検証可能な証拠を付加することでこの問題を解決します。受信メールサーバーが3つの質問に答えるためのDNSレコードと暗号技術のセットです:
- このサーバーはこのドメインのメールを送信する権限がありますか?(SPF)
- このメッセージは送信後に改ざんされていませんか?(DKIM)
- 認証が失敗した場合、どうすべきですか?(DMARC)
入口でIDを見せるようなものだと考えてください。SPFはゲストリストです。DKIMは入口で確認されたことを証明するリストバンドです。DMARCは一致しない人が来た場合の警備員への指示です。
SPF解説
SPFとは
SPF(Sender Policy Framework)は、あなたのドメインに代わってメールを送信する権限を持つすべてのIPアドレスとメールサーバーをリストしたDNS TXTレコードです。受信サーバーがあなたのドメインからメールを受信すると、SPFレコードをチェックして送信サーバーのIPアドレスが承認リストにあるか確認します。
IPが一致すればSPFパスです。一致しなければSPF失敗で、受信サーバーはメールが偽装されている可能性があると判断します。
SPFの仕組み(ステップバイステップ)
hello@yourdomain.comからメールサービスプロバイダー(ESP)を通じてメールを送信します。- 受信サーバーは、メールが
yourdomain.comからのものだと主張していることを確認します。 yourdomain.comのDNSでSPFレコードを検索します。- SPFレコードには「私のためにメールを送信できるのはこれらのサーバーだけです:192.0.2.1、およびMailchimpのSPFレコードにリストされているもの」のような内容が記載されています。
- 受信サーバーは、実際にメールを送信したIPがSPFレコードと一致するか確認します。
- 一致すればSPFパス。一致しなければSPF失敗。
SPFの設定方法
SPFの設定には、ドメインのDNSに単一のTXTレコードを追加する必要があります。一般的なSPFレコードは以下のようなものです:
v=spf1 include:_spf.google.com include:servers.mcsv.net -all
各部分を説明します:
v=spf1-- SPFレコードであることを識別しますinclude:_spf.google.com-- Google Workspaceにドメインの送信権限を付与しますinclude:servers.mcsv.net-- Mailchimpにドメインの送信権限を付与します-all-- 上記にリストされていないサーバーからのメールを拒否するよう受信者に伝えます
設定するには:DNSプロバイダー(GoDaddy、Cloudflare、Namecheapなど)にログインし、DNSレコードに移動し、ホストを@(ルートドメイン)に設定した新しいTXTレコードを追加して、SPF値を貼り付けます。ESPが何を含めるべきか正確に教えてくれます。ドキュメントを確認してください。
よくあるSPFのミス
- 複数のSPFレコード。ドメインにはSPFレコードは1つしか持てません。2つ目を追加すると(例:Google用とMailchimp用で別々に)、両方が壊れます。複数の
include:文を使用して1つのレコードにまとめてください。 - DNS参照回数が多すぎる。SPFにはDNS参照10回の制限があります。各
include:は参照1回としてカウントされ、ネストされたincludeもカウントされます。10回を超えると、送信するすべてのメールでSPFが自動的に失敗します。制限に達している場合はSPFフラット化ツールを使用してください。 -allの代わりに+allを使用。+allフラグは「誰でも私のドメインとして送信を許可する」という意味で、SPFの目的をすべて無効にします。常に-all(ハードフェイル)または最低でも~all(ソフトフェイル)を使用してください。- サードパーティ送信者の忘れ。CRM、ヘルプデスク、トランザクションメールサービスを使用している場合、それらのサーバーもSPFレコードに含める必要があります。よくあるパターン:マーケティングメールはSPFをパスするが、ヘルプデスクからのトランザクションメールは追加を忘れたために失敗する。
DKIM解説
DKIMとは
DKIM(DomainKeys Identified Mail)は、送信するすべてのメールに暗号化デジタル署名を付加します。この署名は送信サーバーだけが持つ秘密鍵を使用して生成されます。対応する公開鍵はDNSに公開され、誰でも署名を検証できます。
送信サーバーのみをチェックするSPFとは異なり、DKIMはメールの内容が送信後に変更されていないことを検証します。誰かがメールを傍受して変更した場合、DKIM署名が壊れ、受信サーバーはメッセージが改ざんされたことを検知します。
DKIMの仕組み(ステップバイステップ)
- メールサーバーがメールヘッダーとボディの一意の暗号化ハッシュを生成します。
- 秘密鍵でそのハッシュに署名し、
DKIM-Signatureフィールドとしてメールヘッダーに添付します。 - 受信サーバーがDKIM署名を確認し、セレクタとドメインを抽出します。
- セレクタを使用してDNSで公開鍵を検索します(例:
selector1._domainkey.yourdomain.com)。 - 公開鍵を使用してメール内容に対する署名を検証します。
- 署名が一致すればDKIMパス。一致しなければDKIM失敗(メッセージが改ざんされたか、鍵が一致しない)。
DKIMの設定方法
DKIMの設定はSPFよりもやや複雑で、メールプロバイダーがキーペアを生成する必要があります。一般的な手順は以下の通りです:
- ESPでDKIM鍵を生成する。メールプロバイダーの設定で「DKIM」または「メール認証」を探します。ほとんどのプロバイダー(Google Workspace、Mailchimp、SendGridなど)が鍵を生成し、追加するDNSレコードを提供します。
- DKIMレコードをDNSに追加する。
google._domainkeyのようなホストと、公開鍵を含む長い値を持つTXTまたはCNAMEレコードが提供されます。これをDNSプロバイダーに追加します。 - ESPでDKIMを有効化する。一部のプロバイダーでは、DNSレコードを追加した後に「認証を開始」などのクリックが必要です。このステップを飛ばさないでください。
- 動作確認する。テストメールを送信し、メールヘッダーで
dkim=passを確認します。ほとんどのESPはダッシュボードにもDKIMステータスを表示します。
DKIM DNSレコードは以下のようなものです:
Host: google._domainkey.yourdomain.com
Type: TXT
Value: v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A...
よくあるDKIMのミス
- すべての送信者にDKIMを設定しない。使用する各メールサービスには独自のDKIM鍵が必要です。Google WorkspaceにDKIMを設定してもMailchimpに設定しなければ、Mailchimpからのメールはdkimチェックに失敗します。
- 鍵の長さが短すぎる。少なくとも1024ビットの鍵を使用しますが、2026年の標準は2048ビットです。一部のプロバイダーはまだ1024がデフォルトです。可能であればアップグレードしてください。
- 鍵のローテーションをしない。必須のローテーションスケジュールはありませんが、DKIM鍵を年1回ローテーションすることはセキュリティのベストプラクティスです。秘密鍵が漏洩した場合、誰かがあなたのドメインとしてメールに署名できてしまいます。
- DNSレコードが単一のTXTエントリに収まらない。一部のDNSプロバイダーにはTXTレコード文字列あたり255文字の制限があります。2048ビットの鍵がこれを超える場合、複数の引用文字列に分割する必要がある場合があります。ESPのドキュメントに方法が記載されています。
DMARC解説
DMARCとは
DMARC(Domain-based Message Authentication, Reporting and Conformance)は、SPFとDKIMを結びつけ、重要な欠けているピースであるポリシーを追加するプロトコルです。DMARCは、あなたのドメインからのメールが認証に失敗した場合に受信サーバーが何をすべきかを指示します。
DMARCがなければ、受信サーバーは推測するしかありません。メールをそのまま配信すべきか?スパムフォルダに入れるべきか?完全に拒否すべきか?各サーバーが独自に判断します。DMARCを使えば、DNSに明確なポリシーを公開することであなた自身が決定できます。
DMARCはまたアライメントを導入します。SPFとDKIMはそれぞれメールヘッダーの異なる部分をチェックします。DMARCは、少なくとも一方が可視的な「From」アドレス(受信者が実際に見るもの)のドメインと「アライメント」していることを要求します。これにより、攻撃者が一方のドメインでSPFをパスしつつ、受信者には完全に異なるドメインを表示するという抜け穴が塞がれます。
DMARCポリシー:none、quarantine、reject
DMARCは3つのポリシーレベルを提供します:
p=none(監視のみ)
ここから開始受信サーバーは認証結果に関係なくすべてのメールを配信しますが、レポートを送信します。これは「観察モード」です。ポリシーを適用する前にすべての正当な送信者を発見するために使用します。
p=quarantine
中間段階認証に失敗したメールはスパム/迷惑メールフォルダに送信されます。認証済み送信者からの正当なメールは引き続き受信トレイに届きます。すべてが正しく動作していることを確認する間の良いステップです。
p=reject
最大の保護認証に失敗したメールは完全にブロックされます。受信者には届かず、スパムフォルダにも入りません。ドメインのなりすましやブランドに対するフィッシング攻撃から最も強力な保護を提供します。
DMARCの設定方法
DMARCはDNS内の単一のTXTレコードです。推奨されるアプローチは以下の通りです:
ステップ1:監視から始める。このTXTレコードをDNSに追加します:
Host: _dmarc.yourdomain.com
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com
v=DMARC1-- DMARCレコードであることを識別しますp=none-- 監視のみ、失敗に対してアクションを取らないrua=mailto:...-- 集約レポートの送信先(あなたのドメインとして誰がメールを送信しているか、認証に合格しているかを示すXMLレポート)
ステップ2:2〜4週間レポートを確認する。主要なメールボックスプロバイダーからXMLレポートを受信します。これらのレポートは、あなたのドメインを使用してメールを送信したすべてのIPアドレスと、SPF/DKIMがパスしたか失敗したかを表示します。DMARCレポートアナライザー(dmarcianやEasyDMARCなど)を使用してデータを読みやすくします。目標:すべての正当な送信者がSPFとDKIMの両方をパスしていることを確認することです。
ステップ3:quarantineに移行する。すべての正当なメールがパスしていることを確認したら:
v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@yourdomain.com
ステップ4:rejectに移行する。さらに数週間のクリーンなレポートの後:
v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourdomain.com
監視なしでいきなりp=rejectにジャンプしないでください。正当な送信者が適切に認証されていない場合、そのメールは無警告でドロップされ、受信者が「メッセージが届かなかった」と苦情を言うまで気づきません。
よくあるDMARCのミス
- いきなりp=rejectにジャンプする。これは最も危険なミスです。忘れていたサードパーティ送信者(古いCRM、ヘルプデスク、トランザクションメールサービス)が認証されていない場合、そのメールは無警告でブロックされます。
- レポートアドレス(rua)を設定しない。レポートがなければ盲目飛行です。正当なメールが失敗しているか、誰かがドメインを偽装しているかがわかりません。
- DMARCレポートを無視する。
p=noneを設定してレポートを見ないのは目的を達成していません。監視の要点は、ポリシーを適用する前に問題を発見することです。 - アライメントの問題。DMARCは、SPFまたはDKIMのドメインが可視的な「From」ドメインと一致(アライン)することを要求します。ESPが異なるドメインから送信し、あなたのドメインのDKIMで署名しない場合、SPFがパスしてもDMARCは失敗します。
SPF vs. DKIM vs. DMARC:比較
各プロトコルが何をし、何から保護するかの比較です:
| SPF | DKIM | DMARC | |
|---|---|---|---|
| 機能 | 認証済み送信サーバーのリスト化 | メールへの暗号化署名の付加 | 認証失敗時のポリシー設定 |
| DNSレコードの種類 | ルートドメインのTXT | selector._domainkeyのTXTまたはCNAME | _dmarcサブドメインのTXT |
| 検証内容 | 送信サーバーIPが認証済み | メッセージ内容が改ざんされていない | SPF/DKIMが可視的Fromドメインとアライン |
| 防止対象 | 未認証サーバーによるなりすまし送信 | 送信中のメール改ざん | ドメインのなりすましとフィッシング |
| 単独で機能? | 部分的 -- Fromヘッダーを検証しない | 部分的 -- 失敗時のポリシーなし | いいえ -- SPFおよび/またはDKIMが必要 |
| 2026年に必須? | はい -- Gmail・Yahooが要求 | はい -- Gmail・Yahooが要求 | はい -- 大量送信者に必須 |
重要なポイント:各プロトコルは異なるギャップをカバーします。SPFだけでは可視的な「From」アドレスを検証しません。DKIMだけでは認証失敗時に受信者に何をすべきか伝えません。DMARCだけではアンカーとなるSPFまたはDKIMなしには機能しません。3つすべてが連携して初めて効果を発揮します。
認証が配信到達性に与える影響
メール認証は送信者レピュテーションの基盤の一つです。メールボックスプロバイダーは認証をベースラインの信頼シグナルとして使用します。認証は受信トレイ到達の保証ではありません。クリーンなリスト、低い苦情率、良好なエンゲージメントも必要です。しかし認証がなければ、他のすべての取り組みが台無しになります。
各認証レベルで何が起こるかは以下の通りです:
- 認証なし:ほとんどの主要プロバイダーはメールをスパムフォルダに入れるか、完全に拒否します。Gmailは2024年の送信者要件更新以降、これについてますます厳格になっています。
- SPFのみ:何もないよりは良いですが、ギャップが残ります。転送されたメールはSPFを壊し、可視的なFromフィールドでのドメインなりすましに対する保護もありません。
- SPF + DKIM:大幅に改善されます。サーバー認証とメッセージの整合性の両方を証明します。しかしDMARCがなければ、ポリシーもレポートもなく、失敗が発生しても分かりません。
- SPF + DKIM + DMARC(reject):ゴールドスタンダードです。完全な認証、完全な保護、完全な可視性。これがGmailとYahooが大量送信者に要求するもので、すべてのドメインが目指すべきものです。
認証は複数の送信サービスを使用している場合に特に重要です。あなたのドメインに代わって送信するすべてのESP、CRM、ヘルプデスク、トランザクションメールシステムが適切に認証されている必要があります。単一の未認証送信者がドメイン全体のレピュテーションを低下させる可能性があります。ClearBounceの配信キットを使用して認証ステータスを監視し、受信トレイ到達率に影響が出る前に問題を捕捉してください。
100%
2024年以降、Gmailの大量送信者にはSPF・DKIM・DMARCが必須
10%
DMARC p=rejectのドメインはDMARCなしと比較して受信トレイ到達率が向上
31億
DMARC保護ドメインにより毎日ブロックされるなりすましメール数
よくある認証のミス
認証を正しく設定したと思っている送信者でも、隠れた問題を抱えていることがよくあります。最も頻繁に見られる問題は以下の通りです:
ドメインにはSPF TXTレコードは1つしか持てません。(マージせずに)2つ目を追加すると、両方が失敗します。これが最も一般的なSPFの設定ミスです。
各include:、a、mx、redirectメカニズムがDNS参照としてカウントされます。多くの送信者が気づかずに10を超え、すべてのメールでSPFがPermErrorを返します。
マーケティングメールはパスするが、ヘルプデスク、CRM、請求書システムはSPFへの追加とDKIM設定を忘れたために認証に失敗します。すべての送信サービスをカバーする必要があります。
監視期間なしでいきなりrejectに移行すると、忘れていたり設定ミスのある送信者のメールが無警告でドロップされます。常にp=noneから始めてレポートを確認してください。
p=noneでDMARCを設定してレポートを読まないと、送信者が壊れたとき、誰かがドメインを偽装したとき、より厳格なポリシーに移行する準備ができたときに気づきません。
1024ビット未満の鍵はクラックされる可能性があり、攻撃者がドメインとしてメールに署名できてしまいます。2048ビットの鍵を使用し、年1回ローテーションしてください。一部のプロバイダーはまだ1024がデフォルトです。確認してアップグレードしてください。
メール認証チェックリスト
このチェックリストを使用して、認証が正しく設定されていることを確認してください。各項目の確認は数分で済みますが、数週間の配信到達性の問題を防ぐことができます:
| タスク | プロトコル | 優先度 |
|---|---|---|
| すべての送信者をリストした単一のSPFレコードを公開する | SPF | 重要 |
| SPFが10未満のDNS参照を使用していることを確認する | SPF | 重要 |
SPFレコードを-allまたは~allで終了する |
SPF | 高 |
| 使用するすべてのメールサービスにDKIMを設定する | DKIM | 重要 |
| 2048ビットのDKIM鍵を使用する(1024ビットではなく) | DKIM | 高 |
| DMARCレコードを公開する(p=noneから開始) | DMARC | 重要 |
| DMARCレポートアドレス(rua)を設定する | DMARC | 高 |
| DMARCレポートを毎週確認する | DMARC | 高 |
| 監視後にDMARCをp=quarantineにアップグレードする | DMARC | 中 |
| 確信が持てたらDMARCをp=rejectにアップグレードする | DMARC | 中 |
| テストメールを送信し、ヘッダーでパスを確認する | 全て | 高 |
| ブロックリストステータスを定期的に監視する | 全て | 高 |
まとめ
メール認証はもはやオプションではありません。Gmail、Yahoo、Microsoftのすべてが、メールが受信トレイとスパムフォルダのどちらに属するかを決定する際のベースラインシグナルとしてSPF、DKIM、DMARCを使用しています。2024年以降、GmailとYahooは大量送信者に3つすべてを明示的に要求しており、その傾向は明確です:認証要件はますます厳格になる一方です。
良いニュースは、認証の設定は一度きりの作業で永続的なメリットがあるということです。SPF、DKIM、DMARCレコードが適切に設定されれば、送信するすべてのメールがそれらが確立する信頼の恩恵を受けます。配信到達性を向上させるだけでなく、レピュテーションと顧客の信頼を損なうフィッシングやなりすまし攻撃からブランドを保護しています。
しかし認証は配信到達性パズルの一部にすぎません。完璧に認証されたメールでも、無効なアドレスに送信すればバウンスします。完璧に署名されたメールでも、スパムトラップに送信すればレピュテーションを損ないます。認証はメールボックスプロバイダーにあなたが主張する通りの人物であることを伝えます。メール検証は、実際に存在し、あなたからの連絡を望んでいる人々に送信していることを確認します。この2つが合わさって、一貫して受信トレイに到達するための基盤となります。
まだ3つのプロトコルすべてを設定していない場合は、今日から始めてください。まずSPF、次にDKIM、そして監視モードのDMARCです。上記のチェックリストを使用してください。あなたの送信者レピュテーションと受信トレイ到達率が改善されるでしょう。
配信到達性を保護しましょう。
認証は正当な送信者であることを証明します。クリーンなリストは責任ある送信者であることを証明します。ClearBounceは、バウンスやブラックリスト登録を引き起こし、認証の成果を台無しにする前に、無効、リスキー、疑わしいメールアドレスを除去します。
100クレジット無料。クレジットカード不要。
無料で検証を開始する