SPF レコード設定：例、参照上限と検証

2026 年にメールインフラを構築するなら、SPF レコードは認証の重要な基盤です。誤りは迷惑メール判定だけでなく、受理の拒否につながる場合があります。ただし、SPF だけで受信トレイへの到達や全受信者の扱いが決まるわけではありません。

2024 年二月から Google と Yahoo は対象となる送信者に認証要件を強化しました。有効な SPF がないと、適用される受信方針によって SMTP 550 が返る場合があります。しかし、すべてのメールが転送完了前に自動で拒否されるという意味ではありません。

一つのドメインで起業する創業者なら、SPF の誤りで投資家に資料が届かないかもしれません。500 の顧客ドメインを管理する MSP なら、月曜の朝に「Gmail に送れない」という問い合わせが集中する場合があります。適切な設定と確認はリスクを減らしますが、すべての問題を防げるわけではありません。

本ガイドでは SPF の役割、適切なレコードの組み立て、到達性を損なう見落としやすい問題、そして複数ドメインでの管理方法を説明します。

SPF が行うこと、行わないこと

Sender Policy Framework (SPF)は DNS に基づく認可プロトコルで、RFC 7208に定義されています。検査するドメインの送信元を DNS で許可し、受信側が接続 IP を照合します。包括的なセキュリティ対策ではなく、特定の送信元確認を担います。

実際の確認方法

Gmail が alice@yourcompany.com から受信するとき、SPF は画面上の From だけを見ません。通常は MAIL FROM のエンベロープドメインを検査します。このアドレスはReturn-Pathに反映され、バウンス処理に使われます。該当する場合は HELO を検査します。受信側は対応する SPF を取得し、接続元 IP が許可されているか評価します。

許可する機構が一致すれば成功する場合があります。残りの送信元には、終端規則から SoftFail (~all) または Fail (-all) が返る構成があります。これらは SPF の結果であり、全受信者に同じ受理や拒否を命令するものではありません。

重要な違い：From と Return-Path

原文の 90% は初心者全体について確認された統計ではありませんが、よくある混同を示しています。SPF は Outlook や Apple Mail に表示される From を検査しません。適切な技術上のエンベロープドメインが対象です。

注意点：Mailchimp はニュースレターのバウンスを処理するため、bounce-mc.us1.mailchimp.com のような自社ドメインを Return-Path に使う場合があります。受信側が調べるのはMailchimpの SPF であり、表示上の自社 From の SPF ではありません。自社レコードが正しくても、この経路では参照されないことがあります。

この整合の問題が、SPF だけでは不十分な理由の一つです。SPF、DKIM、DMARC の関係はメール認証の設定順序で説明しています。

それでも SPF が必要な理由

DKIM と DMARC を使っていても、SPF の欠落は適用される送信者要件に違反する場合があります。Microsoft は対象となる大量送信で 550 5.7.515 Access Denied を返す場合がありますが、すべての Microsoft 受信者に共通する挙動ではありません。SPF とその他の要件を確認してください。

基本形：一つの送信サービス

小規模企業が主に TrekMail、Google Workspace、Microsoft 365 のいずれかと、場合によって一つのマーケティングツールを使うなら、検査する DNS 名ごとに明確な一つの SPF 方針を用意します。構成は比較的簡単でも、典型的な失敗は起こります。

基本規則：同じ DNS 名には SPF 方針を一つだけ公開します。

新サービスを追加するとき、既存 SPF に統合せず二つ目の SPF TXT を作ることがあります。同じ名前に二つの該当 SPF があれば、評価は PermError になります。二つを別々に信頼して検査するのではなく、一つの方針を選べないエラーです。

レコードの構成要素

コードは構造を説明する例で、現行の配備可能な値を保証しません。事業者の値、送信元一覧、参照上限を確認してからSPF の設定ガイドを利用してください。

小規模企業で TrekMail を検討する

原文は Google Workspace を一人月額 $6-$18 とし、十人なら年間 $720-$2,160 と比較しています。TrekMail Starter は月額 $3.50 の固定料金で最大 100 ユーザーと記載されています。これらは過去の比較例なので現行条件を確認してください。include:spf.trekmail.netが適切な構成要素になる場合も、全送信元の把握、DNS 公開、認証確認は必要です。ライセンスと契約条件も具体的な提案で比較します。

複数サービス：代理店の構成

MSP や代理店の顧客は、営業に HubSpot、サポートに Zendesk、マーケティングに Klaviyo、日常業務に TrekMail を使う場合があります。各ツールを自社 SPF に含める必要があるかは、実際のエンベロープドメインと事業者の設定によります。

必要な許可を一つの方針にまとめる際は、RFC の重要な制約であるDNS 参照を要する 10 項目の上限を守ります。

DNS 参照を要する 10 項目の上限

RFC 7208 §4.6.4は、実際の評価経路で DNS 参照を要する該当機構と修飾子を、入れ子を含めて 10 項目までに制限します。全 DNS パケット数とは異なります。悪用による負荷を抑える仕組みですが、正当な複雑な構成にも影響する場合があります。

上限に算入するもの： include:、a、mx、exists、redirectが実際に評価される場合です。古い ptr 機構も算入されます。

この上限に算入しないもの： ip4:、ip6:、allです。

入れ子の include

include:bluehost.comを加えると、1 項目に見えます。しかし歴史的な例では spf.protection.outlook.com と mail.bluehost.comを含み、一つの外側の項目から三つの該当評価になる場合があります。spf.protection.outlook.comにも参照先があるかもしれません。現行値と実際の経路を確認してください。

該当項目が 10 を超えると PermError になります。正当なメールにも影響し得ますが、常に無通知で恒久拒否されるわけではありません。SMTP の診断応答や受信側方針、他の認証結果も関係します。

参照上限を確認する

推測せず、適切な CLI や説明可能な可視化ツールを使います。Mac/Linux では次から始められます。

dig +short txt yourdomain.com

各 include:を再帰的に調べ、他の該当項目と実際の経路も評価します。dig は TXT を表示するだけで、SPF 評価器ではありません。詳しくはSPF 参照上限のガイドを確認してください。

フラット化とサブドメイン分割

10 項目の超過が予想される場合、次の二つなどを検討できます。代理店なら必ず超過するというわけではありません。

選択肢 1：保守が必要な SPF フラット化

フラット化は include:の許可アドレスを解決し、直接の ip4:機構に置き換えます。ip4:の該当 DNS 項目消費はゼロなので、数百の IP でもこの上限を超えない場合があります。ただし、サイズや有効性、元の方針の意味、他のアドレス種別も考慮します。

問題点：HubSpot、Klaviyo などの ESP は IP を変更する場合があります。固定した一覧が古くなると、数か月後には新 IP が欠け、旧 IP が許可されたままになることがあります。以前の成功は将来の正しさを保証しません。

採用には信頼できる元レコードの監視、承認された DNS 更新、エラー処理と戻す手順が必要です。自動スクリプトは補助になりますが、それだけで安全ではありません。保守なしでは技術的負債になります。

選択肢 2：送信をサブドメインに分ける

もう一つは全サービスをルートドメインに詰め込まない方法です。SPF は Return-Path に表れる実際のエンベロープドメインを評価し、サブドメインも使えます。

マーケティングは team@company.com である必要がありますか。それとも news@marketing.company.com が適切でしょうか。表示上の From だけでは SPF の対象は変わりません。

ルートドメイン (company.com)：業務メールや重要なインフラに必要な許可を明確に保ちます。

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

マーケティング用サブドメイン (marketing.company.com)：対応するサービスの送信元の識別情報を分けられます。

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

実際に別のエンベロープ送信者の識別情報と SPF 方針を使う場合に限り、別の 10 項目の予算を使えることがあります。marketing.company.comは評価を遮断する壁ではありません。受信側は組織ドメインや共有 IP をまとめて評価し、経営陣のメールにも影響する可能性があります。Relaxed と strict の DMARC 整合や現行事業者値を確認し、例をそのまま配備しないでください。

他の出発点はSPF 設定テンプレートを参照してください。複数サービスは複数送信元の構成ガイドで説明しています。

公開後の検証手順

DNS エディターで保存しても作業は終わりません。以下は公開と実際の使用を確認するための手順です。

1. DNS の可視性とキャッシュを確認する

DNS 変更は全世界に同時反映されません。TTL、既存キャッシュ、事業者の処理によって数分から数時間かかる場合があります。ローカルと権威 DNS に加え、公開リゾルバーも確認します。

nslookup -type=txt yourdomain.com 8.8.8.8

8.8.8.8は ISP のリゾルバーでなく Google 公開 DNS に問い合わせます。しかし Google にもキャッシュがあります。そこで新値が見えても、多くの世界のリゾルバーや全受信者で反映済みとは証明できません。

2. 構文を検証する

SPF は正確な構文が必要です。よくある問題は次のとおりです。

• v=spf1の前の空白
• ip4: 192.1.1.1：コロン後の空白は無効
• 複数の all：最初が一致し、その先の機構はこの経路で評価されない
• 重複した include:：必ず構文エラーではないが、評価されると予算を無駄にする場合がある

設定を終える前に構文を確認します。現行機能で利用できるDNS 設定ウィザードは補助になっても、完全な検証の代わりにはなりません。

3. 空の DNS 応答を確認する

RFC 7208 は別の上限も推奨し、結果のない DNS 参照は 2 回までとします。NXDOMAIN や成功しても対応データがない応答が該当します。実装で設定可能な場合があり、具体的なエラー種類も確認します。

include:spf.trekmaill.netの余分な「l」は、1 回の空参照になるかもしれません。ただし、include 先に有効な SPF がないと、その時点で PermError になることもあります。二つの誤字だけで推奨上限を超えたことにはなりません。

構文だけでなく、参照先を解決し、結果の意味を確認してください。バウンスが始まるまで発見できない問題ではありません。

4. 実際のメールヘッダーを確認する

管理する Gmail に送信し、三点メニューから「メッセージのソースを表示」を選びます。信頼できる受信システムが付けた Authentication-Results を確認してください。結果の例は次のとおりです。

spf=pass (google.com: domain of user@yourdomain.com designates 192.0.2.1 as permitted sender)

spf=neutralやspf=softfailは意図した方針と照合します。常に設定誤りとは限りません。IP、検査ドメイン、許可を比べてください。DNS 状態の確認で DNS を検証し、信頼できるヘッダーも別途分析します。

よくある失敗と原因

次のパターンは SPF 関連の問い合わせで見られます。知っておくと診断に役立ちますが、普遍的な原因の割合を示すものではありません。

1. 転送による SPF の問題

SPF は接続元 IP を検査します。これが構造上の制約でもあります。

Alice が Bob に送り、Bob が Charlie に転送します。Charlie から見えるのは Bob のサーバー IP です。元のエンベロープが保持され、新 IP が許可されていなければ、元のメールが正当でも SPF は失敗する場合があります。

SPF だけで解決できるとは限りません。DKIM は選択したヘッダーと本文を署名します。正規化後も署名対象が有効で、鍵などの検証条件を満たせば、転送後も成功する場合があります。DMARC には整合も必要です。SPF だけに依存しないでください。

DKIM と SRS の役割はドメインメール転送と到達性で説明しています。すべての転送経路を保証するものではありません。

2. ptr機構

2000 年代初頭には、逆引き DNS の SPF 機構 ptr がよく使われていました。

v=spf1 ptr -all

新しい構成には使わないでください。RFC は負荷と信頼性の理由で ptr を推奨していません。しかし、Gmail が必ず罰したり全レコードを無視したりするとは言えません。既存の ptr は送信元の把握と代替許可、テストの後で置き換えます。送信 IP の SMTP 用 PTR 要件とは区別してください。

3. +allの危険性

次のような問題のある構成も見られます。

v=spf1 include:spf.google.com +all

修飾記号の意味は次のとおりです。

• -all = 前で一致しない送信元に Fail。扱いは受信側の方針による
• ~all = 残る送信元に SoftFail。受理と印付けを強制しない
• +all = 残るすべての送信元に Pass

評価が +all に到達すれば、任意の IP が検査ドメインの送信元として許可されます。+allは SPF を弱め、悪用を助ける可能性がありますが、フィッシングの到達を保証しません。+allがあれば速やかに正当な送信元を把握し、-allなどの適切な規則をテストして選びます。

4. 外部サービスの Return-Path が整合しない

独自 Return-Path を設定しないマーケティングサービスは、事業者のバウンスドメインを使う場合があります。追跡ドメインは同じものとは限りません。自社 SPF はそのエンベロープで参照されず、事業者 SPF が成功しても自社 From と整合しないことがあります。ただし、有効で整合した DKIM があれば DMARC は成功できます。

ESP が bounce.yourcompany.comのような独自バウンスサブドメインを提供するなら、文書に沿って設定します。Relaxed は対応する組織ドメイン、strict は完全一致を使います。DMARC 整合とドメイン評価を参照してください。

生成ツールの評価方法

SPF 生成ツールには違いがあります。確認を助けるものもあれば、不適切な構成を出すものもあります。

役立つ機能

可視化ツールは完全な include:の連鎖を示し、超過前の確認を助けます。適切なメール到達性ツールで利用できる場合がありますが、他の該当項目も考慮します。

構文確認ツールはコロンの欠落や無効文字を発見します。空参照や対象方針などの実行時の問題には、別途 DNS の解決と評価が必要です。変更後に使い、実際の送信でも確認します。

注意が必要な出力

設定ウィザードは ?all、つまり Neutral を出力する場合があります。残る送信元への肯定的な許可信号ではありませんが、自動的に誤りとも言えません。送信元一覧と受信要件から -allや暫定的な~allなどを選び、既定値を無条件に使わないでください。

分割レコード生成ツール：TXT の一つの文字列は 255 バイトまでです。長い SPF は同一レコード内の引用符付き文字列に分けます。二つの独立した SPF TXT にしてはいけません。

• 意図した分割： "v=spf1 include:a..." "include:b... -all"は二つの文字列で一つのレコードを示しますが、実際の内容には境界の区切り空白が必要です
• 誤り：二つの独立した SPF TXT は評価時に PermError になる

連結時に空白は自動で加わりません。この省略例をそのまま有効な SPF として配備せず、生成結果の公開内容と構文を確認してください。

選び方と設定はSPF 生成ツールと設定ガイドを参照してください。

TrekMail による構成の標準化

大手の業務スイートが悪い製品というわけではありません。ただし、同梱機能やユーザー単位の課金が全顧客に適するとは限りません。必要な機能と契約を比較します。

適切な TrekMail の経路では、次の例を出発点にできます。現行値と追加の送信元を確認してください。

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

検査するドメインの必要な送信元をすべて正しく許可している場合に限り、この行は完全です。管理型 SMTP は範囲に応じて IP、PTR、利用できるフィードバックを扱いますが、SMTP 持ち込みでは責任が異なります。送信元、量、リスト、監視は引き続き必要で、許可は到達を保証しません。

同じ実構成の顧客ドメインが 50 あれば、50 の同じ SPF で管理を簡単にできる場合があります。料金と顧客ごとの設定は確認します。新顧客でも百回使った行が適切なことはありますが、実際の送信元が同じ場合に限ります。標準化で個別の検証は不要になりません。

移行はIMAP 移行の概要と必須 DNS レコードを参考に計画します。IMAP はアクセスできるメールボックスのデータを扱い、DNS、アプリ、評価を自動移行せず、無損失や無停止も保証しません。認証の準備、テスト、差分と移行結果の確認後に MX を切り替えます。画面からの一括追加はドメインの一括取り込みで現行条件を確認してください。

継続できる SPF 管理

2024 年にメール認証の要件が強化されました。不適切なSPF レコードは正当な送信にもリスクになります。Google と Microsoft は各自の適用規則で SPF を使い、すべてを同じように自動拒否するわけではありません。

要点は次のとおりです。

1. 今確認する。dig +short txt yourdomain.comを実行し、全 TXT でなく同じ DNS 名の SPF 方針を数えます。複数の SPF 方針は評価時に PermError になります。
2. 許可を統合する。必要な送信元を一つの SPF TXT にまとめます。同じレコード内の複数文字列は可能です。
3. 参照を数える。適切なツールで検査します。該当項目が 10 を超えるなら、実際のエンベロープサブドメインが保守負担の大きいフラット化の代案になる場合があります。
4. -allを意図して選ぶ。~allからの変更は送信元の把握とテスト、方針の決定後に行います。+allは速やかに調査して修正します。
5. Return-Path の整合を確認する。Mailchimp や HubSpot の独自バウンスドメインで SPF を整合できる場合があります。DMARC は代わりに有効で整合した DKIM だけでも成功できます。
6. SPF だけで終わらない。転送で SPF が失敗したり DKIM が変わったりする場合があります。三つすべて、SPF、DKIM、DMARC を使い検証します。

例にある 50 バイトの SPF で、回避できる誤りから契約や顧客を失うのは避けたいものです。適切に設定し、年次という例の周期に加え、送信元や事業者の変更時にも確認します。一度設定して永久に放置できるものではありません。

DNS を確実に確認する運用へ。TrekMail の無料プランを検討する際は、現行条件、固定プランと各ドメインの SPF、DKIM、DMARC 支援範囲を確認してください。