自社ドメインのメールが届かないのは設定の問題

WordPressでサイトを作って納品した後、お客さんから「メールが届いていないと言われた」という連絡が来ました。

受信はできている。でも送れない。あるいは届いていても迷惑メールに入っている。こういう症状は、ドメインのメール認証設定がきちんと揃っていないと起きます。特にWordPressとGoogle Workspaceを同じドメインで組み合わせているケースは、設定が2か所に分散して詰まりやすい。

DKIMが二重に入っていた

そのケースで実際に起きていたのは、DKIMの設定が「サーバー側」と「Google Workspace側」の両方に入っていた状態でした。

制作者がWP用にサーバーのDKIMを設定した。顧客は顧客でWorkspaceのDKIMを自分で設定していた。どちらかを消すと、片方のメール送信が壊れる。サーバー側を消せばWorkspaceから送れるようになるが、HPからの自動返信が届かなくなる。消せない、残せない、という板挟みです。

DKIMはセレクタが別々なら、同じドメインに複数登録できます。なので「競合を消す」ではなく「別セレクタで共存させる」方向で整理します。ただこれを知らずに片方を削除しようとすると、確かに詰まる。

別の確認で、そのドメインのSPFレコードを見ると、こう書かれていました。

v=spf1 a:xxx.sakura.ne.jp include:_spf.google.com mx ~al

最後の ~al が ~all の誤記です。スペルが一文字足りない。これだとSPFが正しく機能しません。

AIに「このSPFレコードを分析して」と頼んだら一発で見つかりました。

このSPFレコードを確認してほしい。さくらのサーバーとGoogle Workspaceを両方使っている構成で、メールが届かないと言われている。

返ってきた中に「~al は誤りです。~all に修正してください」と書いてあった。見た目は分かりにくいので、自分でも見落としていたところです。

メール認証は、この三つがそれぞれ別の役割を持っています。

ひとつでも抜けると、Gmailなどの受信側が「怪しいメール」と判断しやすくなります。DMARCが設定されていないと、なりすましを疑われやすい。SPFがsoftfail（~all）のままで終わっていると、迷惑メール扱いされることがある。

三つを揃えると、受信サーバーが正当なメールと認識しやすくなります。

ヘッダ解析をやっていて気づいたのが、同じドメイン・同じサーバー経由なのにSPFの結果が「pass」と「softfail」に分かれていた件です。

ロリポップの内部プロキシが、mx-proxy101 と mx-proxy103 で異なっていました。宛先アドレスが違うと内部経路が変わる。転送設定が片方だけにかかっていたためで、転送を通るとSPFが再評価されてsoftfailになっていた。

こういうのはSPFレコードを見るだけでは分からなくて、ヘッダを一行ずつ追わないと出てきません。「設定は合っているのに届かない」と言われたら、まずヘッダを確認する、が先です。

HPからの自動返信メールが迷惑メールに入るケースは、WPのフォームプラグインがサーバーのSMTPを経由して送っているのに、そのサーバーがSPFに含まれていない、という組み合わせでよく起きます。

送信経路が増えるたびにSPFの許可リストを確認する必要があります。

このWPサイトに問い合わせフォームがある。自動返信が迷惑メールに入ると言われている。SPFには何を入れれば良いか整理してほしい。

AIにこう頼むと、使っているホスティングサービスとフォームプラグインの構成から、必要な include を列挙してくれます。ここを端折ると、後から「なぜかまた届かなくなった」が起きやすい。

設定したら終わりではなくて、実際に送ってヘッダを確認する手順が要ります。

Gmailで受け取ったメールのヘッダを開くと、SPF・DKIM・DMARCそれぞれの認証結果が記録されています。「pass」が並んでいれば正しく機能している。「fail」や「none」が混じっていたら、対応するレコードを見直す。

ここまでやって初めて「設定できた」と言える状態です。DNS反映には数時間かかることもあるので、変更直後は少し置いてから確認します。