SPFの書き方(例文つき)1行の「送ってよい送信元の名簿」を、読めて・書けて・確かめられるようになる
「SPFを設定してください」と言われて、v=spf1 include:… ~all という暗号のような1行を前に手が止まっていませんか。部品は5種類だけ。名簿にたとえると、10分で読めるようになります。コピペ用の例文も状況別に用意しました。
🧭 結論:SPFは「うちの名前でメールを出してよい送信元の名簿」を1行で書くこと
- SPFは、ドメインのDNSに置く1行のメモです。「example.jp のメールは、この送信元からしか出しません」と世界に公開します。
- 書き方の基本形は
v=spf1(表紙)+ 送信元の一覧 +~allか-all(名簿にない送信元の扱い)。これだけです。 - 使っているサービスごとに公式マニュアルに書かれた
include:〜を足すのが基本。自分でIPアドレスを調べて書く場面は多くありません。 - 失敗の多くは3つ。SPFを2行作ってしまう/参照回数が10回を超える/送信サービスの入れ忘れ。どれも「SPFが効かない」か「本物が迷惑メール扱い」になります。
- SPFだけでは差出人欄の偽装は防げません。SPF → DKIM → DMARCの順で3点セットにするのがゴールです。メールを送らないドメインにも
v=spf1 -allを置きましょう。
名簿は「全部を書く」「1枚にまとめる」「書きすぎない」。この3つを守れば、SPFはほぼ間違えません。
📋 目次
SPFの1行は、5種類の部品でできている
よくあるSPFレコードを、部品ごとに分けてみる
※ 例文のIPアドレス(203.0.113.10)とドメイン(example.jp)は、説明用に予約されたものです。実際には自分の環境の値に置き換えます。
💡 この図のポイントは1つだけ
SPFは「OKな送信元を並べて、最後に“それ以外はどうするか”を書く」という形しかありません。ip4 や include の数が増えても、この形は変わりません。
SPFは、会社が玄関に貼る「送信元の名簿」
メールの差出人は、実は誰でも書き換えられます。手紙で言えば、誰でも封筒の裏に「〇〇株式会社」と書いてポストに入れられる状態です。
そこで会社は、玄関(DNS)に名簿を貼っておきます。「うちの名前の手紙は、この郵便局から出したものだけが本物です」。受け取った側は名簿を見に行き、手紙が出された局が名簿に載っているかを確かめます。これがSPFです。
📝 名簿を書くのは「送る側」
自分のドメインのDNSに、1行のTXTレコードとして書きます。書き換えられるのはドメインの持ち主だけです。
🔍 名簿を見るのは「受け取る側」
Gmail や Outlook などが、メールを受け取るたびに自動で見に行きます。受け取る人は何もしなくてかまいません。
⚖️ 判定結果は「材料」
不合格でも即削除とは限りません。迷惑メールに振り分ける、警告を出すなど、扱いは受け取る側が決めます。
部品一覧:名簿の書き方を表で覚える
| 部品 | 名簿でいうと | 書き方の例 | 参照回数 |
|---|---|---|---|
v=spf1 | 名簿の表紙。「SPFです」の宣言 | v=spf1(必ず先頭、小文字でこのまま) | 0 |
ip4: / ip6: | 郵便局の住所を直接書く | ip4:203.0.113.10ip4:198.51.100.0/24ip6:2001:db8::/32 | 0 |
include: | 「この業者の名簿も見て」と別紙を指す | include:_spf.google.com | 1+別紙の中身 |
a | うちのWebサイトと同じ建物 | a / a:mail.example.jp | 1 |
mx | うちの受付窓口(受信サーバー) | mx | 1 |
all | 名簿にない送信元の扱い。必ず最後 | ~all(怪しい)/ -all(偽物) | 0 |
redirect= | 「名簿は丸ごとあちらを見て」 | redirect=_spf.example.jp | 1 |
「参照回数」は、受け取る側がDNSに問い合わせる回数です。合計10回までという決まりがあります(数え方は「参照は10回まで」の章で説明します)。
部品の前に付く記号(4種類)
各部品の前には記号を付けられます。付けなければ +(OK)扱いです。ふだん記号を付けるのは、最後の all だけと考えてかまいません。
| 記号 | 意味 | 判定結果の名前 | 使いどころ |
|---|---|---|---|
+(省略可) | 本物として通してよい | pass | 送信元の部品。書かなくても同じ |
~(チルダ) | たぶん偽物。受け取ってよいが印を付けて | softfail | 最後の ~all |
-(マイナス) | 偽物。受け取らなくてよい | fail | 最後の -all |
? | 何とも言わない | neutral | 試験中だけ。本番では使わない |
※ 名簿のたとえは最初の理解のための比喩です。実際に照合しているのは「郵便局」ではなく、メールを送り出したサーバーのIPアドレスです。
受け取る側は、こうやって名簿と照合している
あなたが [email protected] からメールを送ったとき、受け取る側(たとえばGmail)の中では、次のことが一瞬で起きています。
- メールが届く。送ってきたサーバーのIPアドレス(例:203.0.113.10)が分かります。
- 「封筒の差出人」のドメインを見る。SPFが見るのは、画面に出る差出人名ではなく、配送用の差出人(Return-Path)のドメインです。
- そのドメインのDNSに名簿を聞きに行く。
example.jpのTXTレコードからv=spf1で始まる1行を探します。 - 左から順に照合する。
ip4に一致するか、include先の名簿に載っているか…と進み、最初に一致したところで止まります。 - 結果が決まる。一致すれば pass。どれにも一致しなければ最後の
~allや-allに従って softfail / fail。 - DMARCに引き継ぐ。SPFの結果とDKIMの結果を合わせ、画面上の差出人と一致しているかをDMARCが最終判定します。
⚠ SPFだけでは「差出人欄のなりすまし」は防げない
手順2のとおり、SPFが確かめるのは配送用の差出人です。攻撃者は配送用の差出人を自分のドメインにしてSPFに合格させ、画面に見える差出人だけを「〇〇銀行」にできます。このズレを取り締まるのがDMARCです。SPFはあくまで3点セットの1つ目と考えてください。
SPF・DKIM・DMARCの役割分担
| 仕組み | たとえると | 確かめること | SPFとの関係 |
|---|---|---|---|
| SPF | 送信元の名簿 | 決められたサーバーから送られたか | この記事の主役。転送されると失敗しやすい |
| DKIM | 封筒の封印 | 途中で書き換えられていないか(電子署名) | 転送されても残りやすい。SPFの弱点を補う |
| DMARC | 名前の照合と処分ルール | 画面の差出人とSPF・DKIMの結果が一致するか | SPFかDKIMの合格が前提。レポートでSPFの漏れも見つかる |
ヘッダーの見方やDMARCの詳しい話は、メールヘッダーでDMARCを確認する方法、メール全体の守りはメールセキュリティ7つの壁でも解説しています。
状況別の例文12個:自分に近いものから選ぶ
まずは自分の状況を下の4つから選んでください。該当する例文に進めば、ほぼそのまま使えます。
- A. メールを送らないドメインサイト専用・転売対策で取っただけ → 例文1
- B. クラウドのメールだけGoogle Workspace や Microsoft 365 → 例文2・3
- C. レンタルサーバーのメールエックスサーバーなど → 例文6・7
- D. いくつものサービスから送る配信サービス・予約システム・自社サーバー → 例文4・5・8〜12
基本の4パターン
例文1メールを一切送らないドメイン
名簿に誰も載せず「このドメインからのメールは全部偽物」と宣言します。使っていないドメインは、詐欺メールの差出人に悪用されやすいので必ず置きましょう。Microsoftもこの書き方を案内しています。DMARC(p=reject)も合わせて置くとさらに確実です。
例文2Google Workspace だけで送る
Googleの管理者ヘルプに載っている形そのままです。Googleは最後を ~all にすることを推奨しています。
例文3Microsoft 365 だけで送る
Microsoft Learn に載っている形です。Microsoftは、DKIMとDMARCも設定する前提で -all を推奨しています(Googleと推奨が違う理由は「~all と -all の選び方」で)。
例文4自社のメールサーバー1台から送る
送信サーバーのグローバルIPアドレスを直接書きます。社内のIP(192.168.〜 や 10.〜)を書いても意味がありません。インターネット側から見えるIPアドレスを書きます。
範囲・IPv6・レンタルサーバー
例文5IPアドレスの範囲とIPv6もまとめて書く
/24 は「198.51.100.0〜198.51.100.255 の256個」という範囲の書き方です。範囲を広くしすぎると、同じ範囲を使う他人のメールまで合格してしまうので、必要な分だけにします。
例文6エックスサーバーの初期設定(実例)
エックスサーバーでは、独自ドメインを追加するとこの形のSPFが自動で入ります(sv*** は契約サーバー名、example.com は自分のドメインに置き換わります)。+a: や +mx の「+」は省略できる記号を明示的に書いているだけで、意味は同じです。自動で入っているので、多くの場合は触らなくて大丈夫です。
例文7エックスサーバー+Gmailから独自ドメインで送る
Gmail(Googleのサーバー)を送信サーバーとして使い、独自ドメインのアドレスで送る場合の追加例です(エックスサーバーのマニュアル掲載の形)。新しい行を作るのではなく、既存の1行の ~all の前に足すのがポイントです。
複数サービス・分割・使い回し
例文8Google Workspace+Salesforce から送る
サービスが増えたら include: を並べるだけです。include値は必ずそのサービスの公式マニュアルで確認してください(Googleのヘルプには Amazon SES・Mailchimp・Shopify・Zendesk などとの組み合わせ例も載っています)。
例文9Microsoft 365+自社サーバー1台
複合機のスキャン送信や、社内システムの通知メールを自社サーバーから送っている場合の形です。「人が送るメール」以外の送信元を忘れやすいので注意します。
例文10メルマガ配信だけサブドメインに分ける
配信サービスは news.example.jp のようなサブドメイン専用の名簿に分けると、参照回数の節約にもなり、配信側のトラブルで本業のメールの評判が下がるのも防げます(Microsoftが推奨する分け方)。サブドメインは親の名簿を引き継がないので、送るサブドメインごとに名簿が必要です。mail.example-esp.net は説明用の架空の値です。
例文11長くなった名簿を分けて書く
TXTレコードの1つの文字列は255文字まで。それを超えるときは "…" "…" と区切ります。受け取る側はすき間を入れずにつなげて読むので、1つ目の最後にスペースを入れておくのがコツです。レコードは2つにしません(間違い探し参照)。
例文12複数のドメインで同じ名簿を使い回す
redirect= は「名簿は丸ごとあちらを見て」という意味です。ドメインをいくつも持っている会社で、名簿の修正を1か所で済ませたいときに便利です。redirect を使うときは同じ行に all を書きません。
✅ 例文を使うときの3つの約束
- SPFの行はドメインごとに1つだけ。足すときは既存の行に書き足す
- include値は各サービスの公式マニュアルからコピーする(記事やブログの値を信じない)
- DNSの反映には時間がかかる。Googleは「最長48時間ほど」と案内しています
最後の「all」はどれにする? ~all と -all の選び方
SPFで一番質問が多いのがここです。実はGoogleとMicrosoftで推奨が違います。
| 書き方 | 名簿でいうと | 危険度 | こんなときに |
|---|---|---|---|
-all | 名簿にない局の手紙は偽物 | 🟢 強い | 送信元を全部把握できている/メールを送らないドメイン。Microsoftの推奨 |
~all | 名簿にない局の手紙は、たぶん偽物 | 🟢 標準 | 送信元の洗い出しに自信がない間。Googleの推奨 |
?all | 名簿にない局でも、何とも言わない | 🟡 弱い | 試験期間だけ。本番では使わない(Microsoft) |
+all | 誰が出しても本物扱い | 🔴 危険 | 使ってはいけない。名簿の意味がなくなり、なりすましに合格を与える |
| (all なし) | 名簿の最後に何も書いていない | 🟡 弱い | どれにも一致しないと neutral 扱い。必ず書く |
GoogleとMicrosoftの言い分を並べると
Google:~all を推奨
名簿の書き漏れがあっても、本物のメールがいきなり拒否されにくい。最終的な処分はDMARCに任せる考え方です。
Microsoft:-all を推奨
DKIMとDMARCも設定する前提で -all を推奨。DKIM署名のないメールでは、~all だとDMARCの処分が実質的に効かない場合がある、と説明しています。
このサイトのおすすめ
まず ~all で始め、DMARCレポートで送信元の漏れがないと確認できたら -all。メールを送らないドメインは最初から -all。
🚨 -all にする前に必ず確認すること
名簿に載っていない正規の送信元(予約システム、請求書の送信サービス、複合機、Webサイトの問い合わせフォームなど)があると、-all にした瞬間にそのメールが相手に届かなくなることがあります。DMARCを p=none(監視だけ)で入れてレポートを数週間見てから切り替えると安全です。
昔と今:SPFは「やったほうがいい」から「ないと届かない」へ
| 項目 | 以前 | 今(2024年2月〜) |
|---|---|---|
| Gmail宛てに送る全員 | SPFがなくても届くことが多かった | SPFかDKIMのどちらかが必須 |
| Gmail宛てに1日5,000通以上送る送信者 | 同上 | SPFとDKIMの両方+DMARCが必須。差出人欄のドメインとSPFかDKIMのドメインの一致も必要 |
| SPFの役割 | 単独のなりすまし対策 | DMARCの材料の1つ。DKIMとセットで使う |
出典:Google「メール送信者のガイドライン」。1日5,000通は個人アカウント(Gmail)宛ての合計です。
「参照は10回まで」を実際に数えてみる
SPFには「名簿を読む途中で、別の場所を見に行くのは合計10回まで」というルールがあります(RFC 7208)。これを超えると、名簿そのものがエラー(permerror)扱いになり、本物のメールでもSPFに合格できなくなります。
数えるのは include・a・mx・exists・redirect(と非推奨の ptr)。ip4・ip6・all は0回です。落とし穴は、include先の名簿の中にさらに include があると、それも数えることです。
例:エックスサーバー+Gmail(例文7)を数えると
| 部品 | 回数 | 中身(2026年9月30日にDNSで確認) |
|---|---|---|
+a:sv***.xserver.jp | 1 | サーバーのIPアドレスを調べる |
+a:example.com | 1 | 自分のドメインのIPアドレスを調べる |
+mx | 1 | 受信サーバーを調べる |
include:spf.sender.xserver.jp | 1+2 | 中にさらに include が2つ入っている |
include:_spf.google.com | 1 | 中身はIPアドレスの一覧だけ(追加の参照なし) |
| 合計 | 7 | 上限10回まで、残り3回 |
見た目の部品は5つでも、実際は7回。ここに配信サービスを3つ足せば上限ぎりぎりです。各社の名簿の中身は予告なく変わることもあるので、回数は定期的に数え直すのが安全です(下の確認方法で使うチェックツールの多くは、回数を自動で数えてくれます)。
10回を超えそうなときの3つの手
- サブドメインに分ける(例文10)。サブドメインごとに10回の枠があります。
- 使っていない送信サービスを名簿から消す。解約済みのサービスの include が残っていることはよくあります。
- include を IPアドレスに置き換える(フラット化)。ただし相手のIPが変わると追いかける必要があり、Microsoft 365のようにIPが頻繁に変わるサービスでは勧められていません。
間違い探し:このSPF、どこがおかしい?
実際によくある失敗を6問にしました。答えを考えてからタップしてください。
Q1. DNSに次の2行を登録した
v=spf1 include:_spf.google.com ~all
v=spf1 include:spf.protection.outlook.com ~all
答え:SPFが2つある。1つのドメインにSPFは1つだけ。2つあると受け取る側はどちらを使うか決められず、エラー(permerror)になります。正しくは v=spf1 include:_spf.google.com include:spf.protection.outlook.com ~all と1行にまとめます。サービスを追加するときに一番起きやすいミスです。
Q2. v=spf1 include=spf.protection.outlook.com -all
答え:「=」ではなく「:」。include: です。redirect= と混ざりやすい書き間違いで、Microsoftも典型的な誤りとして挙げています。
Q3. v=spf1 include:spf.protection.outlook.com. -all
答え:ドメイン名の最後の「.」が余計。DNSの画面ではドメインの最後にピリオドを付ける習慣があるため、つい付けてしまうミスです。同じく include: spf… のように「:」の後ろにスペースを入れるのも誤りです。
Q4. v=spf1 ip4:203.0.113.10 +all
答え:+all は「誰でも合格」。最後の all に + を付けると、名簿に載っていない世界中のサーバーが合格になります。なりすまし対策どころか、偽物に合格証を渡すことになります。~all か -all にします。
Q5. v=spf1 -all include:_spf.google.com
答え:all が先頭側にある。照合は左から順で、all は「すべてに一致」します。そのため -all の時点で全員が不合格になり、後ろの include は読まれません。all は必ず最後に置きます。
Q6. 会社のメールは [email protected] と [email protected]。SPFは example.jp にだけ登録した
答え:shop.example.jp の名簿がない。サブドメインは親の名簿を引き継ぎません。shop.example.jp にも専用のSPFを登録します。逆に、メールを送らないサブドメインのなりすましは、DMARCのサブドメイン設定で守るのが基本です。
ほかにも多い「効かないSPF」
| 失敗 | 何が起きる | 直し方 |
|---|---|---|
| 全角スペース・全角コロンが混ざる | 読めずにエラー | 半角で打ち直す。Wordやチャットからのコピペで起きやすい |
v=spf1 を v=spf や spf1 と書く | SPFとして認識されない(SPFなし扱い) | 先頭は必ず v=spf1 |
| DNSの「SPF」というレコード種類で登録 | 今の仕組みでは見てもらえない | 種類は必ず TXT。SPF専用の型は廃止扱い |
ptr を使う | 遅く、不安定 | RFCで「使うべきでない」とされている。ip4 や include に置き換える |
| 存在しないドメインを include | エラー(permerror)になることがある | 解約・移行したサービスの include を消す |
| 複合機・フォームの送信元を入れ忘れ | そのメールだけ迷惑メール扱い | DMARCレポートで送信元を洗い出す |
自分のSPFを確かめる3つの方法
方法1:コマンドで名簿を読む(1分)
Windowsなら「コマンドプロンプト」、Macなら「ターミナル」で、次のように打ちます(example.jp を自分のドメインに)。
表示された中に v=spf1 で始まる行が1つだけあればOKです。0行ならSPF未設定、2行あればQ1の失敗です。
方法2:自分宛てにメールを送って、判定結果を見る(3分)
- 自分のドメインのアドレスから、自分のGmailアドレス宛てにメールを1通送る
- Gmail(パソコン)でそのメールを開き、右上の「︙」→「メッセージのソースを表示」
- 上部の表に SPF: PASS と出ていれば合格。SOFTFAIL / FAIL なら、送ったサーバーが名簿に載っていない
同じ画面の下の方にある Received-SPF: の行には、どのIPアドレスから届いて、なぜその判定になったかが書かれています。名簿に足すべきIPを探すヒントになります。
方法3:チェックサービスで回数まで数える
「SPF チェック」などで検索すると、ドメインを入れるだけで構文の誤り・参照回数・重複を調べてくれる無料サービスが見つかります。設定を変えたらその都度通しておくと安心です。
あなたのドメインは大丈夫? 診断チェック
□ 当てはまらないものがあれば、そこが次の作業です
- メールを送るドメインに、
v=spf1で始まるTXTレコードがちょうど1つある - 最後が
~allか-allになっている(+all・?all・なし ではない) - メールを送るすべてのサービス(予約・請求・配信・フォーム・複合機)が名簿に入っている
- 参照回数が10回以内(include の中身まで数えて)
- メールを送らないドメインに
v=spf1 -allを置いている - SPFだけでなく、DKIMとDMARCも設定している
今日やることは3つだけ
- いまのSPFを読む。
nslookup -type=txt 自分のドメインで、v=spf1の行が1つだけか、最後が~all/-allかを確認する。 - メールを送っているサービスを書き出す。メールソフト以外(予約・請求書・メルマガ・フォーム・複合機)も含めて一覧にし、名簿の include と見比べる。足りなければ既存の1行に書き足す。
- 使っていないドメインに
v=spf1 -allを置く。あわせてDMARC(まずはp=noneの監視モード)とDKIMの設定を予定に入れる。
SPFが1行・漏れなし・10回以内・all付き。これで「うちの名前のメールはここからしか出ない」という名簿が正しく公開されます。次の一歩はDKIMとDMARCです。
仕様の細かい話(RFC 7208)
判定結果は7種類
| 結果 | 意味 | 主な原因 |
|---|---|---|
| pass | 送信を許可された送信元 | 名簿の部品に一致 |
| fail | 許可されていない(強い主張) | -all などに一致 |
| softfail | たぶん許可されていない(弱い主張) | ~all に一致 |
| neutral | 何とも言わない | ?all、または all なしでどれにも不一致 |
| none | SPFがない | TXTに v=spf1 の行がない、ドメインが存在しない |
| temperror | 一時的なエラー | DNSのタイムアウトなど。再試行で直ることがある |
| permerror | 名簿そのものの誤り | SPFが複数、構文誤り、参照10回超え、void lookup 超過 |
知っておくと役に立つ仕様
| 項目 | 内容 |
|---|---|
| 照合の対象 | SMTPの MAIL FROM(Return-Path、RFC5321.MailFrom)のドメイン。MAIL FROM が空(エラー通知メールなど)の場合は HELO/EHLO の名前で照合する。ヘッダーFromは見ない |
| DNS参照の上限 | include・a・mx・ptr・exists・redirect の合計10回。超えると permerror |
| void lookup | 応答が空(NXDOMAIN や回答0件)の参照は2回までにすべき(SHOULD)。超えると permerror |
| mx の上限 | mx が指す受信サーバーの住所(A/AAAA)の問い合わせは10件まで。超えると permerror |
| include の意味 | 参照先の評価が pass のときだけ「一致」。参照先の fail は「不一致」として次の部品へ進む(参照先の -all がそのまま結果になるわけではない) |
| 文字数 | TXTの1文字列は255オクテットまで。複数文字列はすき間なしで連結される。DNS応答が収まるよう全体は450オクテット未満が目安 |
| レコード型 | TXTのみ。SPF専用のRR型(99)はRFC 7208で使われなくなった |
| ptr | 「使うべきでない(SHOULD NOT)」とされている |
| TTL | Microsoftは3600秒(1時間)以上を推奨 |
| 転送 | 転送先では送信元IPが転送サーバーになるためSPFは失敗しやすい。DKIMの署名を維持し、DMARCはDKIM側の一致で合格させる設計にしておく |
⚠ 「include したサービスの利用者全員」が合格になる
include: は、そのサービスの共用サーバー全体を名簿に入れることでもあります。同じサービスを使う別の利用者が、配送用の差出人にあなたのドメインを書いて送れば、SPFは合格してしまう可能性があります。DMARCでヘッダーFromとの一致を求め、DKIMで自分の署名を付けることで、この穴を埋めます。
SPFの書き方でよく聞かれること
DNSの画面の「ホスト名」には何を入れる?
ドメインそのもの(example.jp)のSPFなら、ホスト名は空欄か「@」にする管理画面が多いです。サブドメインなら「shop」のようにサブドメイン部分だけを入れます。表記は事業者ごとに違うので、各社のマニュアルを確認してください。
値を「”」(ダブルクォート)で囲む必要はある?
管理画面が自動で付ける場合と、自分で付ける場合があります。多くの管理画面では囲まずにそのまま入力します。長い名簿を分割する(例文11)ときだけ、区切りとして使います。
設定したのに反映されない
DNSの変更が世界中に行き渡るまで時間がかかります。Googleは最長48時間ほどと案内しています。nslookup で新しい値が見えるか確認し、見えていれば自分宛てのテストメールで判定を確かめます。
a と mx は書いたほうがいい?
WebサーバーやMXサーバーから実際にメールを送る場合だけ書きます。送らないなら不要で、書くと参照回数を1回ずつ使います。レンタルサーバーの自動設定に入っている場合は、そのままで問題ありません。
SPFを設定すれば、なりすましメールは来なくなる?
SPFは「自分のドメインを名乗る偽メール」を受け取る側が見抜く材料を公開するものです。他人のドメインを名乗る詐欺メールがあなたに届くのは防げません。また、SPFだけでは差出人欄の偽装を防げないため、DKIMとDMARCが必要です。
メールを送らないドメインにもSPFは必要?
必要です。SPFもDMARCもないドメインは、詐欺メールの差出人に使われても受け取る側が見抜けません。v=spf1 -all を置き、DMARCも p=reject で置いておくのが基本です。
📚 出典・参考資料(2026年9月30日確認)
仕様
- IETF「RFC 7208 Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1」(2014年4月)
https://www.rfc-editor.org/rfc/rfc7208
メールサービス・事業者の公式手順
- Google Workspace 管理者ヘルプ「SPF を設定する」(~all 推奨、連携サービス別の例文、反映まで最長48時間)
https://support.google.com/a/answer/33786?hl=ja - Google「メール送信者のガイドライン」(2024年2月1日から適用)
https://support.google.com/a/answer/81126?hl=ja - Microsoft Learn「Microsoft 365 ドメインの有効なメール ソースを識別するように SPF を設定する」(-all 推奨、パークドメイン、構文ミスの例、参照回数)
https://learn.microsoft.com/ja-jp/defender-office-365/email-authentication-spf-configure - エックスサーバー マニュアル「SPFレコード」(初期設定値、Gmail追加時の例)
https://www.xserver.ne.jp/manual/man_mail_spf.php
このサイトの関連記事
参照回数の表は、2026年9月30日に各社のSPFレコードをDNSで取得して数えたものです。各社の名簿の中身は変わることがあります。
📮 SPFは「名簿を1枚、漏れなく、書きすぎず」
表紙(v=spf1)→ 送信元 → 最後の all。形はいつも同じです。名簿ができたら、次は封印(DKIM)と照合ルール(DMARC)へ。


コメント