Googleの新しい送信者ガイドラインに備えてDMARCレポートに基づいて具体的にやったこと
2023年10月にGoogleとYahoo!がメール送信者向けのガイドラインを更新してから早3か月。いよいよ適用開始の2024年2月が近づいてきました(ドキドキ)。
私は昨年から本件の対応を進めていて、地味に大変だな、と感じています。多くの企業では自社ドメインから様々なメールを送信していると思います。利用しているツール・サービスも様々で、たとえば、Sendmail/Postfix/Eximのサーバを立てている、Google WorkspaceやMicrosoft 365を使っている、といった他に、CRMであるSalesforce、マーケティングツールのHubspotやAccount Engagement(旧Pardot)、メール送信用のAmazon SESやSendGridを使っているなど、多くのツール・サービスを併用している企業が多いのではないでしょうか。
そういった状況では自社のどこからどんなメールが送られているのか整理するのも大変です。そこでDMARCのレポートが重要になります。
DMARCは設定したら完了ではなく、設定してからが始まりです。今回Gmailのbulk sender[1]としての要件をしっかり満たすためには、細かい送信状況を把握してSPFやDKIMの設定、必要に応じてアライメントの調整などを進めていく必要があります。
本記事では私が実際に行った実務目線で内容をまとめます。
作業内容
作業は次の順に進めました。
1.DMARCレコードを設定する
2.DMARCレポート(RUA)を受信する
- Valimailを導入
- 個別に自社メールでも受信
3.受信したレポートを解析してSPFやDKIMの設定に抜け漏れがないか確認する
4.必要に応じて情シスや各部門と調整して抜け漏れに対応する
私が対応したケースでは利用ドメインが一つのため最初から1に着手できました。企業内で様々なドメインを利用している場合は1の前にドメインの整理が必要です。この辺りはナリタイの「DMARCを使う」で紹介されているのでご参照ください。
1.DMARCレコードを設定する
何はともあれまずは自社ドメインに対してDMARCレコードを登録するところから始めます。DMARCは自社ドメインがなりすまし等で使われた際に、そのメールを受信者がどのように扱うか(スパムとして迷惑メールフォルダに入れる、メールを拒否して受け取らないなど)、送信者が決めるための方法です。
メールの扱いを決めるポリシー(policy)はpタグで定義します。既に運用しているメールドメインであれば最初はp=noneに設定するのが無難です。noneは特定のアクションを要求しない、つまり受信者に従来どおりの振舞いをするように伝えます。
この時点での登録イメージはこちらです(これ以降、自社ドメインをexample.comと表記します)。続けてDMARCレポートを受信するための定義を追加します。
Host | Type | Value |
---|---|---|
_dmarc.example.com | TXT | v=DMARC1; p=none; |
2.DMARCレポート(RUA)を受信する
DMARCでは受信サーバの認証結果などをレポートする機能があります。
- RUA Report(Reporting URI for Aggregate report)...集計レポート
- RUF Report(Reporting URI for Forensic/Failure Report)...失敗レポート
送信状況を分析するためにRUA Reportの送り先を設定します。自社ドメインのメールで受信する場合は次のように定義します。
Host | Type | Value |
---|---|---|
_dmarc.example.com | TXT | v=DMARC1; p=none; rua=mailto:hoge@example.com |
設定が完了すると、受信サーバからDMARCレポートのメールが届きます。
なお、DMARCレポートを分析するツールを使う場合は、サービスの仕様にしたがって定義してください。たとえば、自社メールに送りつつValimailを使う場合は次のように定義します。
Host | Type | Value |
---|---|---|
_dmarc.example.com | TXT | v=DMARC1; p=none; rua=mailto:hoge@example.com,dmarc_agg@vali.email |
3.受信したレポートを解析してSPFやDKIMの設定に抜け漏れがないか確認する
RUAはxmlをzipまたはgz(gzip)で圧縮したファイルで届きます。以下は実際に受信したxmlです(私の個人ドメインで受信したもの)です。
<?xml version="1.0" encoding="UTF-8" ?>
<feedback>
<report_metadata>
<org_name>google.com</org_name>
<email>noreply-dmarc-support@google.com</email>
<extra_contact_info>https://support.google.com/a/answer/2466580</extra_contact_info>
<report_id>6026605514643003670</report_id>
<date_range>
<begin>1701907200</begin>
<end>1701993599</end>
</date_range>
</report_metadata>
<policy_published>
<domain>kikutaro.tech</domain>
<adkim>r</adkim>
<aspf>r</aspf>
<p>reject</p>
<sp>reject</sp>
<pct>100</pct>
<np>reject</np>
</policy_published>
<record>
<row>
<source_ip>168.245.67.245</source_ip>
<count>24</count>
<policy_evaluated>
<disposition>none</disposition>
<dkim>pass</dkim>
<spf>pass</spf>
</policy_evaluated>
</row>
<identifiers>
<header_from>kikutaro.tech</header_from>
</identifiers>
<auth_results>
<dkim>
<domain>kikutaro.tech</domain>
<result>pass</result>
<selector>s1</selector>
</dkim>
<dkim>
<domain>sendgrid.info</domain>
<result>pass</result>
<selector>smtpapi</selector>
</dkim>
<spf>
<domain>sendgrid.kikutaro.tech</domain>
<result>pass</result>
</spf>
</auth_results>
</record>
</feedback>
DMARCレポートの分析ツールを利用するとビジュアルに状況を把握できます。下図はValimailの例です。
ツールで状況を把握しながら、どんな送信が行われているのか?SPFやDKIMに抜け漏れはないのか?をチェックしていきます。
分析ツールはOSSでも様々なものがあります。私はValimailのほか、受信したRUAを分析するdmarc-report-converterを使いました。XMLを集約して表形式のHTMLに変換してくれるシンプルなツールです。以前ブログで使い方をまとめたので興味ある方はご参照ください。
このツールはDMARCレポートをそのまま分析してHTMLファイルに出力してくれます。
HTMLの表では何もできないので、これをGoogle Spreadsheetにコピペします。Spreadsheetにはquery句というのがあるため、たとえばSalesforceなどは次のようなクエリを書くことSQLライクにデータを抽出できます。
=query(HTMLからコピペしたシート!開始セル:終端セル,"select * where (DKIM検証結果のカラム!='pass' OR SPF検証結果のカラム!='pass') AND SPFのエンベロープFromのカラム LIKE '%salesforce%'")
たとえば上記のように、分析するとSalesforceでDKIMが設定されていないこと、エンベロープFromが自社ドメインではなくsalesforce.comドメインでpassしていることがわかります。
4.必要に応じて情シスや各部門と調整して抜け漏れに対応する
手順1~3によってどこから何通のメールが送られていて、SPF/DKIMの検証結果やアライメントがどうなっているか把握できるようになりました。
会社規模によってはここからが一番大変なのではないかと思います。3で確認した結果に基づいて、必要に応じて対応が必要です。例えば先ほどの3でSalesforceにDKIMがないことがわかりましたが、この対応を誰がするのか決める必要があります。Salesforceを全社的に導入していれば情報システム部門だけに相談すればよいかもしれません。一方、部門ごとにSalesforceを利用している(社内に複数のアカウントがある)場合には、ダッシュボードの設定は各部門が行い、DNSサーバへのレコード追加は情報システム部門が実施するというケースもあります。
こうした調整や対応をする上では今回のGmailガイドラインのことを知ってもらい、気を付けて欲しいことをわかりやすく伝える必要があります。 そして今後また新しくメールサービスが増えたときの対応を社内でルール化するなどの整備も必要です。この辺りは社内である程度影響力を持った方に協力してもらい進めてもらうのが大事だと思います。
SalesforceにおけるSPF/DKIMの設定
実際の例として先ほどのSalesforceをみてみましょう。DKIM検証がfailしていることからDKIMの設定がされていないことがわかります。SalesforceでDKIMを設定する方法は「DKIM 鍵の作成」のとおりです。
次にSPFです。先ほどの結果をみるとSPFはpassしているので一見問題はなさそうです。でもガイドラインには
Set up SPF and DKIM email authentication for your domain.
の記述に加えて次のような記述があります。
For direct mail, the domain in the sender's From: header must be aligned with either the SPF domain or the DKIM domain. This is required to pass DMARC alignment.
アライメントまで気にするのであれば、現在エンベロープFromがsalesforce.comでヘッダFromが自社ドメインで一致しないため対応が必要です。エンベロープFromを自社ドメインにするには
設定の「管理」->「メール」->「標準メールセキュリティのメカニズムへの準拠を有効化」のチェックを外して、SPFレコードを含める設定が必要です。
今回は一例としてSalesforceを挙げましたが、1つのサービスだけみてもSPF/DKIMの設定方法を調べたり、アライメントをどうするか決めて設定したり、その社内調整をしたり...と手間がかかります。
SPFにおけるinclude回数制限
SPFの設定を進めるとDNSルックアップの制限に引っかかる場合があります。前述のSalesforceの例は、includeを使ってSPFレコードを含める設定でした。
include:_spf.salesforce.com
SPFレコードを追加する際は、現在設定されているSPFレコードのinclude(DNSルックアップ)回数を気にする必要があります。なぜならincludeは最大10回までという制限があるためです。現在の回数を知りたい場合はEASYDMARCのSPF Record Checkerが便利です。下図のドメインの結果をみると7回になっています。
includeの回数はinclude先の定義も含まれます。具体的な例としてはGoogle WorkspaceのSPFをみてみましょう。ドキュメントには次のincludeをTXTレコードに追加するよう書かれています。
include:_spf.google.com
ここで_spf.google.comのTXTレコードを引いてみます。するとinclude先でさらに3つincludeされています。この場合は合計4回になります。
include:_netblocks.google.com include:_netblocks2.google.com include:_netblocks3.google.com
10回を超えないようにするためには、不要なSPFレコードを削除する、というのが一番楽な方法です。その他、フラット化(include先の値を参照元の値に移動させる)やマクロを使う方法があります。
おわりに
今回はDMARCレポートを使ってSPFやDKIMの抜け漏れをチェックして対応するまでの流れについて書きました。Gmailの新ガイドラインに対応するにはこれだけでは不十分で、配信停止リンクや迷惑メール報告率などへの対応も必要です。たかがメール、されどメール。まだまだメールはビジネスの上で重要です。届かないことがないようしっかり対策を進めていきましょう。
-
1日あたり 5,000 件以上のメール送信者 ↩︎
Discussion