SPF・DKIM・DMARCは何のために設定するのか
サイトのお問い合わせフォームから送信されたはずの通知メールが、担当者の受信箱に届かない。送信記録は残っているのに、迷惑メールフォルダにも見当たらない。あるいは、特定の相手にだけ届かない。原因を探そうにも、どこを見ればよいのか分からない——という状況で読まれることを想定した記事です。
先に結論
- SPF・DKIM・DMARC は、そのメールが名乗っているドメインから本当に送られたかを受信側が確かめるための仕組みです
- フォーム通知が届かない原因の多くは、送信元アドレスに自社ドメインを使いながら認証が通っていないことにあります
- 設定するのは WordPress の中ではなく、DNS(ドメインの住所録)と送信サーバーの側です
- 調べる順番は決まっています。届いたメールのヘッダーを見れば、どこで落ちたかが書かれています
フォーム通知が届かない、という相談の中身
「送信完了と画面に出るのに、メールが届かない」という相談は、実は二つの状態が混ざっています。そもそも送信されていないのか、送信はされたが受信側に届いていないのか。この二つは対処がまったく違います。ここを分けないまま設定をいじると、直っていないのに直った気になります。
WordPress の送信ログに「成功」と残っていても、それは受信を意味しません。WordPress が記録しているのは、あくまで「送信サーバーに渡すところまでは成功した」という事実です。その先で受け取りを拒否されたか、迷惑メールに振り分けられたかは、WordPress からは見えません。
近年、Gmail や Microsoft 365 といった大手のメール事業者が、送信ドメイン認証を満たさないメールの扱いを厳しくしています。以前は届いていた設定のまま放置していたサイトで、ある時期を境に通知が届かなくなる。そういう相談が増えている背景には、この変化があります。
ですからまず、サーバーのエラーログを見て、送信処理そのものが失敗していないかを確かめます。ログの場所と読み方はエラーログはどこにあり、どう読むかで扱っています。ここで送信処理のエラーが出ていれば、認証の話に進む前にそちらが原因です。
なぜ「なりすまし」が成立してしまうのか
メールの差出人欄は、封筒に手書きする差出人と同じです。誰でも好きな名前と住所を書けます。書いた内容が正しいかどうかを、封筒そのものは保証しません。だから受信側は、差出人欄に書かれた文字列だけでは本物かどうかを判断できません。
ここにフォームプラグインの初期設定が絡みます。多くのプラグインは、通知メールの送信者アドレスに自社ドメインのアドレスを入れる形が既定になっています。見た目は自然です。しかし実際にメールを送り出しているのは、レンタルサーバーの送信機能です。
つまり、自社ドメインとは無関係なサーバーから、自社ドメインを名乗ったメールが出ていく形になります。受信側から見れば、これは第三者によるなりすましと区別がつきません。差出人を偽装した迷惑メールと同じ形をしているため、静かに捨てられるか、迷惑メールフォルダに入ります。これがフォーム通知が消える、もっとも典型的な構図です。
三つの仕組みは、それぞれ別の質問に答えている
SPF・DKIM・DMARC は、どれか一つを選ぶものではありません。三つとも別々の質問に答える、役割分担の関係にあります。
SPF — このサーバーから送ってよいことになっているか
SPF は「このドメインのメールは、これらのサーバーから出ます」という一覧を DNS に書いておく仕組みです。受信側は、実際に接続してきたサーバーが一覧に載っているかを照合します。載っていなければ、名乗りと実態が食い違っていると判断されます。
DKIM — 途中で差し替えられていないか(電子署名)
DKIM は、送信側がメールに電子署名を付ける仕組みです。署名を検証する鍵は DNS に公開しておきます。受信側はその鍵で署名を確かめ、確かにそのドメインが署名したこと、そして本文や件名が途中で書き換えられていないことを確認します。
DMARC — 認証に失敗したらどう扱うか
DMARC は、SPF と DKIM の判定結果をどう扱うかという方針を、ドメインの持ち主が宣言するものです。あわせて、判定結果のレポートをどこへ送ってほしいかも指定できます。方針には段階があり、何もしない(監視のみ)、迷惑メール扱いにする、受け取りを拒否する、という強さの違いがあります。準備が整わないうちに強い方針を宣言すると、正規のメールまで止まります。
自分で確かめる手順
設定値を先に決めようとせず、まず現状を読みます。手順は次のとおりです。
- 自分宛に一度フォームから送信し、届いたメールを開く
- メールのヘッダー(ソース)を表示する
Authentication-Resultsで始まる行を探す- その行に、spf・dkim・dmarc がそれぞれ pass か fail かで書かれている
Gmail ならメニューの「メッセージのソースを表示」、Outlook なら「メッセージの詳細を表示する」（従来の Outlook は「ファイル → プロパティ」のインターネット ヘッダー）から見られます。ヘッダー全体は数十行から数百行ありますが、読むのはこの数行だけで足ります。
fail と書かれていれば、同じ行にどのドメインについて、どのサーバーからの送信で失敗したかも併記されています。たとえば SPF が fail で、そこに書かれている送信元がレンタルサーバーのものであれば、前の節で述べた構図がそのまま起きています。
そもそもメールが一通も届かない場合は、ヘッダーを読むこともできません。その場合はサーバー側のメールログと、WordPress のエラーログを先に確認します。届いた上で迷惑メール扱いなのか、そもそも出ていないのかで、見る場所が変わります。
直し方は三つに分かれる
認証が通っていないと分かった場合、対処の方向は大きく三つです。
- 方針A: 通知メールの送信者アドレスを、実際に送っているサーバー側のドメインに合わせる。最も手軽ですが、受け取った人が返信したときの宛先をどうするかを別途決める必要があります
- 方針B: メール配信サービスを経由して送る。サービス側の案内に従って、DNS に SPF と DKIM の情報を追加します
- 方針C: 自社で使っているメールサーバーを経由して送る設定にする。社内メールと同じ経路になるため、認証はそちらの設定を引き継ぎます
方針 B と C はいずれも DNS の変更を伴います。DNS はドメイン全体の住所録なので、記述を一文字間違えると、フォーム通知どころか既存のメールまで届かなくなります。
🚨 DNS レコードの書き換えは、サイトだけでなく社内メール全体に影響します。変更前の内容を必ず控えてから触ってください。
DMARC を新たに設定する場合は、監視だけの方針から始めます。しばらくレポートを受け取り、自社ドメインを名乗って送っているものが他にないか(基幹システムの通知、外部サービスからの一斉配信など)を把握してから、方針を強めます。順番を逆にすると、把握していなかった正規の送信が止まります。
着手する前に、自社の DNS を誰が管理しているかを確認しておきます。ドメイン登録業者の管理画面にある場合と、レンタルサーバー会社側にある場合があり、担当窓口が分かれていることも珍しくありません。
届かない原因が、認証ではないこともある
ここまで認証の話を続けてきましたが、届かない理由が他にあることも同じくらいあります。送信先アドレスの打ち間違い、受信側の振り分けルール、メーリングリスト経由の転送で署名が壊れるといったものです。
技術的な側では、プラグインの更新が途中で止まっていて送信処理そのものが動いていない例があります。更新が失敗したときに何が起きているかを押さえておくと、この可能性を早く外せます。
また、サーバー側で PHP のバージョンが上がったあと、古い送信ライブラリが動かなくなって通知だけが止まる、という形もあります。サイトは普通に表示されるため気づきにくく、数日経ってから発覚します。バージョンを上げると古いサイトが止まる理由と同じ構図です。
ですから、認証の設定に飛びつく前に、送信されているのかどうかを先に確定させます。切り分けの順番を誤ると、DNS を書き換えて満足したものの、実際は送信処理が止まっていただけだった、ということが起こります。
送信ドメイン認証は、メールを速く届けるための仕組みではなく、自社の名前を他人に勝手に使わせないための仕組みです。フォーム通知が届くようになるのは、その副産物にすぎません。自社のドメインが今どう名乗られているかを一度確かめておくと、次に何かが届かなくなったときの調べ方が変わります。
