SPF設定で10回のDNS参照上限を避ける方法

送信元が一つなら、SPF設定は問題なく動きます。そこへGoogle Workspace、Mailchimp、Zendesk、トランザクションAPIを加えると、Microsoftから550 5.7.515が返ることがあります。導入時は簡潔だったレコードが10回の参照上限を超え、送信メールの認証が安定して通らなくなったためです。

これが落とし穴です。SPFにはプロトコル上の厳格な上限があり、多くのチームは三つ目か四つ目のサービスを加えた時点で到達します。さらにinclude:を貼るという一般的な対処は、必要なときほど機能しません。構文の基本はメール用SPFレコードのガイドをご覧ください。この記事では、複数の送信元に対応し、事業者変更にも耐え、四半期ごとの書き直しを避ける設計を扱います。

複数の送信元でSPF設定が壊れる理由

RFC 7208では、レコードごとのSPF評価を10回のDNS参照までに制限しています。include、a、mx、exists、redirectはすべて数えられ、再帰的な参照も対象です。事業者のincludeが内部でさらに三つを参照すれば、それらも消費します。11に達すると受信側がPermErrorを返し、メールを拒否する場合があります。

典型的な流れは同じです。最初はincludeが二つだけで余裕があります。マーケティングがHubSpot、サポートがFreshdesk、開発がアプリ通知用のSendGridを加えます。参照チェーンは想定より深く、突然12回となり、Googleが各メッセージに550 5.7.26を返します。

メカニズム	参照を消費？	運用上の注意
`include:`	はい、入れ子も含む	事業者で一般的だが深さを予測しにくい
`ip4:` / `ip6:`	いいえ	管理下の固定送信元に使用
`mx`	はい	過剰利用されがちで、可能ならip4に置換
`a`	はい	SPFには非効率で、ip4を優先
`ptr`	はい	非推奨なので使用しない
`redirect`	はい	別ドメインのレコードへ評価を移す
`-all` / `~all`	いいえ	ポリシー終端として一つ入れる

計算は難しくありませんが、障害まで見えにくいのが問題です。複数送信元のSPFはコピーではなく設計から始めます。

追加前にSPFレコードを監査する

最初に不要なものを取り除きます。数か月、数年前に解約したサービスのincludeが残るドメインは多く、すべて参照枠を浪費します。追加より先に整理してください。

公開されている内容を確認します。

dig txt yourdomain.com +short

次に各includeの深さをたどります。

dig txt _spf.google.com +short
dig txt spf.protection.outlook.com +short

DMARC集計レポートとも照合します。事業者のIPから実際に送信されていなければ、そのincludeは不要です。利用状況を確認してから削除します。

監査ですぐ実行できる三つの改善:

mxを実際のIPを示すip4:に置き換え、一回分を節約する。
利用を終えたサービスのincludeを削除する。
SPFの重複を確認する。同じドメインにv=spf1で始まるTXTが二つあると、直ちにPermErrorになる。

これだけで2-3回分を確保できる場合があります。詳しくはSPFレコード設定ガイドをご覧ください。

サブドメイン分割: 拡張できるSPF設計

複数送信元で10回の上限を避ける確実な方法は、サブドメインによる分割です。SPFは目に見えるFromではなくReturn-Pathドメインを評価します。企業メール以外をサブドメインへ移すと、各送信経路に10回の新しい予算ができます。

構成例は次のとおりです。

ルートドメイン、人が送るメールのみ

ルートは簡潔に保ち、主要メールボックス事業者だけを置きます。

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

includeは一つ、参照も一回です。マーケティングが新しいツールを加えても、役員のメールを巻き込みません。

マーケティング用サブドメイン、キャンペーンとニュースレター

; news.example.com
v=spf1 include:spf.hubspot.com include:servers.mcsv.net -all

HubSpotとMailchimpはルートではなくnews.example.comの予算を使います。このサブドメインが制限されても企業メールは継続しやすくなりますが、評価の関連付けは受信側によって異なります。

サポート用サブドメイン、チケットシステム

; help.example.com
v=spf1 include:mail.zendesk.com -all

トランザクション用サブドメイン、通知と領収書

; alerts.example.com
v=spf1 include:amazonses.com -all

Zendeskがsupport@help.example.comとして送信すると、受信側はhelp.example.comのDNSを確認します。ルートドメインのSPFは評価しません。これが分割の目的です。

従来の方法	新しい方法
すべての送信元をルートSPFへ詰め込む	ルートには主要メールボックス事業者だけを置く
一社の変更が全送信へ影響する	障害を該当サブドメインに限定する
全サービスで参照枠を共有する	各サブドメインに10回分を用意する
ツール追加のたびにSPFを書き換える	事業者変更に耐えやすい構成にする

SPFフラット化は最後の手段

すべてのメールを裸のドメインから送る必要があり、サブドメインを使えない場合はフラット化が選択肢です。事業者のincludeをIPへ展開し、参照を消費しないip4:として列挙します。動作しますが、保守が難しくなります。

危険なのは情報の陳腐化です。SaaS事業者はIPを変更します。SendGridが明日新しい範囲を追加しても、レコードが昨日のままならSPFが失敗します。毎日確認できない限り手動で行わず、事業者IPを監視してTXTを安全に更新する動的SPFサービスを検討してください。

フラット化は回避策であり、基本設計ではありません。まずサブドメイン分割を採用し、本当に他の方法がない場合だけ使います。

SPF設定を検証する

変更後は公開DNSが実際に返す内容を確認します。レジストラの画面、キャッシュされた表示、事業者UIの緑色表示だけに頼らないでください。ドメインへ直接問い合わせ、ホスト名ごとに有効なSPFが一つだけあることを確認します。

# Check the root record
dig txt example.com +short

# Check a subdomain
dig txt news.example.com +short

# Verify DMARC while you're at it
dig txt _dmarc.example.com +short

各ホスト名にはv=spf1で始まるTXTが一つ必要です。二つでも、現在のものと二年前の移行時の残骸でもいけません。

次にGmailへテストメールを送り、三点メニューから原文表示を選び、以下を探します。

SPF: PASS with IP [your sending IP]
DKIM: PASS
DMARC: PASS

FAILやSOFTFAILは設定上の問題を示すため、大量送信前に直します。ただしPASSだけで受信トレイ到達が保証されるわけではありません。送信者評価のシグナルで全体像を確認してください。

TrekMailが複数ドメインのSPFを簡素化する方法

一つのドメインでも面倒ですが、異なる事業者やDNS環境、過去の設定を持つ50の顧客ドメインでは大きな負担です。TrekMailは自身のSPF使用量を小さく予測しやすく保ち、他の送信元の余地を残します。

中心となるincludeはinclude:spf.trekmail.netです。現在の設計では一回の参照で、入れ子のredirectや予測不能な展開チェーンはありません。Microsoft 365は内部転送で2-3回を使う場合があり、Google Workspaceも地域で異なる可能性があります。必ず実際のDNSで検証してください。

個人創業者ならマーケティングツール追加後も簡潔に保ちやすく、チームなら導入時のDNSミスを減らせます。代理店はTrekMail includeを追加し、他社をサブドメインへ分ける共通テンプレートを使えます。上限リスクは減りますが、定期監査は必要です。詳しくは複数ドメインのメールホスティングをご覧ください。

TrekMailのDNSステータス確認はSPF競合を管理画面に表示し、本番障害の前に発見しやすくします。完全な設定はドキュメントの必須DNSレコードをご覧ください。

まとめ: SPFを一度正しく設計する

良いSPFは構文ではなく設計から始まります。使われないincludeを削除し、送信元をサブドメインへ分け、各経路に10回の予算を持たせます。ルートは一つのメール事業者、一つのinclude、一つの-allに保ち、画面ではなくdigで確認します。

TrekMailは現在、一つでも百でも定額の複数ドメインホスティング、簡潔なSPF include、共有ストレージ、DNS確認を提供しています。Nanoは10ドメインと持ち込みSMTPに対応し、カード不要で無料です。有料のStarterは$3.50/moからで、マネージドSMTPと14日間の試用が含まれ、カードが必要です。価格と条件は変わるため、trekmail.net/pricingで最新プランを確認してください。