SPF 失敗の原因を調べて DNS を修正する方法

メールがバウンスし、ヘッダーに spf=fail と記録されています。550 5.7.1 または 550 5.7.26 が表示され、顧客は届かなかった返信を待っています。

SPF の失敗はコンテンツの問題ではなく、DNS 認証の失敗です。受信メールサーバーが SPF レコードを確認し、送信 IP が許可リストにないと判断したため、迷惑メールフォルダーに届く前にメッセージを拒否した可能性があります。

2024 年二月以降、Google と Yahoo は未認証メールを単に疑わしいと判定するだけでなく、プロトコルレベルで拒否する場合があります。このガイドでは、表示されたエラーコードの意味、ヘッダー内で失敗した IP を見つける方法、SPF 失敗の多くを解決できる三つの DNS 修正を説明します。推測に頼らず、該当する修正から始めましょう。

初めて独自ドメインにメールを設定する場合は、障害を調べる前に基本の DNS 構成を整えてください。SPF の問題は、不完全な初期設定に起因することがよくあります。

SPF の失敗とは

受信メールサーバーがドメインの Sender Policy Framework レコードを評価し、送信 IP アドレスが許可されていないと判断すると、SPF が失敗します。SPF はドメインの DNS TXT レコードとして公開され、代理送信を許可する IP アドレスとメールサービスを列挙します。検証に失敗すると、サーバーはメッセージを拒否する場合 (hard fail) と、疑わしいものとして受け入れる場合 (soft fail) があります。DMARC ポリシーでは、どちらも失敗として扱われます。

SPF が検証するのはエンベロープ送信者、つまり SMTP ハンドシェイクで使われる MAIL FROM アドレスです。受信者に表示される "From" ヘッダーではありません。障害箇所を追う際、この違いが重要です。

SPF の結果	レコード修飾子	メールへの影響
Hard Fail (`fail`)	`-all`	IP は未許可です。受信サーバーがポリシーに従って拒否する場合があります。
Soft Fail (`softfail`)	`~all`	IP は未許可です。メールは受け入れられても印を付けられ、迷惑メールに入ることがあります。
PermError	構文エラーまたは 10+ 回の参照	レコードが無効です。正当な通信を含む各送信者で SPF が失敗する可能性があります。
Pass	`-all` (IP を記載)	IP は許可済みです。通常の配信処理が可能です。

変更する前にエラーコードを確認する

メールサーバーによって SPF 失敗時の SMTP コードは異なります。エラーコードから、受信側の判断と理由を把握できます。550 5.7.26 を一般的な 550 5.7.1 と同様に扱うと、診断に時間がかかります。DNS レコードを変更する前にコードと原因を対応付けてください。

プロバイダー	エラーコード	意味
Google / Gmail	`550 5.7.26`	未認証メールがブロックされました。合格した SPF または DKIM がありません。Google が 2024 年二月に導入した大量送信者要件に基づく一般的な拒否です。
Microsoft / Outlook	`550 5.7.515`	送信者の身元が認証されていません。SPF または DKIM の失敗です。"Access Denied" はコンテンツの検査前に発生する場合があります。
一般的な受信側	`550 5.7.1`	リレーアクセスが拒否されました。ポリシー拒否の一般的なコードであり、送信 IP が十分に信頼されていないことを示します。
Soft Fail (受け入れ)	ヘッダーに `~all`	SPF は失敗しましたが、ポリシーは寛容です。直接拒否されず、迷惑メールに入る場合があります。

ステップ 1: ヘッダーで失敗した IP を見つける

SPF の失敗を起こした IP を推測しないでください。バウンスしたメッセージまたはバウンス通知の生ヘッダーを開き、Authentication-Results を検索します。このヘッダーには、受信側が評価した IP と判定結果が記載されています。

Authentication-Results: mx.google.com;
   spf=fail (google.com: domain of team@example.com does not designate
   192.0.2.55 as permitted sender)

ここには二つの調査情報があります。送信 IP (192.0.2.55) と、検証対象のドメイン (example.com) です。次に、その IP の所有者を特定します。

最近導入した SaaS ツールか (HubSpot、Zendesk、Shopify)
自社の Web サーバーか (WordPress、cPanel)
メール転送サーバーか (後述の転送の落とし穴を参照)

続いて、現在の SPF レコードを簡単に確認します。

dig +short txt yourdomain.com | grep spf

v=spf1 で始まる行が複数あれば、考えられる問題の一つが見つかりました。

ステップ 2: よくある三つの SPF 修正

SPF 失敗の多くは、プロバイダーの include 不足、レコードの重複、10 回の DNS 参照上限超過のいずれかです。ステップ 1 の結果に合う修正を選んでください。

修正 1: Include の不足 (プロバイダーの欠落)

HelpScout、HubSpot、Zendesk、Shopify のトランザクションメールなど、新しいメールツールを追加したのに DNS を更新していません。サービスが未許可の IP を使って代理送信します。新しいプロバイダーの導入後によくある SPF 失敗の原因です。

失敗するレコード:

v=spf1 include:spf.trekmail.net -all

合格するレコード (HelpScout の追加後):

v=spf1 include:spf.trekmail.net include:helpscoutemail.com -all

プロバイダーの文書で必要な SPF include 文字列を調べます。新しいレコードを作らず、既存の SPF TXT レコードに追加してください。実際に送信に使う各サービスを記載する必要があります。

修正 2: 二重レコード (重大な構文エラー)

一つのドメインに設定できる SPF レコードは一つです。新しいツールを既存レコードへ統合せず、二つ目の TXT レコードとして追加すると、受信側には競合するポリシーが見え、両方が無効になります。その結果 PermError が発生し、以前は正常に配信できたメールを含め、ドメインからの各メールで hard SPF fail になる可能性があります。

誤り、二つの個別レコード:

v=spf1 include:spf.trekmail.net -all
v=spf1 include:_spf.google.com -all

正解、一つに統合:

v=spf1 include:spf.trekmail.net include:_spf.google.com -all

DNS プロバイダーへログインし、一つを残して他の SPF TXT レコードを削除し、一行に統合します。二重レコードによる PermError は、修正するまで各送信者の SPF に影響する可能性があります。

修正 3: 10 回の参照上限 (構成上の失敗)

RFC 7208 は SPF 評価を 10 回の DNS 参照に制限し、サーバーが DNS 増幅攻撃に利用されることを防ぎます。include、a、mx などの機構は上限に数えられます。プロバイダーが別のプロバイダーのレコードを参照する、入れ子の include も対象です。

10 回を超えると PermError が発生し、各送信者で SPF が失敗する可能性があります。レコードをたどり、現在の参照数を確認します。

dig +short txt yourdomain.com

include、a、mx の各機構を数え、プロバイダーごとに入れ子の include もたどります。上限を超えている場合、二つの方法があります。

送信者をサブドメインに分けます。大量送信するマーケティングツールを marketing.yourdomain.com へ移します。このサブドメインには、メインドメインのレコードとは別に、新しい 10 回の参照枠があります。
レコードをフラット化します。include の連鎖を、解決先の実際の IP に置き換え、ip4: または ip6: を使います。これらは参照回数に入りません。ただし、プロバイダーが IP を変更したときは手動更新が必要です。

空参照の上限にも注意してください。チェーン内で二つを超える参照が NXDOMAIN を返す場合、たとえば include:spf.gogle.com という誤記があると、RFC 7208 §11.1 に基づきレコードが無効になります。入れ子になったプロバイダーの include に一つ誤記があるだけでも、SPF 評価全体に影響する可能性があります。

転送の落とし穴: 正当なメールで SPF が失敗する理由

DNS 構成に問題がなくても SPF は失敗します。卒業生用アドレス (alice@university.edu) に送信し、そのメールが Gmail (alice@gmail.com) へ自動転送される例です。Gmail には大学のサーバー IP から届きます。自社の SPF レコードはその IP を許可していないため、正しく設定していても SPF は失敗します。

経路は、自社サーバー -> 大学のサーバー -> Gmail です。Gmail は最後のホップを評価します。SPF は元の送信 IP だけを許可するため、転送による失敗を SPF だけで修正することはできません。転送サーバーが入ると IP 検証が一致しなくなります。

適切な補完策は DKIM です。DKIM はメッセージ本文とヘッダーに暗号署名します。通常、転送サーバーは本文を変更しないため、DKIM 署名はリレーホップ後も有効な場合があります。SPF が失敗しても、有効な DKIM 署名があれば DMARC で認証を維持できます。

インフラレベルの転送を運用し、SPF と互換性のある書き換えが必要なら、Sender Rewriting Scheme (SRS) を理解しておくと役立ちます。転送サーバーがエンベロープ送信者を書き換え、最終宛先で SPF を通過できるようにする仕組みです。転送に関する広範な配信問題は、メール転送の設定と修正ガイドで説明しています。

次へ進む前に修正を検証する

DNS レコードを更新したら反映を待ちます。多くのプロバイダーでは通常 5 から 30 分ほどですが、一部では数時間かかる場合があります。完了と判断する前に、修正が実際に反映されたか確認してください。

Gmail アドレスへテストメールを送り、生ヘッダーを開いて Authentication-Results を検索します。期待する結果は次のとおりです。

Authentication-Results: mx.google.com;
   spf=pass (google.com: domain of team@example.com designates
   192.0.2.55 as permitted sender)

spf=fail または spf=softfail が残っている場合、修正がまだ反映されていないか、レコードに問題が残っています。ヘッダーの IP と更新したレコード内の IP を比較し、一致していることを確認します。

レコードは直接確認することもできます。

dig +short txt yourdomain.com

v=spf1 で始まるレコードが一つだけで、使用する送信サービスが記載され、末尾が -all (hard fail) または ~all (soft fail) であることを確認します。

複数ドメインの SPF を管理する

一つのドメインなら、SPF 管理は通常一度で済みます。include を追加し、重複を統合し、参照数を修正します。しかし、それぞれ独自の SPF レコードと SaaS プロバイダーを持つ 10、50、500 ドメインのメールを管理する場合、SPF 失敗を個別に手作業で調べることは大きな運用負担になります。

方法	必要な SPF レコード	IP レピュテーションの管理者
DIY / BYO SMTP	各プロバイダーを記載した完全なレコード	利用者が手動で管理
TrekMail Managed SMTP	`v=spf1 include:spf.trekmail.net -all`	TrekMail: IP ローテーション、レピュテーション、DKIM アライメント

TrekMail のマネージド SMTP は $3.50/mo からの Starter で利用でき、構成をドメインごとに一つの include へ簡素化します。TrekMail が IP ローテーション、バウンス監視、DKIM アライメント、基盤となる配信インフラを担当します。Agency プラン ($23.25/mo) では、個々のレコードで SPF エラーを追う代わりに、標準 DNS テンプレートを顧客ドメインへ適用できます。

マネージド配信を実際に試す場合は、14-day 無料トライアルを利用できます。

SPF 失敗の要点

SPF の失敗は、受信サーバーが DNS を確認し、送信 IP を見つけられず、ポリシーを適用したことを意味します。Hard fail (-all) は拒否、soft fail (~all) は迷惑メールへの配置につながる場合があります。PermError はレコードが壊れており、修正するまで各送信者で SPF が失敗する可能性があることを示します。

次の順番で修正します。