mail-tester 7/10の真因はSPF includeのTEMPERROR。1行消して10/10に
Google Workspace + Xサーバー環境でmail-testerを回すと7/10になり「You are not allowed to use one of your sender email addresses (-3)」と指摘される。SPFレコード内のincludeがDNS lookupタイムアウトしている時のTEMPERRORが真因で、不要なincludeを1行削るだけで10/10になる、移行直後によくある落とし穴。
DNSをXサーバーからCloudflareに移した直後、念のため mail-tester.com でメール認証スコアを計測したら 7/10 が出ました。「Good stuff. Your email is almost perfect」というメッセージとともに、減点項目に「You are not allowed to use one of your sender email addresses (-3)」。
掘り下げると、犯人は SPFレコード内の include:spf.sender.xserver.jp で、これがDNS lookupタイムアウトを起こしてSPF評価全体がTEMPERRORと判定されていました。Web移行とセットでSPFレコードも簡素化したら、1行消すだけで10/10まで届きます。
出発点: 7/10とDMARC警告
mail-tester 7/10の評価内訳。
| 項目 | 判定 |
|---|---|
| SpamAssassin likes you | ✓ |
| You are not allowed to use one of your sender email addresses | -3 |
| Your SPF signature is valid | ✓ |
| Your message passed the DMARC test | ✓ |
| Your hostname is assigned to a mail server | ✓ |
| Your message could be improved | △ |
| You’re not blocklisted | ✓ |
| No broken links | ✓ |
不思議なのは「SPF signature is valid」「DMARC test passed」と同時に「-3 sender email addresses」が出ているところ。SPFもDMARCもpassしているなら、なぜ「許可送信元ではない」と言われるのか。
-3を開いて初めて分かるTEMPERROR
詳細を展開すると、こう書かれていました。
[SPF] <own-domain> does not allow your server <google-smtp-ip> to use <user>@<own-domain>そして下の方のVerification detailsに、決定的な行が。
spfquery --scope mfrom --id <user>@<own-domain> --ip <google-smtp-ip> --helo-id <google-smtp-host>:
temperror
<own-domain> ... spf.sender.xserver.jp: Time-out on DNS 'TXT' lookup of 'spf.sender.xserver.jp'temperror。SPF評価で spf.sender.xserver.jp のTXTレコードを引きにいったらDNS lookupがタイムアウト。SPF評価全体が temperror (一時的エラー) で完了できなかった、という結果。
メール本文のAuthentication-Resultsでは dkim=pass、dmarc=pass、Received-SPF: Pass だったので、リアルタイムの受信判定はパスしていました。けれどmail-testerは独立にspfqueryを走らせて、SPFの解決可能性を厳しくチェック。タイムアウトするincludeが含まれていると -3。
なぜTEMPERRORが起きたか
問題のSPFレコードはこういう状態でした。
v=spf1 +a:sv<NNNNN>.xserver.jp +a:<own-domain> +mx include:spf.sender.xserver.jp include:_spf.google.com ~all各エントリの役割と、Web移行後の状況。
| エントリ | 役割 | 移行後の状況 |
|---|---|---|
+a:sv<NNNNN>.xserver.jp | Xサーバー AレコードIPを許可 | Xserverから直接送信していないので不要 |
+a:<own-domain> | apex AレコードIPを許可 | 移行でapexがCF PagesのAnycast IPに変わり、意図せず広い許可になっている |
+mx | MX (SMTP.GOOGLE.COM) を許可 | include:_spf.google.com で網羅されるので冗長 |
include:spf.sender.xserver.jp | Xサーバー SPFサブドメインを取り込み | DNS lookupタイムアウト = TEMPERRORの犯人 |
include:_spf.google.com | Google Workspace SPFを取り込み | 必須 |
~all | 列挙外はsoft fail | 必須 |
spf.sender.xserver.jp のTXTが引けない状況は、Xサーバー側のSPFサブドメインの応答が止まっているのか、解決経路に問題があるのか、原因はいくつか考えられます。けれど そもそも使っていないincludeを残し続ける必要がないので、削除一択。
ついでに +a:<own-domain> も問題です。Web移行でapexのAレコードがCF PagesのAnycast IPに変わったため、「Cloudflare上の任意のIPが <own-domain> を名乗ってメール送信できる」という意図せぬ広い許可になっていました。これも削除。
1行に簡素化
メール送信ルートを棚卸しすると、このサイトのケースでは下記でした。
- Google Workspace経由の手動 / システムメール送信
- Xサーバーはcatch-all受信のみ (= 中継、
<own-domain>を名乗って外部送信しない) - Sendgrid不使用 (DKIM CNAMEは過去の遺物として残存、別タスクで削除予定)
- WordPress廃止済 (Web移行でAstroに書換、PHPからのシステムメール送信なし)
つまり実際の送信元はGoogle Workspace 1つ。SPFはこれで足ります。
v=spf1 include:_spf.google.com ~allCF DNSでTXT <own-domain> のSPFレコードを編集して、コンテンツをこの1行に置換。保存即時で世界に伝播 (CF DNSの権威DNSは即時更新、ローカルキャッシュはTTL 300秒以内)。
再計測で10/10
5分後にmail-testerを再実行。
| 項目 | 判定 |
|---|---|
| SpamAssassin likes you | ✓ |
| You’re properly authenticated | ✓ (前回の -3が解消) |
| Your message could be improved | ⚠ 警告のみ、減点なし |
| You’re not blocklisted | ✓ |
| No broken links | ✓ |
総合10/10。「Wow! Perfect, you can send」。
「Your message could be improved」の警告は List-Unsubscribe headerなしの指摘で、これはnewsletter等の大量配信メール想定の要求項目。手動メール送信中心の運用では不要 (false positive) で、減点もありません。
転送と送信の違いに注意
ハマりやすいポイント。「Xサーバーでcatch-all転送している場合、SPFに include:spf.sender.xserver.jp を残すべきでは?」と考えるかもしれません。実は不要です。
転送 (forwarding) はSMTPリレーで、Xサーバーは中継しているだけ。
外部 (例: [email protected])
↓ 元メール (From: [email protected])
Google Workspace 受信
↓ Default Routing で SMTP リレー
Xサーバー SMTP
↓ 転送設定で <user>@<own-domain> へ
Google Workspace 再受信この経路で Fromヘッダーは終始元の送信者 ([email protected]) のまま。Xサーバーは <own-domain> を名乗ったメールを新規発信していません。SPF評価は元の送信者 (gmail.com) のドメインに対して行われ、<own-domain> のSPFレコードとは無関係。
つまりcatch-all転送が動いているケースでも、<own-domain> のSPFにXサーバー関連エントリは不要です。
Web移行とSPF見直しはセットで
今回の経験から得られるSOP。
DNSを別の権威DNSに移行する時、必ずSPFレコードを棚卸しする。チェック項目:
+a:<own-domain>がある → Web移行でapexのAレコードが変わった可能性 → 削除include:<old-provider>がある → 移行で旧プロバイダのメールサービスを使わなくなった可能性 → 削除+mxがある → 同じ意図のinclude:があれば冗長 → 削除- 不要なincludeやaが残っていないか → DNS lookupがSPF評価のレートリミット (RFC 7208で10回まで) を消費する、シンプルに保つ
移行直前にメール送信ルートの全件洗い出しを実施し、本当に使っている送信ルートだけがSPFに残る状態にすると、mail-testerも含めた認証スコアが綺麗に出ます。
mail-testerで7/10が出たら、まず -3セクションを開いてVerification detailsのspfquery結果を読む。TEMPERRORが出ていたら、SPFのincludeのDNS lookupが失敗している。Web移行を経た直後なら、不要なincludeやaエントリが残っている可能性が高い。1行消すだけで10/10まで行ける典型例です。