SPFとは

SPFを読むときの前提

SPF（Sender Policy Framework）は、そのドメインから送信してよいメール送信元をDNSのTXTレコードで示す仕組みです。受信側はEnvelope FromやReturn-Path側のドメインを基準に、送信元IPが許可範囲に入るかを確認します。

実務では、v=spf1、include、redirect、ip4/ip6、mx、a、all、DNS lookup数10回制限、外部送信サービス、転送経路、DMARC alignmentを分けて確認します。Fromヘッダーの見た目だけではSPFの対象ドメインは判断できません。

証跡には、対象ドメイン、SPF TXT、展開後の送信元、lookup数、allの強さ、Authentication-Results、Received、正規送信サービス一覧を残します。

送信元棚卸しから始める

SPFを強める前に、メールを送っている基盤を棚卸しします。Microsoft 365、Google Workspace、メール配信SaaS、監視通知、チケットシステム、複合機、Webフォームなど、見落としやすい送信元を確認します。

DNS上のincludeを見ただけでは、実際に使われている送信元か、すでに廃止済みか判断できません。受信側ヘッダーやDMARCレポートと突合します。

• 正規送信サービスと所有者を一覧化する。
• Authentication-ResultsとReceivedを保存する。
• 廃止済みincludeや広すぎるip4/ip6を棚卸しする。

10 lookup制限とincludeを確認する

SPFにはDNS lookup数10回の制限があります。includeを多用すると、送信元が正しくてもPermErrorになり、受信側で評価が失敗することがあります。

include先がさらにincludeやredirectを持つ場合は、展開して確認します。SaaSを追加するたびにSPFへincludeを足す運用では、lookup数と所有者が分からなくなりやすいです。

• SPFを展開してlookup数を確認する。
• include先の所有者と用途を記録する。
• 不要なincludeを削除できる条件を残す。

allの強さとDMARCを分ける

~all、-all、?all は、SPF不一致時の扱いの強さを示します。ただしSPFだけを強くしても、DMARCで見るFromドメインとのalignmentが合わなければ、なりすまし対策として期待どおりにならないことがあります。

転送メールではSPFが失敗しやすく、DKIMやDMARCの評価と合わせて判断します。SPFのpass/failだけで配送可否やなりすまし対策を断定しません。

• allの強さと変更理由を記録する。
• DMARC alignmentを確認する。
• 転送やメーリングリストの影響を見る。

変更証跡と引き継ぎ

SPF変更では、旧レコード、新レコード、追加/削除した送信サービス、lookup数、テストメールのヘッダー、戻し条件を残します。強いポリシーへ進める場合は段階的に影響を確認します。

引き継ぎでは、正規送信元台帳、DNS管理者、メール基盤管理者、関連語としてTXTレコード、DKIM、DMARC、MXを残すと確認しやすくなります。

• 変更前後のSPFとlookup数を保存する。
• テストメールのAuthentication-Resultsを残す。
• 送信サービス廃止時の削除条件を記録する。

関連語

同じ主要カテゴリの用語

メールの学習順

同じ主要カテゴリの用語をまとめて確認できます。現在の用語を起点に、前後の用語へ進むと文脈を保ったまま読み進められます。

InfraEngKit内の関連機能