メール認証は1つの設定ではなく、スタックとして機能する5つのDNSレコードです。このチェッカーはそれらを一度にすべて取得するので、1つずつレコードを追いかける代わりに全体像を把握できます。ここでは、その監査結果の読み方と、正しい順序で修正する方法を解説します。
完全な監査がカバーする範囲
完全なチェックでは、SPF（どのサーバーが送信できるか）、DKIM（メッセージが改ざんされていないことを証明する署名）、DMARC（SPFとDKIMをあなたのFromドメインに結び付けるポリシー）、MTA-STS（転送中のTLS暗号化の強制）、TLS-RPT（暗号化失敗の報告）を確認します。ドメインは1つに合格して残りに失敗することがあるため、これらをまとめて監査することが、実際に保護されているかを知る唯一の方法です。
結果の読み方：健全 vs 破損
- SPF - 存在し、有効で、10 DNSルックアップ未満であること。確実を期すにはSPF構文をチェックしてください。ここでのPermErrorは、DMARCを静かに壊します。
- DMARC -
_dmarcに存在し、p=noneより強いポリシーと報告先アドレスを備えていること。 - DKIM - 強力な（2048ビット）鍵を公開する、少なくとも1つのアクティブなセレクタがあること。
- MTA-STS / TLS-RPT - TLSを強制する公開ポリシーと、失敗レポートを受け取るアドレスがあること。
修正する順序
各層は下の層に依存するため、下から上へ進めます。まずSPFから始めます。これは土台であり、合格しアライメントの成立したSPFまたはDKIMの結果がなければDMARCは強制できません。次にDKIM署名を確認します。それからDMARCポリシーをnoneからrejectへと引き上げます。その後でMTA-STSとTLS-RPTで転送のセキュリティを追加し、最後にロゴを表示するためのBIMIを追加します。BIMIはそもそも動作させるためにDMARCの強制が必要です。
ドメインが最もよく失敗する箇所
- SPFが10ルックアップ上限を超えている - 最もよくある失敗であり、AutoSPFがincludeをフラット化して自動的に修正する対象です。
- DMARCが
p=noneのまま - 公開されているが強制されておらず、何の保護も提供しません。 - MTA-STSがない - メールは配信されますが、ダウングレード攻撃に対する保護はありません。
- VMCなしのBIMI - Verified Mark Certificateがなければ、GmailやApple Mailでロゴは表示されません。
送信サービスを追加したりプロバイダーを変更したりするたびに、この監査を再実行してください。定期的なSPFレコードのチェックは、ずれを早期に検出します。そして、上でリンクした各専用ツールで各層を修正しましょう。SPFを正しく設定することは、他のすべての前提条件です。AutoSPFがSPFを有効かつルックアップ上限内に保つので、スタックの残りの部分は確かな土台の上に築かれます。