Googleのドメイン認証強化切り替えスケジュールとDMARC導入の注意点

◆Googleドメイン認証強化のスケジュール

Google宛のメッセージの送信ドメイン認証が2月に強化されましたが、皆さまいかがでしょうか？
「思ったほど影響がなかった」
「特に何も問題ないみたい」
という、杞憂だったかな？と思う方もいらっしゃるかもしれません。
ただ、警戒を解くのはもう少しお待ちください。

2月に有効化されたのは、送信要件を満たしていない送信者に対し、一時的にエラーコードを返すのみの処置なので、メールが届かない状況になることは少ない可能性があります。DMARC認証もまだ実施されていません。

Googleが公式に発表しているスケジュールによると、早ければ2024年6月からルールが厳しくなります。（本記事執筆時点）
※内容は変更される可能性があります。
つまり、実際に影響が出てくるのは6月以降の可能性があります。
それまでに、Googleから返されるエラーコードをもとに修正していくことはもちろんですが、以下にDMARC導入における注意点を記載しますので、6月からの本格運用に備えて、設定を見直しましょう。

◆DMARC導入が失敗してしまう理由

DMARC（Domain-based Message Authentication, Reporting, and Conformance）の導入において、SPF（Sender Policy Framework）およびDKIM（DomainKeys Identified Mail）の設定に関する失敗はDMARC認証が失敗する要因となります。
また、SPF・DKIMの設定が正しくされていない場合、誤検知を恐れ、いつまでもp=noneのままで運用してしまう可能性があります。
p=noneのDMARCポリシーでは、実質的になりすまし対策になりません。
メール送信要件をクリアするためだけにDMARCレコードを設定するのではなく、なりすまし対策として有効な手立てを十分に活用できるよう、DMARCポリシーの移行（p=quarantine/reject）をご検討ください。

◆見直しポイント

見直しポイント①： SPF設定の不一致の有無
SPFで指定された送信元IPアドレスが、実際のメール送信に使用されるメールサーバーのIPアドレスと一致しない場合、SPFの検証が失敗し、DMARCがポリシーに基づいてメールを処理します。
一致しない例として、下記のようなケースが考えられます。

・SPFレコードに、正規利用サーバやサービスの送信元IPアドレスが登録されていない
・転送メール

すべての送信元IPアドレスをSPFレコードに登録することが難しいケースもあります。
また、転送メールも、送信元IPアドレスが変わってしまうため検証が失敗しますので、対応が必要です。
このように、SPFレコードだけでは対応できないケースの場合、DKIMも一緒にご利用いただくことをご検討ください。
SPFのアライメントに失敗しても、DKIMのアライメントがあるため、DMARC認証の失敗を削減できます。

見直しポイント②： DKIMの不正確な設定
DKIMが失敗する原因は多岐にわたりますが、主な例として下記が考えられます。

・DKIMで使用される鍵ペアの情報が一致せず、正しく認証できない
・DKIM署名がメールに正しく含まれていない、あるいは無効化されてしまっている
・DKIMレコードや構文に誤りがある

DKIMの公開鍵と秘密鍵が正確に一致していること、DKIMレコードに誤りがないか、セレクターの指定なども含めてご確認ください。
また、メールヘッダーにDKIM署名が正しく含まれているかどうかも確認します。
DKIM Canonicalization（正規化）にもご注意ください。

見直しポイント③： DMARCレコードの設定 DMARCレコードにおいて、SPFやDKIMの結果に対する処理が不正確であると、メールサーバーがメールを適切に処理できませんので、上記①②をしっかり対応していただくことが成功の鍵となります。
その他、DMARCレコードで指定するタグが正しい構文で記述されていることをご確認ください。

DMARCポリシーのタグ一覧

なお、受信機側の対応によっては上記の指定通りに動作しない可能性があります。

◆DMARC認証の主な失敗パターン

また、DMARCレコードの十分な解析やチューニングを行わずにDMARCポリシーをp=rejectやp=quarantineに変更した場合、正当なメールが拒否されてしまう可能性があります。

DMARC認証の失敗パターンはいくつか考えられますが、特にクラウドサービスでよく見られるのが、“SPF/DKIM認証は成功しているけれどもDMARC認証は失敗する”パターンです。
もちろんなりすましメールが正常にブロックされているだけとも考えられますが、正当なメールでも設定によっては起こりえます。例を挙げて見てみましょう。

クラウドサービスでは独自の自社ドメイン①をエンベロープFrom、DKIM署名を使用してメールを送信していることが、往々にして多くあります。そうすると実際にサービスを利用しているユーザーが使用するドメイン②と乖離が発生し、DMARC認証が失敗してしまうのです。こうした場合、エンベロープFromの修正、もしくはDKIM認証でのDMARC導入を検討する必要があります。

このようにDMARC認証が失敗しているメールにはどんなものがあるか、なぜ失敗しているかをDMARCレポートから読み解き、正当なメールで失敗している場合は必要に応じたチューニング作業を行います。正当なメールがブロックされるのを防ぐために、DMARCポリシーの変更は不正確な設定を修正した後に実施すべきです。

◆まとめ

DMARCの導入において、SPFやDKIMの設定が不正確であると、メールが適切に処理されない可能性があります。しっかりした検証と修正が大切です。
また、DMARCポリシーにおいて、p=quarantineやrejectへの移行は、十分なDMARCレポートの解析および適切にチューニングした後に実施する必要があります。

DMARCポリシーをp=noneのまま運用していくことは、なりすまし対策になりません。p=quarantineやrejectへの移行を行うことで、所有ドメインのサイバーセキュリティを強化し、ドメインの信頼性を高めることが可能になります。

p=quarantineやp=rejectへの移行にお悩みの方はこちら、下記リンクからお気軽にお問合せください。