SPF徹底解説 — 構文・判定のしくみ・CNAMEで委ねる方式

最終更新: 2026-09-09

こちらは踏み込んだ解説です。まず全体像をつかみたい方はSPFレコードとは？（かんたん解説）からどうぞ。このページでは、レコードの部品ひとつひとつの役割、受信側が実際に何と照合しているのか、そしてTXTではなくCNAMEで配信サービスに委ねる方式までを扱います。

このページでわかること

レコードが「バージョン指定・メカニズム・限定子（＋修飾子）」でできていること
受信側が照合しているのは、受信者に見える差出人ではないこと
TXTではなくCNAMEで配信サービスに委ねる方式の、仕組みと注意点
評価は上から順で、最初に一致したところで止まること

レコードの構文を分解する

SPFレコードは、DNSのTXTレコードとして1本公開します。中身は「バージョン宣言」＋「許可する送信元の並び」＋「締めくくり」という単純な構造です。

SPFレコードは「バージョン指定・メカニズム・限定子（＋修飾子）」でできている

メカニズム — 許可する送信元を指定する

メカニズムは「この送信元なら、うちのメールだ」と認める条件です。上から順に照合され、最初に一致したところで判定が確定します。

メカニズム	意味	DNS参照
`ip4:` / `ip6:`	指定したIPアドレス（または範囲）からの送信を認める。`ip4:203.0.113.0/24` のようにCIDRも書ける	0回
`include:`	指定したドメインのSPFレコードを読み込み、その中身で照合する。サービス利用時の基本形	1回＋その先
`a`	そのドメインのAレコード（Webサーバーなど）のIPを認める	1回
`mx`	そのドメインのMXレコード（受信サーバー）のIPを認める	1回＋MXの数
`exists:`	指定した名前が引けるかどうかで判定する。動的な制御に使う（通常は不要）	1回
`ptr`	逆引きで判定する。RFC 7208で非推奨。使わないでください	複数回
`all`	すべてに一致する。必ずいちばん最後に置く締めくくり	0回

💡 include / a / mx / exists / ptr と修飾子の redirect は、検証中のDNS参照を消費します。合計10回を超えるとpermerrorになり、設定していないのと同じ扱いになります（→10回制限の詳しい解説と減らし方）。

限定子 — 一致したときに、どう扱うか

各メカニズムの前に付けて、一致したときの結果を指定します。省略すると +（許可）です。ふだん目にするのは末尾の ~all や -all ですが、限定子は -include: のようにどのメカニズムにも付けられます。

限定子	結果	末尾に置いたときの意味
`+`（省略時）	pass（合格）	`+all` は誰でも名乗れる状態。SPFが実質無効になります
`-`	fail（不合格）	`-all` は最も厳格。送信元をすべて把握できているとき
`~`	softfail（あやしい）	`~all` は一般的な推奨。取りこぼしがあっても即拒否されない
`?`	neutral（中立）	`?all` は判定に使われず、実質「宣言していない」のと変わりません

修飾子 — redirect と exp

修飾子はメカニズムとは別物で、レコード全体に1回だけ効きます。書く位置は自由ですが、動きが違うので混同しないでください。

redirect=yourdomain.com — 自分のレコードを捨てて、指定先のSPFレコードで判定し直します。「以後はあちらを見てください」という委任です。all がある場合は redirect は無視されるので、両方書いても意味がありません
exp=spf.yourdomain.com — 不合格になったときに、受信側が拒否理由の文面を取りに行く先。付けなくても判定は変わりません

📌 include: と redirect= は似ていますが別物です。include は「あちらも許可する」（一致しなければ自分のレコードの続きを見る）、redirect は「あちらに丸ごと任せる」（戻ってこない）。

受信側が照合しているのは、どの差出人か

ここがSPFでいちばん誤解されるところです。SPFが照合するのは、受信者の画面に表示される差出人（From）ではありません。配送のために使われる、裏側の差出人アドレス（Return-Path、エンベロープFrom）です。

SPFが照合するのは Return-Path。Fromは別のドメインでもよい

だからこそ、Fromのドメインを変えずに、Return-Pathだけを配信サービス用のサブドメインにするという設定が成り立ちます。受信者に見えるアドレスは info@yourdomain.com のまま、SPFの照合は em.yourdomain.com に対して行われます。

⚠️ ただしDMARCは、この2つのドメインが揃っている（アライメントする）ことを求めます。既定の「緩やかな一致」なら em.yourdomain.com と yourdomain.com は同じ組織ドメインなので通りますが、aspf=s（厳格）を指定していると通りません（→アライメント不一致の直し方）。

TXTではなく、CNAMEで配信サービスに委ねる方式

SPFは通常TXTレコードとして登録しますが、メール配信サービスによっては「TXTではなくCNAMEを登録してください」と案内されます。SendGrid・BowNow・オレンジメールなど、採用しているサービスは少なくありません。

やることは単純で、配信用のサブドメインに、サービス側が指定するCNAMEレコードを1本置くだけです。SPFの中身はサービス側が管理します。

お客様が置くのはCNAME1本。SPFの中身は配信サービスが管理する

なぜこの方式が使われるのか

送信IPが変わっても、顧客側でDNSを直さなくてよい。配信サービスがサーバーを増減しても、SPFの中身はサービス側で更新されます
バウンス（不達通知）を配信サービスが直接受け取れる。Return-Pathがサービス側に向くので、宛先不明の処理を自動化できます
本体ドメインの10回制限を消費しない。配信サービス分の参照はサブドメイン側で完結するため、本体のSPFが複雑でも干渉しません（→10回制限）
本体ドメインの評判を守れる。一括配信の評価はサブドメイン側に付くため、日常の業務メールへの影響を抑えられます

注意すべき点

同じ名前にCNAMEと他のレコードは共存できません。DNSの仕様上の制約です。em.yourdomain.com にCNAMEを置いたら、その名前にTXTやMXを追加してはいけません。「念のためSPFのTXTも書いておこう」は設定を壊します
ドメイン本体のSPFは、これとは別に必要です。委譲でカバーされるのは、その配信サービスから送るメールだけです。同じドメインでGoogle Workspaceや自社サーバーからも送っているなら、本体のTXTレコードも要ります
10回制限は委譲先でも効きます。「CNAMEにしたから無制限」ではなく、たどった先のSPFの中身が上限の対象です
DMARCの厳格アライメント（aspf=s）とは併用できません。Return-Pathがサブドメインになるためです。既定の緩やかな一致なら問題ありません

🔍 この方式のドメインは、本体のTXTを調べてもSPFが出てきません。「未設定」と誤って判断されやすいところです。本サイトの診断は、この形を見分けて「設定済（○○経由）」と表示します。

評価の順序 — 上から順に、最初の一致で止まる

受信側は、メカニズムを書かれた順に照合します。一致した時点でその限定子の結果を返し、残りは読みません。だから all は必ず最後です。途中に置くと、その後ろのメカニズムは永久に評価されません。

v=spf1 ip4:203.0.113.10 ~all include:_spf.google.com
                            ^^^^ ここで必ず止まる
                                 → include は一度も評価されない

また、SPFレコードは1ドメインに1本だけです。2本publishするとRFC 7208違反でpermerrorになり、両方とも無効になります。サービスを増やすときは、レコードを増やすのではなく既存の1本に include: を追記します。

確認のしかた

コマンドで確かめるなら、TXTを引きます。CNAME方式のドメインは、本体ではなく配信用サブドメインを引いてください。

# ドメイン本体のSPF
dig +short TXT yourdomain.com

# 配信用サブドメイン（CNAME方式のとき）
dig +short TXT em.yourdomain.com
dig +short CNAME em.yourdomain.com

参照回数の合計や、たどった先で何が起きているかまでまとめて見るなら、このサイトの診断が早いです。include を再帰的にたどって回数を数え、参照先が消えている・重複しているといった無駄も指摘します。