SPF・DKIM・DMARC は、どれもドメインのDNSに TXT レコードを追加して設定する送信ドメイン認証の仕組みです。順番は「SPF → DKIM → DMARC（最初は監視だけ）」が基本で、3つがそろうと、WordPress から送る問い合わせ通知やパスワード再設定メールが迷惑メール扱いされにくくなります。この記事では、それぞれのレコードの意味と書き方、DNS管理画面での入力のコツ、設定後の確認方法までを順に説明します。
3つの仕組みの役割
最初に、それぞれが何を証明するのかを整理しておくと、設定ミスの原因を追いやすくなります。
- SPF：「このドメインのメールは、このサーバー（IPアドレス）から送られる」と宣言します。受信側は、メールを送ってきたサーバーが一覧に含まれているかを確かめます
- DKIM：送信サーバーがメールに電子署名を付け、受信側はDNSに公開された公開鍵で署名を検証します。途中で改ざんされていないことと、署名したドメインが分かります
- DMARC：SPF または DKIM の結果が、メールの差出人（From）のドメインと一致しているかを確認し、失敗したときに受信側にどう扱ってほしいかを指定します。集計レポートの送り先も指定できます
Gmail や Yahoo などの大手メールサービスは、送信者に SPF・DKIM の設定を求め、大量に送る送信者には DMARC も求める方針を公表しています。対象の条件や細かい基準は変わることがあるため、各社の送信者向けガイドラインを確認してください（2026年10月現在）。
設定の前に確認すること
実際にメールを送っているサーバーを洗い出す
SPF に書くべきなのは「そのドメインを差出人にしてメールを送っているすべての送信元」です。WordPress サイトでは、次のように送信元が複数あることがよくあります。
- WordPress の
wp_mail()が、Webサーバーから直接送っている（PHP の mail 関数経由） - WP Mail SMTP や FluentSMTP などのプラグインで、外部のSMTPサーバーやメール配信サービス経由に切り替えている
- 社員が使う Google Workspace や Microsoft 365 などのメールサービス
- メルマガ配信サービスやフォームサービス
ひとつでも漏れると、その経路から送ったメールだけが SPF で失敗します。Webサーバーから直接送るより、SMTPプラグインで認証付きの送信サービスに寄せたほうが、SPF と DKIM を管理しやすくなります。
既存の TXT レコードを調べる
dig +short example.com TXT
dig +short _dmarc.example.com TXTv=spf1 で始まる行がすでにあれば、新しく追加せずにその行を編集します。SPF のレコードが2つ以上あると、仕様上エラー（permerror）として扱われ、両方とも効かなくなります。
SPF レコードを設定する
DNS管理画面で、ホスト名をドメインそのもの（多くの画面では @ または空欄）にして、TXT レコードを追加します。
v=spf1 ip4:203.0.113.10 include:_spf.mail-service.example ~allip4:は送信サーバーのIPv4アドレス。IPv6で送る場合はip6:も加えますinclude:は、利用しているメールサービスが公開しているSPFを取り込む指定です。値はサービスごとに決まっているので、各サービスのヘルプに書かれたものを使います- 末尾の
~allは「一覧に無い送信元は疑わしい（softfail）」、-allは「一覧に無い送信元は不正（fail）」という意味です
最初は ~all で始め、送信元の漏れが無いと分かってから -all を検討するのが無難です。また、include: などDNSの参照が発生する指定は合計10回までという上限があります。サービスを足していくうちに上限を超えると SPF 全体がエラーになるため、使っていないサービスの include: は削除しておきます。
DKIM レコードを設定する
DKIM の公開鍵は自分で作るのではなく、メールを送るサービス（メールサービス、配信サービス、レンタルサーバーのメール機能など）の管理画面で発行するのが一般的です。発行時に表示される「セレクター」と「値」を、そのままDNSに登録します。
ホスト名: s1._domainkey
種類: TXT
値: v=DKIM1; k=rsa; p=MIIBIjANBgkqh...（サービスが表示した公開鍵）s1 の部分がセレクターで、サービスによって名前が異なります。注意したいのは次の点です。
- サービスによっては TXT ではなく CNAME で登録する方式を採用しています。画面の指示どおりの種類で登録します
- 鍵が長い（2048ビットなど）と、1つの文字列の上限（255文字）を超えます。管理画面によっては自動で分割されますが、手入力で途中の文字が欠けると検証に失敗します
- 自前の Postfix サーバーから送る場合は、OpenDKIM などで鍵を作り、署名の設定もサーバー側で行う必要があります
DMARC レコードを設定する
DMARC は、ホスト名 _dmarc に TXT レコードを追加します。最初は受信側に処置を求めない p=none で始め、レポートで状況を確認します。
ホスト名: _dmarc
種類: TXT
値: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.comrua には集計レポート（XML形式）の送り先を書きます。届いたレポートを読むと、どの送信元が SPF・DKIM に失敗しているかが分かるので、漏れていた送信元を SPF や DKIM の設定に足していきます。レポートは量が多く読みにくいため、専用の受信・可視化サービスを使う方法もあります。なお、送り先を別ドメインのアドレスにする場合は、そのドメイン側で受け取りを許可するレコードが必要になります。
失敗するメールがほぼ無くなったら、p=quarantine（迷惑メールフォルダへ）、p=reject（受信拒否）の順に強めます。いきなり reject にすると、設定漏れのあった正規のメールまで届かなくなるので、数週間ほどレポートを見てから段階的に進めます。
「一致（アライメント）」でつまずきやすい点
DMARC は、SPF や DKIM が「合格した」だけでは足りず、合格したドメインが差出人（From）のドメインと一致している必要があります。たとえば WordPress がWebサーバーから送るメールでは、Fromは wordpress@example.com でも、裏側の送信元アドレス（Return-Path）がサーバーのホスト名になっていることがあります。この場合 SPF は合格しても、DMARC の判定には使われません。SMTPプラグインで送信サービスを経由させ、そのサービスで自分のドメインの DKIM 署名を有効にすると、この問題を避けやすくなります。
DNS管理画面で入力するときの注意
- ホスト名の書き方：画面によっては、入力した名前の後ろにドメイン名が自動で付きます。
_dmarc.example.comと入れて_dmarc.example.com.example.comになっていないか確認します - 引用符：値を
"で囲むかどうかは画面ごとに異なります。囲まない前提の画面で囲むと、引用符まで値に含まれることがあります - TTL：あとで修正する可能性が高い初期設定の間は、短め（300〜3600秒程度）にしておくと、修正の反映を待つ時間を減らせます
設定後の確認方法
DNSに登録された内容は dig で確認します。
dig +short example.com TXT
dig +short s1._domainkey.example.com TXT
dig +short _dmarc.example.com TXT次に、WordPress から自分の Gmail アドレスなどにテストメールを送ります。SMTPプラグインの多くにはテスト送信の機能があります。受信したメールの「メッセージのソースを表示」に相当する画面（表記はサービスによって異なります）で、SPF・DKIM・DMARC がそれぞれ PASS になっているかを確かめます。FAIL の場合は、ヘッダーの Authentication-Results 行に、どのドメインで何が失敗したかが書かれています。
まとめ
- SPF・DKIM・DMARC は、どれも TXT レコード（DKIM は CNAME の場合もあり）で設定する
- SPF は1ドメインに1レコード。送信元を漏れなく書き、DNS参照10回の上限に注意する
- DKIM の鍵はメール送信サービスで発行し、指定どおりのホスト名と種類で登録する
- DMARC は
p=noneで始め、レポートを見ながらquarantine、rejectへ段階的に強める - WordPress のメールは SMTPプラグインで送信サービス経由にすると、差出人ドメインとの一致を取りやすい
- 設定後は dig とテストメールのヘッダーで、3つとも PASS になっているかを確認する