メールの認証まわりを調べていると、ときどきこういう状況に出くわします。
自分のドメインにSPFレコードを設定していないのに、送ったメールが『SPF pass』になっている。逆に、SPFを厳しくした途端に一部のメールが急に届かなくなる。
最初に見たときは「本当に？」と思いますが、仕組みがわかればすっきり説明できます。
配信ベンダーが持つ「専用ドメイン」の役割
SPF認証は、エンベロープFrom（見えない送信者）のドメインに対してチェックをかけます。Fromヘッダ（見える送信者）ではありません。
メール配信サービスに登録して使うと、実際にメールを投函するのはそのサービスのサーバーです。このとき、エンベロープFromにはベンダーが管理する専用ドメインが使われることが多い。たとえば bounces.配信サービス名.com のようなドメインです。
このベンダー側のドメインには、ちゃんとSPFレコードが設定されています。だから「自社ドメインにSPFレコードがなくても、ベンダー側のドメインでSPFがpassになる」という状態が起きます。受信側はそのドメインのSPFをチェックして合格と判定する。自社ドメインは関係ない。
自社ドメインのSPFレコードを確認してもなにも書いてないのに認証が通る、というのはこういう仕組みです。
-allを設定したら急にメールが弾かれた
問題が起きるのは、ここからです。
SPFの記法で末尾に -all（hardfail）をつけると、「このリストに載っていないIPからの送信は全部NG」という意味になります。~all（softfail）は「怪しい」程度ですが、-all は「拒否」です。
自社ドメインのSPFレコードを新規に作るとき、あるいはセキュリティ強化のために -all に変えたとき、急にメールが届かなくなる事故が起きやすい。
原因は決まっています。配信ベンダーのサーバーIPが、自社ドメインのSPFレコードに含まれていないからです。
ベンダーが専用ドメインで送信してくれているから今まで問題なかったのに、自社ドメインのSPFを厳しくした結果、別の経路で飛ばしているメール（WordPressのフォーム通知、GASのスクリプト経由の自動メールなど）が弾かれ始める。
メールヘッダを読んで何が起きているか確認する
詰まったときにまずやるのは、ヘッダの確認です。Gmailなら「メッセージのソースを表示」で全文が見られます。
確認する箇所は2つです。
ひとつは Received: from の行。メールがどこのサーバを経由してきたかがわかります。最後に届いた受信サーバのほうから順に読んでいくと、実際の送信元IPが見える。
もうひとつは認証結果です。
Authentication-Results: mx.google.com;
spf=fail (google.com: domain of info@example.com does not designate X.X.X.X as permitted sender)
こんな表示が出ていたら、そのIPアドレスがSPFレコードに含まれていないという状態です。X.X.X.X の部分に出てくるIPが、弾かれている送信元です。
このIPが何者かを調べます。逆引きすれば大抵わかります。WordPressのホスティング会社だった、使っている配信サービスのサーバーだった、GASの実行サーバーだった、といった具合です。
対処は「includeを追記する」だけ
原因がわかれば対処はシンプルです。弾かれているIPが属するサービスのSPFレコードを、自社ドメインのSPFに include: で追加します。
配信ベンダーのヘルプには必ず「SPFレコードに追加するinclude文」が書いてあります。たとえば include:_spf.○○○.com のような書き方です。自社ドメインのSPFレコードに、そのincludeを足す。
v=spf1 include:_spf.google.com include:配信ベンダーのSPF ~all
この要領で、使っているすべての送信経路をSPFに列挙します。Gmailを使ってメールを送る、WordPressのサーバーからもフォーム通知が飛ぶ、配信サービスからもメルマガが出る、という状況なら、それぞれのincludeが必要です。
-allか~allか、最初に迷うところ
これはよく聞かれます。私は「最初は ~all から始める」派です。
-all のほうが厳格で、なりすまし防止効果は高い。でも、送信経路の棚卸しが不十分な状態で -all にすると、自社のメールが黙って消えていく事故が起きます。
順番はこうです。~all でSPFを設定してDMARCのレポートを有効にする。レポートを数週間眺めて「どのサーバからメールが出ているか」を全部把握する。全部includeに収まったと確信したら、-all に変える。
DMARCレポートはXML形式なので読みにくいですが、無料の可視化ツールに食わせるとIPのリストが一覧で出ます。これが棚卸しの代わりになります。
棚卸しは一度でいい
メール認証で詰まる案件を見ていて共通しているのは、「SPFに何が書いてあるかわからないまま何年も運用している」パターンです。
担当者が変わるたびにincludeが増えていて、どれが何の経路か誰もわからない。そこへセキュリティ強化で -all に変えようとして、フォームの通知メールが届かなくなって気づく。
dig TXT 自社ドメイン を実行すると今のSPFレコードが出ます。そこに書いてあるincludeを一行ずつ追いかけて、「これは何のサービス」と書き出す。それだけで全体像が見えます。
「レコードがないのにpassになる」と「-allで急に弾かれた」は、仕組みの裏表です。どちらも起点は「エンベロープFromのドメインのSPFを受信側がチェックする」という一点。ここが腑に落ちると、ヘッダを見て自分で原因を追えるようになります。