SPFは「どの送信元を許可するか」、DKIMは「正規の鍵で署名されたか」、DMARCは「Fromドメインと認証結果をどう評価し、失敗メールをどう扱うか」です。3つは代替ではなく役割が違います。
独自ドメインメールを設定すると、DNS画面にSPF、DKIM、DMARCという言葉が並びます。WordPressの問い合わせ通知をSMTP化した時も、ここを曖昧にすると「送信はできるのに迷惑メールへ入る」「メールサービスを追加したら急に届かなくなった」という問題につながります。
僕も複数ドメインでZoho Mailを使い、DNSへSPF・DKIM・DMARCを設定しています。実際に難しいのは各用語を暗記することではなく、今そのドメインから何がメールを送っているかを漏れなく把握することです。Webサーバー、Zoho、フォーム、配信サービスなど送信元が増えるほど、DNSの整合性が重要になります。
SPF・DKIM・DMARCの違い
| 項目 | 確認する対象 | DNSで主に使う形式 | 失敗すると起こり得ること |
|---|---|---|---|
| SPF | 送信元サーバー/IPが許可されているか | TXT | なりすまし疑い、迷惑判定、拒否 |
| DKIM | メールの署名が公開鍵で検証できるか | TXTまたはCNAME（サービス依存） | 署名不一致、信頼性低下 |
| DMARC | SPF/DKIMとFromの整合＋失敗時ポリシー | _dmarcのTXT | 監視・隔離・拒否の判断に影響 |
3つの認証を役割別に理解する
SPF｜「このドメインから送ってよいサーバー」を宣言する
SPFは、ドメイン所有者が「この送信元は許可している」とDNS上で示す仕組みです。受信側はメールを受け取った時、送信元IPなどがSPFレコードに含まれるかを確認します。
たとえばZoho Mailと別の配信サービスの両方から同じ独自ドメインを使う場合、両方の送信元を1つのSPFレコードへ含める必要があります。ここで最もよくあるミスが、サービスごとにv=spf1から始まるTXTを複数作ることです。Zoho公式も複数のSPFレコードは無効になると説明しています。
DNSを書き換える前に、WordPress、メールホスティング、メルマガ、請求サービス、自動化サービスなど「自分のドメイン名をFromにして送るもの」を一覧化します。消してよい送信元か分からない場合は、既存SPFを上書きしません。
DKIM｜メールに電子署名を付けて正当性を確認する
DKIMでは送信側が秘密鍵でメールへ署名し、受信側がDNSに公開された公開鍵で署名を検証します。配送途中で内容が改変されていないか、正規の送信サービスが署名したかを判断する材料になります。
DKIMのDNS名には「selector」が含まれます。メールサービスによってselectorや公開方法が違うため、他サイトの値をコピーしません。Zohoや利用中のサービスが管理画面で発行した値を、そのドメインのDNSへ正確に追加します。
DMARC｜Fromドメインとの整合と失敗時の扱いを決める
DMARCはSPFやDKIMの結果を使いながら、ユーザーが目にするFromドメインとの整合性を確認し、認証に失敗したメールをどう扱うかを受信側へ示します。また集計レポートを受け取る仕組みを利用できるため、知らない送信元から自分のドメインを名乗るメールが出ていないか監視する材料にもなります。
Zoho公式は、DMARCを公開する前にSPFとDKIMを設定するよう案内しています。最初から強い拒否ポリシーへすると、まだ把握できていない正規サービスまで弾く可能性があります。まず送信元を洗い出し、認証結果を確認してからポリシーを強めるのが安全です。
Gmailの2026年時点の要件
Googleの送信者ガイドラインでは、Gmailアカウントへ送るすべての送信者にSPFまたはDKIM、TLSなどを求めています。1日5,000通を超える送信者にはSPFとDKIM、DMARCなど追加要件があります。さらにGoogleは、規模にかかわらず送信ドメインへSPF・DKIM・DMARCを常に設定することを推奨しています。
WordPressの問い合わせ通知は通常「大量送信」ではありませんが、だから認証が不要という意味ではありません。特にパスワード再設定、問い合わせ、自動返信、注文通知など届かないと困るメールは、送信元ドメインを認証しておく方が運用リスクを下げられます。
WordPressでの設定順
- WordPressからメールを送っている経路を一覧化する
- 主な送信先を認証済みSMTPへ揃える
- Fromアドレスを自分の独自ドメインへ固定する
- 現在のSPFを確認し、送信元を1レコードへ統合する
- メールサービスでDKIMを発行し、DNSへ追加する
- SPF/DKIMが正常なことをテストする
- DMARCを監視から始める
- 問い合わせフォーム・WordPress通知を実送信する
- Gmail等のヘッダーで認証結果を確認する
Cloudflare DNSを使う場合の考え方
CloudflareでDNSを管理していても、SPF・DKIM・DMARCの目的は同じです。MXやTXTはメール用レコードとしてDNSへ登録します。Cloudflare公式ドキュメントでも、MXやメール認証用レコードの設定方法が案内されています。
WebサイトのA/CNAMEをCloudflare経由でプロキシしていることと、メール配送は分けて考えます。Cloudflareのメール関連ドキュメントでも、MXやTXTの値は利用中メールプロバイダーの指示に従う必要があるとされています。
設定・移行で起きやすい失敗
SPFを2本以上作る
最も避けたいミスです。「Zoho用」「別サービス用」と分けず、1本へ統合します。統合方法が分からない場合は現在のレコードを保存してから作業します。
DKIMのselectorを別ドメインからコピーする
selectorや公開鍵はサービス・ドメインごとに発行されるため、他サイトの値を流用しません。
DMARCをいきなりrejectにする
未把握の正規送信元まで拒否する可能性があります。送信元の棚卸しと認証確認を先に行います。
Webサーバー移行時にメールDNSを消す
WebサイトのAレコードだけ変えるつもりが、ネームサーバー変更時にMX/TXTを移し忘れる事故があります。DNS移行前に全レコードを一覧化します。
認証結果を確認する方法
テストメールをGmailへ送り、メッセージの詳細やヘッダーでSPF、DKIM、DMARCの結果を確認できます。Zoho MailにもMX・SPF・DKIM・DMARCを確認するツールがあります。設定画面で「追加済み」と表示されることより、外部DNSから正しく引けるか、実メールで認証に合格するかを確認します。
SPFは「TXTを1本にする」だけでなくDNS lookup上限10回も確認する
SPFはincludeを増やせば安全になるわけではありません。RFC 7208では、SPF評価中にDNS問い合わせを発生させるinclude、a、mx、ptr、exists、redirectの合計を10回までに制限し、超過時はpermerrorとする仕様です。
メール配信サービス、フォーム配信、CRM、メルマガを追加するたびにinclude:を継ぎ足すと、見た目は1本のSPFでも内部参照が増えます。新しい送信元を追加する時は「SPFレコードが1本か」だけでなく「その1本が何回DNS lookupするか」も確認します。
DMARCはp=noneで観測してから段階的に強める
DMARCを最初からp=rejectにすると、正規の送信サービスをSPF/DKIMへ登録し忘れていた場合に、自社メールまで拒否される可能性があります。最初はp=noneで集計レポートを受け取り、正規送信元を洗い出してからquarantine、必要ならrejectへ段階的に進める方が安全です。
| 段階 | 例 | 目的 |
|---|---|---|
| 観測 | p=none; rua=mailto:... |
正規送信元と失敗を把握 |
| 隔離 | p=quarantine |
失敗メールを迷惑メール等へ寄せる |
| 拒否 | p=reject |
未認証なりすましを強く拒否 |
アライメントは「passしたドメイン」とFromが一致するかを見る
DMARCはSPFまたはDKIMが単にpassすればよいわけではありません。受信者に見えるFromドメインと、SPFで評価されたMAIL FROMドメインまたはDKIM署名ドメインが整合している必要があります。外部サービスを使う場合は、送信サービス側で独自ドメイン認証を設定し、Fromだけ自社ドメインへ変えた状態を放置しないことが重要です。
複数サイト運営ではDNS台帳を作る
サイトが増えると、どのドメインでどのメールサービスを使っているか分からなくなります。僕はWebサイト、DNS、メール、フォームを別々のものとして管理しつつ、関係が分かるように一覧化する設計を重視しています。
| 管理項目 | 残す内容 |
|---|---|
| DNS管理先 | ムームーDNS、Cloudflare等のどこが権威DNSか |
| メール提供元 | Zoho Mail、サーバーメール等 |
| 送信元 | WordPress SMTP、請求、自動化、メルマガ等 |
| SPF | 現在の完全な値と変更日 |
| DKIM | selectorと提供サービス |
| DMARC | 現在のポリシーとレポート先 |
| テスト結果 | 最終確認日とGmail等での認証結果 |
DMARCで重要なのは「認証した」だけでなくアライメント
DMARCでは、SPFやDKIMが単体でpassしていても、ユーザーに見えるFromドメインとの整合が取れているかが重要です。たとえば外部サービスのドメインでDKIMがpassしていても、自分のFromドメインと一致しない構成ではDMARCの意図を満たせない場合があります。
そのため「テストツールでSPF passと表示されたから完了」とせず、実際の受信メールヘッダーでSPF・DKIM・DMARCとheader Fromを一緒に見ます。メール配信サービスを追加するときも、そのサービスが自分のドメインでDKIM署名できるか、SPF/DKIMのどちらでアライメントを取る設計かを確認します。
DNS移行・メールサービス変更時は認証レコードも移す
ネームサーバーをCloudflare等へ移す時は、MXだけ移せばメールが使えるとは限りません。SPF、DKIM selector、DMARC、ドメイン所有確認用TXT/CNAMEも新しいDNSへ移します。逆にメールサービス自体を変更する場合は、旧サービスのSPF includeやDKIMをいつ削除するかを切替計画に含めます。
公式情報・参考資料
仕様・ガイドライン確認日：2026年10月1日。設定画面や料金は変更されるため、実作業前にリンク先の最新版も確認してください。
- Gmail：メール送信者のガイドライン
- Zoho Mail：SPFレコード
- Zoho Mail：DMARCポリシー
- Zoho Mail：ツールキット
- Cloudflare：Set up email records
- RFC 7208：SPF DNS Lookup Limits
あわせて読みたい
まとめ
SPF・DKIM・DMARCは「3つの似た設定」ではなく、許可する送信元、署名、Fromとの整合と失敗時ポリシーという別の役割があります。WordPressでメールを安定運用するなら、SMTPだけ設定して終わらず、送信元一覧→SPF→DKIM→DMARC→実メール検証の順で整えてください。
コメント