🔥
Mail.RuのDMARCレポートで発覚:Google Workspaceのメール認証が失敗していた話と対策
Google Workspace メール認証の落とし穴と対策
▶ はじめに
最近、Mail.Ruから届いた一通のメールをきっかけに、Google Workspace で使っているメールアドレスが正しく認証されておらず、第三者によるなりすましの対象になっていた可能性に気づきました。
この記事は、その経緯と、その対策として行った3つの重要なDNS設定についてまとめたものです。
▶ なりすましメールに気づいたきっかけ
Mail.Ru から届いた「This is an aggregate report from Mail.Ru」というメールに、DMARC集計レポート(.xml.gz形式)が添付されていました。この内容を解析したところ、自分の管理する独自ドメインを名乗った不明なIPからメールが送信されていることがわかりました。
▶ 原因:メール認証設定が不完全だった
- SPFレコードはあるが、「include:_spf.google.com」のみでは不十分
- DKIMは
google._domainkey
として設定したが、WordPressのDNSでTXTが2分割され、Googleで認証失敗 - MXレコードが誤って
smtp.google.com
になっていた - DMARCは
p=none
のままで、報告はあるが実際のブロックは何もされない
▶ 対応1:MXレコードの修正
Google Workspace の正しいMXレコードに設定し直しました:
ASPMX.L.GOOGLE.COM (1)
ALT1.ASPMX.L.GOOGLE.COM (5)
ALT2.ASPMX.L.GOOGLE.COM (5)
ALT3.ASPMX.L.GOOGLE.COM (10)
ALT4.ASPMX.L.GOOGLE.COM (10)
▶ 対応2:DKIMの再生成と再設定
- WordPressのTXT分割により、
google._domainkey
の認証は失敗 - そのためGoogle Workspaceで 新しいセレクタ名
gw202405
を使用して再生成 - WordPress.comのDNSに、1行のTXTとして設定し、Google側で「認証開始」を実行
▶ 対応3:DMARCポリシーの強化
最初は気づかず p=none
のままでしたが、現在は次のように強化しています:
v=DMARC1; p=quarantine; pct=100; rua=mailto:report@example.com;
-
p=quarantine
で、認証失敗メールを迷惑メールへ - レポートは手動で受信し、解析中
▶ 実際のDMARCレポートの確認
- Mail.Ru、Google、Outlookなどから .xml.gz 形式でメール届く
- 内容は IP / SPF-DKIM 成否 / 送信元など
- より見やすくするには、Postmark や DMARC Analyzer などのツールが便利
▶ まとめ
- メールセキュリティは DNS設定の精密さが削られる
- SPF / DKIM / DMARC の3つの認証は、すべて正しく設定するまで助け合うと確実
- DKIMのTXT分割は特に要注意
- この記事が、同じような問題を抱える方の参考になれば幸いです
Discussion