10. Effects on Infrastructure (インフラストラクチャへの影響)
SPFの実装は、電子メールおよびDNSインフラストラクチャにさまざまな影響を与える可能性があります。管理者は、これらの潜在的な影響を認識する必要があります。
10.1 DNS Server Load (DNSサーバーの負荷)
SPFチェックには追加のDNSクエリが必要であり、DNSサーバーの負荷が増加する可能性があります。各受信電子メールに対して、受信者は次のことを行う必要があります:
- 送信ドメインのSPFレコードを照会
- メカニズムの追加のDNSルックアップを実行(A、MX、PTR、EXISTS、INCLUDE)
- include:メカニズムの再帰的なクエリを実行
Mitigation (緩和)
- DNSキャッシング: TTL値の適切な使用により、冗長なクエリを最小限に抑える
- ルックアップ制限: SPFはDNSルックアップの数を10に制限し、過度の負荷を防止
- 効率的なSPFレコード設計: メカニズムとincludeの数を最小化
10.2 Large Volume Mailing (大量メール送信)
大量の電子メールを送信する組織は、SPFレコードが次のことを確認する必要があります:
- すべての承認された送信IPアドレスをカバー: すべての正規のメールサーバー、サードパーティ、クラウドサービスを含める
- 正しく構造化: PermErrorまたは過剰なDNSルックアップを回避
- 定期的に更新: 送信インフラストラクチャが変更されたとき
Third-Party Senders (サードパーティ送信者)
サードパーティの電子メールサービス(マーケティングプラットフォーム、クラウドサービスなど)を使用する組織は、これらのサービスをSPFレコードで承認する必要があります:
v=spf1 include:_spf.example.com include:_spf.thirdparty.com -all
10.3 Email Forwarding (電子メール転送)
SPFは電子メール転送シナリオで問題を引き起こす可能性があります:
問題: 受信者が電子メールを別の受信者に転送すると、送信IPアドレスが変わります(現在は転送サーバー)が、MAIL FROMアドレスは元のままです。これによりSPFが失敗します。
Solutions (ソリューション)
- SRS (Sender Rewriting Scheme): 転送中にMAIL FROMアドレスを書き換え
- SPF NeutralまたはSoftFail: 影響を減らすために
-allの代わりに~allを使用 - DMARC統合: 転送シナリオを処理するためにDKIMと共にDMARCを使用
10.4 Mailing Lists (メーリングリスト)
メーリングリストは、電子メール転送と同様の課題に直面しています:
- メーリングリストサーバーは、元の送信者から多くの購読者にメッセージを転送
- MAIL FROMアドレスは元の送信者のままのことが多いが、送信IPはメーリングリストサーバー
Best Practices (ベストプラクティス)
- MAIL FROM書き換え: メーリングリストソフトウェアは、MAIL FROMアドレスをメーリングリストドメインに書き換える必要がある
- DKIM署名: メーリングリストは独自のDKIM署名を追加する必要がある
- List-IDヘッダー: List-IDおよびその他のヘッダーを使用してメーリングリストの起源を識別
10.5 IPv6 Considerations (IPv6に関する考慮事項)
SPFはIPv4とIPv6の両方をサポートしています。管理者は次のことを行う必要があります:
- ip6メカニズムを含める: 送信インフラストラクチャがIPv6をサポートしている場合
v=spf1 ip4:192.0.2.0/24 ip6:2001:db8::/32 -all
- デュアルエントリを維持: IPv4とIPv6の両方の範囲がカバーされていることを確認
- DNS AAAAレコード: AおよびMXメカニズムがIPv6アドレスを適切に解決することを確認
10.6 Subdomain Policies (サブドメインポリシー)
デフォルトでは、サブドメインは親ドメインからSPFレコードを継承しません。電子メールを送信する各サブドメインには独自のSPFレコードが必要です。または、親ドメインはワイルドカードレコードを公開する必要があります:
*.example.com. IN TXT "v=spf1 -all"
これにより、攻撃者が存在しないサブドメインをスプーフィングに使用することを防ぎます。