SPF フラットニングは DKIM と DMARC に影響するか？
SPF フラットニングは DKIM をまったく変えず、DMARC には間接的にしか影響しません。うまくメンテナンスされたフラットニングは SPF を10ルックアップ上限の内側に保って DMARC を強化しますが、古くなったレコードは DMARC を DKIM に依存させます。
手短に言えば、SPF フラットニングは DKIM をまったく変えず、DMARC には間接的にしか触れません。フラットニングはあなたの v=spf1 レコードが 評価される 方法を書き換えます。入れ子になった include: の連鎖を明示的な ip4:/ip6: エントリに置き換えるのです。しかし、DKIM 鍵、DKIM 署名、DMARC がアライメントする対象のドメインを変更することは決してありません。うまく行えば、フラットニングは SPF を 10 回のルックアップの上限より下に保ち、確実に合格させることで、実際には DMARC を 強化 します。まずく行えば（古くなった IP、大きすぎるレコード）、SPF を失敗させ、DMARC を完全に DKIM に依存させることになります。
その 1 つの区別を理解すれば、あとはすべてそれに従います。このページでは、3 つのプロトコルがどのように相互作用するかを正確に説明し、恐れではなく自信を持ってフラットニングできるようにします。
SPF、DKIM、DMARC は実際どう関係するのか
3 つのプロトコルは異なる仕事をしており、SPF フラットニング の影響を受けるのはそのうち 1 つだけです。
- SPF は、接続元 IP が SMTP エンベロープ（MailFrom / Return-Path）のドメインを代理して送信することを認可されているかどうかをチェックします。評価は DNS メカニズム（
include:、a、mx、ptr、exists、redirect）を辿り、RFC 7208 に従って 10 回の DNS ルックアップに制限されます。この上限を越えるとPermErrorになり、それはそのドメインからの すべての メッセージに対する SPF の失敗としてカウントされます。 - DKIM は、秘密鍵を使って各メッセージに暗号署名を付け、DNS に公開された公開鍵に対して検証します。SPF からも接続元 IP からも完全に独立しています。
- DMARC はこの 2 つを結び付けます。SPF または DKIM のどちらかが合格し、かつ 可視の
From:ドメインとアライメント（緩和または厳格）したときに合格します。両方が失敗した場合、DMARC はあなたのポリシー（p=none、p=quarantine、p=reject）を適用します。
フラットニングは完全に SPF の箱の内側に収まります。それは SPF レコードの 構造 を変えるのであって、関わる ドメイン を変えるのではありません。だからこそ、設計上、DKIM の署名や DKIM のアライメントを変えることはできないのです。
SPF フラットニングは DKIM に影響するか？
いいえ。直接的にも、署名にとって意味のある形でも影響しません。DKIM は、あなたの送信プラットフォーム上の秘密鍵と、selector._domainkey.yourdomain.com にある公開鍵に依存します。フラットニングはそのどちらにも触れません。あなたのセレクタ、鍵長、正規化（c=relaxed/relaxed 対 simple/simple）は、フラットナーが v=spf1 TXT レコードに対して行う何によっても、そのままです。
言及に値する 間接的 な関係がちょうど 1 つあります。フラットニングがうまく行かなくなった瞬間、DKIM はより重要になります。フラットニング済みレコードが古くなり SPF が失敗し始めると、DMARC が合格するための道は 1 つ、DKIM だけになります。したがって、健全でアライメントされた DKIM 設定は、SPF の不調時のあなたの安全網です。これは DKIM を強く保つべき理由であって、フラットニングを避ける理由ではありません。
SPF フラットニングは DMARC に影響するか？
はい。ただし通常は良い方向にです。DMARC の SPF 経路は、SPF がクリーンに評価され、かつ MailFrom ドメインが From: ドメインとアライメントしたときに合格します。フラットニングはその方程式の前半を改善します。
- ルックアップが減り、エラーが減る。
include:の連鎖を IP リテラルへ折りたたむと、評価は通常 10 回超のルックアップから 1〜3 回へ下がります。これは（ルックアップ過多による）PermErrorを解消し、そうでなければ SPF 失敗として記録される（DNS タイムアウトによる）TempErrorを減らします。そして DMARC は SPF のPermErrorを失敗として扱います。 - アライメントは変わらない。 フラットニングは MailFrom や
From:のドメインに触れないため、アライメント自体を助けも損ないもしません。単に、そもそも SPF が正常に評価できる可能性を高めるだけです。
実際には、うまくフラットニングするチームは、SPF 経路がエラーを起こさなくなるため、DMARC の「SPF アライメント合格」率が大きく上昇するのを目にします。その利得は本物ですが、DMARC がチェックする内容を変えることからではなく、信頼性から生まれます。
フラットニングが DMARC を損ないうる唯一の道
フラットニングはサードパーティの IP をあなたのゾーンに固定します。プロバイダーが送信プールをローテーションすると、古くなったフラットニング済みレコードは新しい IP を取りこぼし、正規のメールが SPF に失敗します。そうなると DMARC は DKIM にフォールバックします。DKIM が存在しアライメントしていれば、メールはなお合格します。DKIM が欠けているかアライメントしていなければ（トランザクションやトリガー送信ではよくあります）、DMARC は失敗し、p=quarantine や p=reject のもとでそのメールは保留または跳ね返されます。
したがってリスクはフラットニングそのものではありません。リスクは メンテナンスされない フラットニングです。これは、このページ全体で最も重要な運用上の要点です。
なぜメンテナンスがすべてなのか
ベンダーの IP レンジは絶えず変わります。大手 ESP や CDN は数週間ごとに、ピークイベント時にはさらに速くレンジをローテーションします。今日あなたが手作業でフラットニングしたレコードは、今日は正確でも、明日にはドリフトしていきます。2 つの故障モードが続きます。
| 古いレコードの症状 | 何が壊れるか | DMARC への影響 |
|---|---|---|
| 新しいプロバイダー IP の欠落 | 正規のメールが SPF に失敗する | DMARC が DKIM に依存する。DKIM が不在/不整合なら失敗 |
| 廃止された IP の保持 | 再割り当てされた IP があなたのドメインで SPF を通しうる | なりすましの窓 — 新しいテナントが「認可された」メールを送れる |
どちらも回避可能ですが、それはレコードを厳しい周期で再解決する自動化によってのみ可能です。こここそ、AutoSPF が助けとなるよう作られている場所です。15 分ごとに再スキャンし、上流の IP が変わった瞬間にレコードを自動更新 し、そして あなたの include が解決するのとまったく同じ IP に解決します。過剰な認可もなく、悪用のために開かれたままの広いスーパーネットもありません。その組み合わせが、古い IP による到達性の隙間と、手動フラットニングが残すなりすましの窓の両方を閉じます。
レコードを安全に保つ：サイズ、ルックアップ、単一レコードの原則
古さ以外にも、3 つの技術的制約が、フラットニングされた SPF が DMARC を壊すのを防ぎます。
- レコードは 1 つだけ。 ドメインは
v=spf1で始まる TXT レコードをちょうど 1 つだけ公開できます。2 つあるとPermErrorが生じます。サイズのために分割しなければならない場合は、同じ TXT レコード内の複数の文字列に分割してください。決して別々のレコードに分けてはいけません。 - バイト予算に注意する。 各 TXT 文字列セグメントは 255 文字に制限されます（実装はそれらを連結します）。合計を約 450〜600 バイト未満に余裕を持って保ちましょう。大きすぎるレコードは、リゾルバ間で切り詰めやフラグメンテーションのリスクを負います。
- 10 回のルックアップの内側にとどまる。 入れ子の
include:、a、mx、existsを残す部分的なフラットニングは、依然として上限に引っかかりうります。ip4:/ip6:リテラルを優先し、非推奨のptrを除去し、連続するレンジを CIDR に圧縮しましょう。
終端の修飾子は意図的に保ちましょう。ポリシーに応じて -all（ハードフェイル）または ~all（ソフトフェイル）で終えます。完全な仕組みは SPF レコードをフラットニングする方法 で学べます。マクロベースのアプローチと天秤にかけているなら、SPF フラットニング対マクロ をご覧ください。
フラットニングが解決できないこと
フラットニングはルックアップとタイムアウトのエラーを解決します。次のことは 解決しません。
- 転送。 メッセージが転送されると接続元 IP が変わるため、あなたのレコードがどれだけクリーンでも、あなたのドメインの SPF は失敗します。解決策は、転送側での SRS か、あるいはより確実には、転送を生き延びるアライメントされた DKIM です。これこそ、DKIM が常に一級市民でなければならない理由です。
- ベンダーの不整合。 ESP が、あなたの
From:ドメインのサブドメインでないバウンスドメインで送信すると、何をしても厳格な SPF アライメントは失敗します。これは MailFrom の設定の問題であって、フラットニングの問題ではありません。
これらのケースでの答えは、より積極的なフラットニングではなく、DKIM + DMARC（および中継点での SRS/ARC）です。
推奨される姿勢
最も安全な構成はハイブリッドです。ルックアップの多い安定したプロバイダーをフラットニングして上限の内側にとどまり、本当に動的な送信者はベンダー管理の include に残し、すべてのストリームでアライメントされた DKIM を強制し、DMARC 集約レポートを監視して、SPF と DKIM のどちらが実際に合格を担っているかを把握します。
何かを変える前に、今日の自分の立ち位置を確認しましょう。現在のレコードを SPF Checker で実行し、ライブのルックアップ数を見て、上限へ押し上げている include を見つけ、それから何をフラットニングするかを決めます。AutoSPF でリフレッシュを自動化すれば、フラットニングの唯一の本当のリスクであるドリフトが、解決済みの問題に変わり、フラットニングされた SPF が DMARC を静かに損なうのではなく 強化 するようになります。
よくある質問
SPF フラットニングは私の DKIM 設定を変えますか？
いいえ。フラットニングは SPF レコードの評価方法を書き換えるだけで、include: の連鎖を ip4:/ip6: リテラルに置き換えます。DKIM の秘密鍵、公開鍵、セレクタ、署名には決して触れません。唯一の関わりは、強くアライメントされた DKIM 設定が、フラットニングされた SPF レコードがいつか古くなって SPF が失敗した場合の DMARC の安全網として働くことです。
SPF フラットニングは DMARC を壊しますか？
メンテナンスされていれば、いいえ。DMARC は SPF または DKIM のどちらかがアライメントしたときに合格するため、うまくメンテナンスされたフラットニングは、SPF を 10 回のルックアップ上限の内側に保って確実に合格させることで、実際には DMARC を改善します。DMARC が損なわれるのは、フラットニング済みレコードが古くなり、SPF が失敗し始め、そしてメッセージを支える DKIM がそこにない場合だけです。
SPF フラットニングは安全ですか？
はい、自動化されていれば。唯一の本当のリスクはドリフトです。プロバイダーが IP をローテーションし、静的なフラットニング済みレコードが古くなり、SPF の失敗を引き起こしたり、廃止された IP を認可したまま残したりします。頻繁に再スキャンし、正確な上流 IP へ再解決するツール（AutoSPF は 15 分ごとにチェックします）は、そのリスクを取り除きます。手動の、設定して忘れるフラットニングこそ、危険が潜む場所です。
SPF が完璧にフラットニングされていれば、DKIM はまだ必要ですか？
絶対に必要です。DKIM は最も信頼できる DMARC 合格経路です。SPF が設計上失敗する転送やメーリングリストを生き延びるからです。完璧なフラットニング済みレコードでさえ一時的な DNS の問題に見舞われることがあり、その瞬間に DMARC を合格させ続けるのが DKIM です。フラットニングを DKIM の代替として扱ってはいけません。
SPF フラットニングはメールのなりすましを引き起こしますか？
怠慢を通じてのみ引き起こされます。フラットニング済みレコードが、プロバイダーが廃止した IP を保持し続け、それらの IP が新しいテナントに再割り当てされると、そのテナントがあなたのドメインで SPF を通してしまう可能性があります。あなたの include が解決するのとまったく同じ IP へフラットニングし、廃止されたレンジを自動的に刈り取ることが、この過剰な認可を完全に防ぎます。
フラットニングされた SPF レコードはどのくらいの頻度で更新すべきですか？
プロバイダーが IP を変えるのと同じ頻度で、動的なクラウド送信者では数日ごとになることもあります。手動更新ではそのペースに追いつけません。だからこそ自動化が重要です。AutoSPF は 15 分ごとに再スキャンし、上流の IP が変わった瞬間に再公開するため、レコードが SPF を壊したり、なりすましの窓を開いたままにしたりするほど大きくドリフトすることはありません。