この記事の結論
新サービスの案内をそのまま追加し、同じ名前にSPFを複数作ると認証エラーの原因になります。まず送信経路を棚卸しし、既存の許可と統合する範囲を確認します。
表示される差出人だけで判断しない
SPFが確認するドメインは通常、配送時のMAIL FROMに使われるものです。画面上のFromと同じとは限りません。社員メール、請求サービス、メルマガ、Web通知について、送信サービスと認証対象ドメインを記録します。サービス独自の戻り先ドメインを使う構成も確認します。
既存のSPFと統合する
同じドメインまたはサブドメインのSPFは、一つのレコードとして管理します。追加時は既存内容を保存し、提供元の手順に従って必要な要素を統合します。TXTは別用途にも使うため、SPF整理のために全TXTを削除しません。担当不明の許可は契約と利用ログを調べます。
includeの数だけで判断しない
SPFにはDNS参照を伴う評価の上限があり、参照先がさらに別の情報を参照する場合もあります。Microsoftは10回を超える参照によるエラーに注意を促しています。表面上のinclude数だけでなく、全送信経路の評価を確認します。動的な送信アドレスを独断で固定IPへ置き換えることも避けます。
既存経路の試験と撤去まで行う
変更後は新サービスだけでなく、既存のメールや通知も試験し、受信側の認証結果を確認します。SPF成功だけでDMARC成功や配送が保証されるわけではありません。サービス終了時は利用停止を確認して許可を削除し、変更日と担当を記録します。
| 項目 | 記録内容 | 目的 |
|---|---|---|
| 業務 | 請求・通知・配信と担当 | 設定責任者を明確にする |
| 認証 | MAIL FROMドメイン・設定先 | 編集するDNS名を特定 |
| 履歴 | 導入日・検証結果・終了予定 | 不要な許可を残さない |
導入・見直しのチェックリスト
- 全ての正規送信元を把握したか
- SPF重複とDNS参照数を確認したか
- 既存経路も試験したか
参考資料と確認範囲
- Microsoft：SPFの構成 — 対象ドメイン・単一レコード・DNS参照制限。台帳は編集部の提案です。