DNSとメールのセキュリティ：SPF・DMARC・CAAの読み方

DNSを変える前に送信元を把握する

社員メール、サポート、取引通知、請求、マーケティング、稼働中の旧サービスを列挙します。表示Fromドメイン、エンベロープ送信者、DKIM署名ドメイン、責任者を記録します。各提供元に現在必要なDNS記録を確認し、別会社から推測したincludeをコピーしないでください。

問い合わせ名、結果、時刻を残します。DNSタイムアウトと、権威サーバーが記録不存在を返すことは別です。予想外の結果はDNS提供元で確認し、キャッシュも考慮します。MXは受信を示しますが、MXなしで送信するドメインもあります。MXがなく警告されないことは、安全な送信の証拠ではありません。

ポリシーの問題を適切な大きさで判断する

ポリシーの弱さは、偽メールが届いた証拠ではありません。記録の存在確認が通っても配送保証ではありません。悪用が信頼を直接損なうログインリンク、請求、サポートのドメインを優先します。

正規の送信を維持してSPFを修正する

SPFは接続した送信者をエンベロープドメインのポリシーで評価し、表示Fromを直接認証するものではありません。実際の提供元に合わせた一貫した単一ポリシーを公開します。+allは避け、正規送信の試験後に最終ポリシーを選びます。

評価中のDNS参照を伴う項目は、入れ子のincludeやredirectを含めて10個までです。Sitelemetryのテキスト上の計数は早期警告で、再帰的な完全評価ではありません。提供元の指針で全体を確認します。使わない送信者や不要な仕組みから削除します。includeを安易に固定IPへ置き換えると、提供元の基盤変更時に保守問題が生じます。

DMARCを監視から段階的な強制へ進める

DMARCは表示Fromを、アライメントしたSPFまたはDKIM認証に結び付けます。どちらかの整合した認証で通る場合があり、必ず両方が必要ではありません。DKIMセレクターは提供元ごとに異なり、公開スキャンが全署名キーを推測することはできません。

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

監視ポリシーの例です。自分で管理し報告を処理できる宛先に変更します。外部宛先にはDNSによる許可が必要になる場合があります。転送の影響も含め全正規フローと報告を確認し、整合性を直してからquarantineやrejectへ進めます。不完全な送信元一覧で拒否を強制し、請求やパスワード再設定メールを失わないようにします。

RFC 9990：DMARC集約レポート

CAAとMTA-STSの役割を分ける

CAAは証明書を発行できる認証局を示します。CDN管理の証明書やワイルドカードを含む実際の提供元に制約を合わせてください。不適切な制約は更新を止めます。CAAがないことは改善余地であり、攻撃者が証明書を持つ証明ではありません。

MTA-STSは対応送信者が受信メール配送に公開TLSポリシーを適用できる仕組みです。TXTは一部分で、HTTPSファイル、MXパターン、メールサーバー証明書が一致する必要があります。強制前に全体を試します。WebサイトのHTTPSとは別で、TXTがないことは全メールが平文という証拠にはなりません。

記録と実際の配送を確認する

1. 現在のDNS値と各サービスの責任者を保存する。
2. 確認した変更を権威DNSで公開し、問い合わせ名を確認する。
3. 関係するキャッシュ時間後に再確認し、同じ監査範囲を繰り返す。
4. 各正規サービスから自分のテストアカウントへ管理されたメールを送る。
5. 受信側の認証結果とDMARC報告を確認し、再設定、請求、サポート返信の到達を確かめる。

ポリシー検査と配送監視を分けます。認証が通っても評判、受信フィルター、本文は配送に影響します。DNSエラー、未評価セレクター、未試験サービスを記録し、緑の要約で未確認範囲を隠さないようにします。