メール到達率とDNS

SPFレコード例：各種構成で使えるコピー用テンプレート

著者：Alexey Bulygin 2026年4月20日

オンラインで見つかるSPFレコード例は、単純化しすぎているか、ほとんど遭遇しない例外で膨らんでいることがあります。実際に必要なのは、ドメインの95%をカバーする三つのインフラ構成向けテンプレートです。TXTレコードは一つで、v=spf1から始まり、-allで終わります。設定を誤ると、GoogleやMicrosoftなどの受信側が550 5.7.26のような分かりにくいSMTPエラーを返し、メールを拒否する場合があります。

以下にSPFレコード例のテンプレートを示します。該当する構成を選び、レコードを貼り付けたら、本当に注意が必要な課題へ進みましょう。

各送信構成に対応するSPFレコード例

適切なSPFレコード例は、六つのSaaSツールを想定した架空の構成ではなく、実際のインフラに一致させます。以下の三つのシナリオは、単一送信元、ハイブリッド構成、複雑な複数送信元構成をカバーします。各テンプレートは、ルートドメインのDNS TXTレコードとして公開できます。

シナリオ1：単一送信元（一つのプロバイダーですべてを処理）

すべてのメールを一つのプラットフォームから送信します。最も明快で、目標にしやすい構成です。

TrekMail（Starter、Pro、Agencyプラン）：

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

Google Workspace：

v=spf1 include:_spf.google.com -all

Microsoft 365：

v=spf1 include:spf.protection.outlook.com -all

includeが一つ、-allが一つです。これだけでDNS検索を1回使い、許可される上限は10回です。

シナリオ2：ハイブリッド送信元（受信箱 + トランザクションサービス）

主要なメールボックスプロバイダーに加えて、トランザクションメールやマーケティング向けの別サービスを利用します。独自SMTPを使うTrekMailのNanoプランや、Amazon SES、Mailchimpなどを追加する構成で一般的です。

TrekMail Free + Amazon SES：

v=spf1 include:amazonses.com -all

Google Workspace + Mailchimp：

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

includeは二つで、検索も二回です。プロバイダーが発生させる入れ子の検索は別途加算されますが、通常はまだ上限内です。

シナリオ3：複数送信元構成（高リスク）

このSPFレコード例では、企業メール、CRM、ヘルプデスク、HRプラットフォームを一つのドメインで承認します。問題が起きやすい構成です。

v=spf1 include:spf.trekmail.net include:hubspot.com include:mail.zendesk.com include:spf.bamboohr.com -all

表面上はincludeが四つですが、各includeには入れ子の検索が含まれる場合があります。HubSpotだけでも3-4回の追加検索につながることがあります。合計が10を超えると、受信側はPermErrorを返し、メールを未認証として扱います。このような構成なら、以下の検索上限の節を必ず確認してください。

重要なSPF構文の仕組み

SPFはRFC 7208で定義されたDNSベースの許可リストです。どのIPアドレスがドメインを代表してメールを送信できるか、受信サーバーへ伝えます。実際のSPFレコード例で使う構成要素は次のとおりです。

構成要素	例	役割
バージョン	`v=spf1`	必須で、レコードの先頭に置きます。
Include	`include:spf.trekmail.net`	別ドメインのSPFレコードに記載された全IPを承認します。
IPメカニズム	`ip4:192.0.2.1`	静的IPを直接承認し、DNS検索を消費しません。
HardFail	`-all`	明示されていないIPを拒否します。通常はこちらを使います。
SoftFail	`~all`	未記載のIPを疑わしいものとして扱います。移行時のテスト向けです。

検証ツールやフラット化のリスクを含む手順は、SPFレコード設定ガイドをご覧ください。

10回の検索上限：SPFレコードが破綻しやすい箇所

RFC 7208は、SPF評価ごとのDNS検索を10回に制限しています。サービス拒否攻撃を防ぐための制限ですが、成長する企業が直面しやすい上限でもあります。

次のメカニズムはそれぞれ1回を消費します： include、a、mx、redirect、exists、ptr（非推奨のため使用しないでください）。

次のメカニズムは消費しません： ip4、ip6、all。

注意点は、検索が再帰的であることです。include:bluehost.comを追加すると1回を消費します。Bluehost自身のSPFレコードにinclude:spf.protection.outlook.comがあれば、その入れ子の検索も自社側の上限に加算されます。入れ子のincludeを持つプロバイダーを3-4社つなぐと、すでに10を超える可能性があります。

見落とされやすい空検索の上限

RFC 7208 §11.1には二次的な制限もあり、結果が返らないDNS検索、つまりNXDOMAINまたは空の結果は最大2回です。include:spf.trekmaill.netのように「l」を余分に入力すると、1回の空検索になります。入力ミスが二つあれば、レコード全体が失敗します。

フラット化せずに検索上限へ対処する方法

SPFレコードのフラット化に頼る前に、より堅実な代替策を検討してください。includeを生のIPへ解決するフラット化は不安定です。IPは予告なく変わることがあり、フラット化したレコードが古くなるためです。次の二つの方法は長期的に運用しやすいでしょう。

サブドメインで送信元を分割する

すべてのツールをルートドメインへ詰め込まないでください。各サブドメインには新たに10回の検索枠があります。

企業メール： @company.com：TrekMailやGoogleなど主要プロバイダーのみ
マーケティング： @news.company.com：Mailchimp、HubSpot
サポート： @support.company.com：Zendesk、Freshdesk

これは拡張しやすい戦略です。複数のドメインや顧客アカウントを管理する場合、サブドメイン分割によって各SPFレコードを簡潔で監査しやすい状態に保てます。ドメイン評価も分離されるため、マーケティング施策の問題がトランザクションメールの配信へ波及するリスクを抑えられます。

DNS検索をIPメカニズムに置き換える

静的メールサーバーを利用している場合は、aメカニズムではなくIPを直接指定します。

1回の検索を消費：

v=spf1 a:mail.company.com -all

0回の検索を消費：

v=spf1 ip4:192.0.2.55 -all

ip4またはip6へ置き換えるたび、includeを必要とするSaaSツール用の検索枠が空きます。

配信性能に深刻な影響を与えるSPFエラー

エラー1：同じドメインに二つのSPFレコード

SPFレコード例で最もよくある誤りです。同じドメインに、v=spf1で始まるTXTレコードを二つ公開することはできません。どちらもPermErrorになります。

誤り：

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

正しい例：

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

一つに統合してください。レコードは常に一つです。理由と完全な例はメール向けSPFレコード、最初からの設定手順はSPFレコード設定をご覧ください。

エラー2：+allの使用

+allは使用しないでください。すべてを合格させる指定であり、誰でも自社ドメインとして送信できると各メールサーバーへ伝えることになります。常に-all（HardFail）を使用します。

エラー3：転送メールでSPFだけに依存する

SPFは、エンベロープ送信元のドメインに対して送信IPを確認します。メールを転送するとIPは変わりますが、エンベロープ送信元は変わりません。その結果、SPFが失敗します。

この問題に対応するのがDKIMです。メッセージ内容へ署名するため、転送後も署名を維持できます。メーリングリストやメール転送を使うなら、SPFだけでは不十分です。DKIMに加え、どちらかを受け入れるDMARCポリシーを設定するのが望ましいでしょう。転送を構成するもう一つの要素がSender Rewriting Scheme（SRS）です。エンベロープ送信元を書き換え、次のホップでSPFを通過できるようにします。

TrekMailがSPF管理を簡素化する仕組み

一つのドメインでもDNSレコードの管理は手間がかかります。50または100の顧客ドメインを扱うと、ミスが重なりやすくなります。

TrekMailの方式はプランによって異なります。

Free（$0/mo、カード不要）：独自SMTPを使用し、自社プロバイダーのSPFレコードをincludeします。費用をかけずに管理できます。
Starter（$3.50/mo）とPro（$10/mo）：管理型SMTPです。include:spf.trekmail.netを追加すると、基盤となるIPインフラをTrekMailが管理します。サーバーを切り替えてもDNSは変更不要です。
Agency（.25/mo）：同じ管理型SMTPを複数ドメイン向けに提供します。標準化したSPFテンプレートを全顧客ドメインへ適用できます。一つのincludeに抑えることで、顧客の他ツール用に検索枠を残します。

すべての有料プランには14日間の無料トライアルがあり、カードが必要です。内蔵のSPF/DKIM/DMARCウィザードがDNS設定を順番に案内し、本番環境へ反映する前に検出したエラーを示します。

SPFチェックリスト

このガイドのSPFレコード例はすべて同じ原則に従います。不要に複雑化しなければ、適切なレコードは難しくありません。次の順序で監査してください。

検索回数を数える。dig TXT yourdomain.comを実行するか、オンラインSPF検証ツールを使います。10を超えていれば、すでに失敗します。
重複レコードを統合する。一つのドメインに一つのv=spf1レコードです。
負荷の大きい送信元を分割する。マーケティングとサポートのツールをサブドメインへ移します。
静的サーバーではaメカニズムをip4へ置き換える。
-allで終える。例外はありません。