結論：Gmailなら「メッセージのソース」を開いて、Authentication-Results を見ればOK。
ここに spf=pass / dkim=pass / dmarc=pass が揃うと、到達率・迷惑メール回避は一気に安定します。
WordPressのフォーム通知が「届かない」「迷惑メールに入る」とき、原因はだいたいこのどれかです。
- SPFが失敗している（送信元が許可されていない）
- DKIMが付いていない／検証に失敗している
- DMARCの“整合（アライメント）”が崩れている（Fromのドメインが一致していない）
この記事では、GmailでSPF/DKIM/DMARCの結果を最短で確認し、FAILだった時の切り分け方までまとめます。
この記事でわかること
- Gmailでメールヘッダー（ソース）を開いて認証結果を見る手順
spf / dkim / dmarcの pass / fail / none の意味- FAILだったときに、どこを直せばいいか（最短の当たりの付け方）
- WordPressフォーム通知で“やりがちな事故”を回避する設計（From / Reply-To）
事前に知っておくと迷わない「3つの用語」
ヘッダーを見ると、似た名前がいくつか出てきます。最初はここで迷いがちです。
1) From（見た目の差出人）
受信画面で見える「差出人」です。例：no-reply@mg.example.com
2) Return-Path（実際の送り主の住所）
メールの返送先（バウンス先）で、SPF判定に効きやすい値です。
※サービスによっては bounce@mg.example.com のようにFromと違うことがあります。
3) DKIMの署名ドメイン（d=）
DKIMはメールに署名が付いていて、d=example.com のように“署名したドメイン”が表示されます。
そして重要なのがこれです。
- DMARCは「Fromのドメイン」と、SPFまたはDKIMの“ドメイン整合（アライメント）”が取れているかを見ます
→ SPF/DKIMが一部通っていても、Fromと整合していないとDMARCはfailになります
Gmailで認証結果（PASS/FAIL）を確認する手順
手順1：対象メールを開く
Gmailで、届いたメール（または迷惑メールに入ったメール）を開きます。
手順2：「メッセージのソース」を開く
本文右上の「︙（その他）」→ 「メッセージのソースを表示」
新しいタブで、ヘッダーと本文の生データが表示されます。
手順3：Authentication-Results を探す
開いたソース画面で検索（Ctrl+F / ⌘F）して、次のキーワードを探します。
Authentication-Resultsspf=dkim=dmarc=
だいたいこんな行が見つかります（例）。
spf=pass (...)dkim=pass (...)dmarc=pass (...)
ここだけ読めばOK：判定の読み方（超重要）
理想形（到達率が安定しやすい）
spf=passdkim=passdmarc=pass
よくある表示と意味
pass：OK（認証成功）fail：NG（認証失敗）softfail：ほぼNG（弱い失敗。迷惑メール判定の原因になりやすい）neutral/none：判定材料が弱い（設定不足 or 対象外）dkim=none：署名が付いていない（または受信側が確認できない）
FAILだったときの「最短切り分け」
ここからが本題です。
どこがfailかで、直す場所がほぼ決まります。
1) SPFが fail / softfail のとき
ありがちな原因
- SPF（
v=spf1）に 今の送信元が含まれていない - SPFが 複数本になっている（
v=spf1が2つ以上ある） - 送信サービスを変えたのに、SPFを更新していない
- WordPressが自ドメインを名乗っているが、実際の送信が外部（SMTP/配信サービス）でズレている
まず確認すること（これで8割当たる）
- 送信に使っているのはどれ？
- レンタルサーバーのメール送信
- 外部SMTP（Google Workspace / Microsoft 365 など）
- 送信サービス（Mailgun / SendGrid / Amazon SES など）
→ 使っている送信元に合わせて、SPFに include やIP許可が必要になります。
対処の方向性
- SPFのTXTを「1本」に統合する
- 実際の送信元を許可する（include追加）
- 送信方式を統一する（SMTP or API送信）
2) DKIMが fail / none のとき
ありがちな原因
- DKIMが未設定（そもそも署名が付いていない）
- DNSレコード名の貼り間違い（
_domainkeyが二重になっている等） - 参照しているDNSゾーンが違う（認証ドメインと貼り先のDNSが不一致）
- DNSがまだ反映していない（TTL/キャッシュ）
- Cloudflareの設定影響（DNSレコードの扱い・見え方の問題）
まず確認すること
- ヘッダー内に
dkim=が出ているか（noneなら署名が付いていない可能性大） dkim=failの場合、header.d=やselector=の情報が出ていないか
対処の方向性
- 送信サービス側で DKIM有効化 → 指示されたDNSレコードを正しく追加
- レコード名の二重化を疑う
- DNS反映待ちの場合は時間を置いて再確認
3) DMARCが fail のとき（ここが一番ハマる）
DMARCが見ているのは「整合（アライメント）」
DMARCはこう判断します。
- SPFが通っているか、DKIMが通っているか
- さらに、Fromのドメインと一致（または許容範囲で整合）しているか
つまり、よくある失敗がこれです。
- SPFはpass（でもReturn-Path側だけ）
- DKIMはpass（でも署名ドメインがFromと違う）
- 結果、Fromと整合しない → DMARC fail
対処の方向性（WordPressフォームで一番効く）
- Fromを「認証済みドメイン配下の固定アドレス」にする
- 例：
no-reply@mg.example.com
- 例：
- 返信先はFromにしない（ここが事故ポイント）
- Reply-Toにフォーム送信者を入れる
WordPressフォーム通知で“鉄板”の設計（これで崩れにくい）
フォーム通知が迷惑メールに入りやすいのは、From設計がブレるからです。
最も安全なのはこれ。
- From：自分の認証済みドメインの固定アドレス（例：
no-reply@mg.example.com） - Reply-To：フォーム送信者のメールアドレス（返信はここに返す）
- 送信方法：SMTPまたはAPI送信で統一（
wp_mailの素送信を避ける）
この形にすると、認証の整合が崩れにくく、到達率が安定します。
10分チェックリスト（最短で改善したい人向け）
- Gmailの「メッセージのソース」で
Authentication-Resultsを確認 spf=passになっているdkim=passになっているdmarc=passになっている- Fromが「認証済みドメイン配下の固定アドレス」になっている
- フォーム送信者はFromではなくReply-Toに入れている
- SPF（
v=spf1）が1本に統合されている
よくある質問
Q. SPF/DKIMはpassなのに、迷惑メールに入るのはなぜ？
A. 代表例は DMARCの整合が崩れている（Fromが一致していない） パターンです。
Fromを固定（認証済みドメイン配下）にして、返信はReply-Toに回すと改善しやすいです。
Q. dmarc=none って問題？
A. DMARCレコード自体がない／評価していない可能性があります。
最低でも p=none で置いておくと、運用の土台ができます（いきなりrejectは非推奨）。
まとめ
- Gmailなら 「メッセージのソース」→
Authentication-Resultsで一発確認 - まずは
spf / dkim / dmarcが pass になっているかを見る - FAILした箇所で、直す場所がほぼ決まる
- WordPressフォーム通知は From固定＋Reply-To運用 が鉄板
関連記事
- SPF/DKIM/DMARCとは？メールが届かない・迷惑メールを防ぐ「認証」の基礎（初心者向け）
- WordPressフォームが迷惑メールに入る原因と対策（SMTP・From・認証の崩れ）
- Mailgunの送信ドメインがActiveにならない原因と対処（DNS/SPF/DKIM）
- WordPressメール送信「エラー別」トラブル集（SMTP・API送信）
この記事は、以下のまとめ記事で全体像を解説しています。
▶ メールが迷惑メールに入る理由と対策【完全まとめ】
コメント