SPFレコードの作成：送信元の整理とDNS参照数の管理

ドメインのSPFレコードを作成する目的は、必要な送信元を許可し、半年後に問題が起きるような複雑なDNS設定を避けることです。トラブルの始まりはたいてい同じです。サービスを追加し、さらに別のサービスを追加する。やがてMicrosoftから550 5.7.515、Googleから550 5.7.26が返され、夜11時にTXTレコードを調べることになります。

ここが落とし穴です。SPFは簡単そうに見えても、ルートドメインのレコードがあらゆる送信サービスの寄せ集めになると事情が変わります。再帰的なincludeが積み重なり、DNS問い合わせを伴う項がさらに評価されるだけでPermErrorになることがあります。企業ドメイン、顧客のメール基盤、複数ブランドの環境では、受信側の方針によってメールが届かなくなる深刻な問題です。ドメイン設定の全体像については、先に小規模企業向けのビジネスメールをご覧ください。

このガイドでは、日常の企業メールをルートドメインに置き、一斉配信やアプリのメールをサブドメインに分け、DNS問い合わせの予算を有限の資源として管理する設計を紹介します。SPFレコードを頻繁に全面改修する必要を減らせますが、定期的な確認と保守は引き続き必要です。

多くのSPFレコードが問題を起こす理由

SPFの評価では、DNS問い合わせを発生させる項の評価数に制限があります。すべてのDNSパケットを単純に数える制限ではありません。同じドメインにincludeを詰め込みすぎると、上限を超えてPermErrorになる可能性があります。構文が一見正しくても、受信側の方針によって拒否される場合があります。ただし、PermErrorなら必ず拒否されるわけではありません。

RFC 7208は、この点を明確に定めています。DNS問い合わせを伴う項にはinclude、a、mx、ptr、exists、redirectがあります。受信側は再帰的な評価も含め、その総数を10以内に制限しなければなりません。超過した場合は警告ではなく恒久エラーです。同じホスト名に複数のSPFレコードがある場合もPermErrorになりますが、SPFとは無関係なTXTレコードの併存は問題ありません。

そのため、よくある説明だけでは不十分です。一般的なガイドは、@のTXT値にすべての送信元をまとめるよう勧めます。整理されているように見えますが、実際にはルートドメインがニュースレター、サポートシステム、アプリ通知、営業ツール、個人のメールボックスの共通基盤になります。あるベンダーがincludeの連鎖を広げると、ルートドメイン全体のSPF評価に影響することがあります。

避けたい設計：ルートドメインのSPFレコードだけで、会社が使ってきたすべてのツールを許可する。

Googleの送信者向けガイドも、適切な認証とドメインの整合を重視しています。一斉配信では特に重要です。SPFは全体の一部にすぎませんが、SPFの不備が最初に目立つ問題になることは少なくありません。

本当の制約：DNS問い合わせを伴う10項の予算

厳格なルールは、SPFの評価でDNS問い合わせを伴う項を使える上限が10ということです。この予算は再帰的に計算されます。includeの評価中にさらに同種の項が評価されれば、それらも加算されます。DNS事業者を変えても、詰め込みすぎたSPF設計は解決しません。

予算に数えられる項：

• include
• a
• mx
• ptr（使用しないでください）
• exists
• redirect

予算に数えられない項：

• ip4
• ip6
• all

結果の得られないDNS問い合わせ、いわゆるvoid lookupにも注意が必要です。RFC 7208は、受信側がこれを二回までに制限することを推奨しています。include先の誤記がその余裕を消費することがあります。誤った参照によって推奨上限を超えると、別のPermErrorにつながる可能性があります。上限に達することと超えることは同じではありません。

四社、五社のサービスを経由して送るドメインなら、早い段階で予算を確認する価値があります。SPFそのものが脆いからではなく、ベンダーの再帰的な連鎖が設計を圧迫する可能性があるからです。

送信経路を分けてSPFレコードを作成する

堅実な設計では、人がやり取りするメールと、一斉配信やアプリのメールを分離します。主要なメールボックス事業者はルートドメインで使い、マーケティング、サポート、アプリ送信はサブドメインへ移します。ただし、SPF予算が分離されるのは、実際のMAIL FROMまたはReturn-Pathがそのサブドメインを使う場合だけです。表示上のFromアドレスを変えるだけでは分離できません。DMARCには整合したSPFまたはDKIM認証が引き続き必要で、厳格モードと緩和モードでは整合の条件が異なります。

設計の基本は次のとおりです。

1. ルートドメイン@は日常の対人メールに使う。
2. ニュースレター、サポート、取引通知などは、適切なエンベロープドメインを設定したサブドメインに分ける。
3. ホスト名ごとにSPFレコードは一つ。重複や古いSPFは削除し、無関係なTXTレコードは残してよい。

TrekMailの管理型送信で使うルートドメインの例です。適用前に現在の事業者の指示を確認してください。

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

includeが一つで方針も明確な、確認しやすい形です。それでも再帰的な評価と、実際の送信元の全体を調べる必要があります。

マーケティング用サブドメインの例：

v=spf1 include:servers.mcsv.net include:hubspot.com -all

これらの値はベンダー設定の例であり、共通の正解ではありません。MailchimpとHubSpotの最新の公式手順を確認し、独自MAIL FROMの対応状況や設定も調べてください。SPFが実際にmarketing.example.comを評価する場合に限り、その予算はexample.comの企業メールと分離されます。

TrekMailもこの構成に組み込めます。ドメイン設定の文書では基本のincludeとしてinclude:spf.trekmail.netが示され、DNSチェッカーは競合の発見を支援します。ただし、送信元全体の確認に代わるものではありません。メールボックスやDNSの設定中なら、TrekMailへのドメイン追加とDNS状態の確認を参照し、現在の設定要件に従ってください。

推測に頼らずSPFレコードを作成する手順

保守しやすいSPFを作るには、最初にすべての送信元を洗い出し、それぞれに適切なホスト名を割り当ててからTXTレコードを組み立てます。DNS画面ではなく、送信の担当と用途から始めましょう。不要なincludeがルートドメインに積み重なるのを防げます。

次の流れで進めます。

1. 自分のドメイン名で送信するサービスをすべて列挙する。
2. 各送信元を企業メール、取引通知、サポート、マーケティングに分類する。
3. 使用するホスト名と実際のMAIL FROMドメインを決める。
4. そのドメインに必要な、最小限で正しいSPF方針を使う。
5. ホスト名ごとにSPFのTXTレコードを一つ公開する。他の用途のTXTは別扱いにする。

その後、事業者の公式要件とエンベロープドメインの設定に合わせて実際のレコードを作成します。

TrekMailの管理型SMTPの例：

Type: TXT
Host: @
Value: v=spf1 include:spf.trekmail.net -all
TTL: 3600

Nanoプランやハイブリッド構成でTrekMailと持ち込みSMTPを併用する例です。両方の送信経路を本当に許可する必要がある場合に限ります。

Type: TXT
Host: @
Value: v=spf1 include:spf.trekmail.net include:amazonses.com -all
TTL: 3600

持ち込みSMTPでは、対応するエンベロープドメインに対して、実際に使うSMTP事業者を許可します。TrekMail、Amazon SES、他者のincludeを自動的に追加するわけではありません。SESでは特に、独自MAIL FROMに関する現在の要件を確認してください。ここで説明するNanoの方式では、送信に自分のSMTP事業者が必要です。本文で引用する提供例では、有料プランは月額$3.50からで管理型SMTPを含み、Nanoは常時無料とされています。有料プランには14日間の無料試用があり、クレジットカードが必要とされています。いずれも現在のプラン条件を確認してください。設定は持ち込みSMTP（BYO）とTrekMailの管理型SMTPで説明されています。

レコードの公開と検証

SPF値を作成したらTXTレコードとして公開し、公開DNSで取得できる回答を確認します。レジストラの画面、キャッシュされた管理画面、特定ツールの緑の表示だけを信用しないでください。次のコマンドは通常リゾルバーを使い、キャッシュされた回答を返す可能性があります。権威DNSサーバーへの直接問い合わせを保証するものではありません。有効なSPFが一つだけあることを確認し、キャッシュの有効期間も考慮します。

MacまたはLinux：

dig txt example.com +short

Windows：

nslookup -type=txt example.com

v=spf1で始まるSPF値が一つだけ見えるのが正しい状態です。複数のSPFや、現在のレコードと三年前の移行で残った古いレコードの併存は避けます。無関係なTXTレコードは、それだけではSPFの競合になりません。

簡単な確認項目：

• v=spf1で始まっている
• テストと送信元の完全な棚卸しが済んだら-allで終えている
• 本当に必要な送信元だけを含んでいる
• ホスト名ごとにSPFレコードが一つだけ存在する

事業者を変更する際は、古いMXとSPFが残りがちです。TrekMailのDNS文書もこのような競合に注意を促しています。自分の移行に必要な手順を確認してください。より広いプラットフォーム移行なら、独自ドメインのメールを作成する方法と複数ドメインのメールホスティングも参考になります。

よくあるSPFエラーと対処

よくある原因は、問い合わせ予算の超過、複数のSPFレコード、送信ドメインの誤り、includeの誤記です。送信元の対応関係が明確なら発見しやすくなります。場当たり的な設定では、原因調査にすぐ多くの手間がかかります。

次の二つの運用ルールが役立ちます。

1. 完全に管理できる固定アドレスの送信元にはip4を使う。SPFでDNS問い合わせを伴う項の予算を消費しません。
2. 十分な理由がない限り、マーケティングと経営陣のメールで同じエンベロープドメインを共用しない。表示上のFromだけではこの境界は作れません。

Googleの送信者向け文書が示す目標は、SPF単独ではなく、認証とドメインの整合です。SPFに合格しても、認証されたドメインが表示上のFromドメインと整合しなければ、方針を満たせない場合があります。DMARCは設定された厳格または緩和モードに従い、整合したSPFまたはDKIMを受け入れます。一斉配信の問題を調べる際は、Googleのメール送信者ガイドラインに関するFAQをご覧ください。

TrekMailで設定を簡素化できる場面

複数ドメインのSPF構成を整理したい場合、TrekMailは選択肢になり得ます。ここで紹介する運用上の特徴は、TrekMailのinclude、共有ストレージ、ユーザー単位ではない課金、組み込みのIMAP移行、プランと送信方式に応じた持ち込みSMTPまたは管理型SMTPです。機能の提供状況、上限、設定は現在のサービス条件に従います。includeが一つでも、再帰的な連鎖の確認は必要です。

個人で事業を始める人には、ルートドメインを整理し、TrekMailでメールボックスを運用し、席数単位の料金を避けるシンプルな構成になり得ます。チームでは統一した設定が導入を助けます。代理店やMSPは多数のドメインで設計を再利用できますが、各ドメインと事業者の要件は個別に確認しなければなりません。

顧客ごとに異なる壊れやすいSPFを組む代わりに、再利用可能な設計、共通の管理画面、検証済みのルートドメインincludeを使う。これはTXT文字列だけでなく運用方法の改善ですが、保守が不要になるわけではありません。

本文で引用するNanoの提供例は、10ドメイン、5GBの共有ストレージ、持ち込みSMTPで、クレジットカードは不要とされています。管理型送信やより高い上限が必要な場合、有料プランは月額$3.50から、14日間の無料試用にはクレジットカードが必要とされています。選ぶ前にTrekMailの料金ページで現在の機能、上限、条件を確認してください。

まとめ：SPFを設計して、全面的な変更を減らす

長く使えるSPFを作るには、ルートドメインの巨大な許可リストではなく、構成全体を考えます。日常メールはルートドメイン、用途別のメールは適切なエンベロープサブドメイン、includeは最小限に。送信元を完全に確認したうえで明示的な-allを設定し、公開後はDNSを検証します。

この方法は予算超過や予期しない障害を減らし、事業者変更を容易にする助けになります。ただし、SPFが永久に保守不要になる保証はありません。メール基盤を作り直すなら、TrekMailを調べ、現在の提供内容が事業の成長に合うか判断してください。