【DMARCレポートが届いたら？】メールの認証失敗を解決するハウツーガイド｜DAD UNION

最近、noreply-dmarc-support@google.com のような送信元から、件名に「Report domain: [あなたのドメイン] Submitter: google.com」と書かれたメールが届いていませんか？

本文は空白で、添付ファイル（ZIP形式のXMLファイル）が付いている――もしそうなら、それはDMARC（ディーマーク）レポートです。多くの人にとって見慣れないこのメールは、実はあなたのドメインから送られるメールの信頼性を高めるための、とても重要なヒントを教えてくれます。

このブログ記事のターゲット：

DMARCレポートが届き、内容がよくわからない方
ご自身のメールがスパム判定されるのを防ぎたい方
メールのセキュリティ設定に関心がある方

Contents

DMARCレポートとは？なぜ届くの？
- 添付ファイルの内容を読み解く
認証失敗の主な原因
- 1. SPF認証の失敗（<spf>fail</spf> または softfail）
- 2. DKIM認証の失敗（<dkim>fail</dkim>）
具体的な対処方法：メールの信頼性を取り戻そう！
まとめ

DMARCレポートとは？なぜ届くの？

DMARCレポートは、あなたのドメイン（例: yourcompany.com）から送信されたメールが、受信側のサーバーでどのように処理されたかを報告するものです。特に、SPFとDKIMという2つの重要なメール認証技術の結果について詳しく教えてくれます。

これが届くのは、あなたのドメインのDNS設定にDMARCレコードが存在し、レポートの送信先が設定されているからです。Googleなどの大手メールプロバイダは、DMARCレコードがあるドメインからのメールについて、定期的にこのレポートを送ってくれます。

添付ファイルの内容を読み解く

添付されているXMLファイルは、少し複雑に見えますが、重要な情報が含まれています。例えば、以下のような項目があります。

<org_name>google.com</org_name>: レポートを送ってきた組織（この場合はGoogle）
<report_id>...</report_id>: このレポートの識別子
<date_range>...</date_range>: このレポートが対象としている期間
<policy_published>: あなたのドメインのDMARCポリシー設定（現在の設定）
<record>: 個々のメールに関する認証結果の詳細

特に注目すべきは、<record>内の認証結果です。ここに「fail（失敗）」や「softfail（ソフトフェイル）」と記載されている場合、あなたのドメインから送られたメールに問題があることを示しています。


<policy_evaluated>

  <disposition>none</disposition>

  <dkim>fail</dkim>

  <spf>fail</spf>

</policy_evaluated>

このような表記がある場合、あなたのメールは受信者からスパムと判断されたり、最悪の場合届かなくなったりする可能性があります。

認証失敗の主な原因

DMARCレポートで「fail」や「softfail」が出た場合、主に以下の2つの認証に問題があることが多いです。

1. SPF認証の失敗（`<spf>fail</spf>` または `softfail`）

SPF（Sender Policy Framework）は、「このドメインのメールは、このIPアドレスからしか送りませんよ」という情報をDNSに公開する仕組みです。これによって、なりすましメールを防ぎます。

SPF認証が失敗する主な原因は、メールを送信しているサーバーのIPアドレスが、あなたのドメインのSPFレコードに含まれていないことです。例えば、自社サーバーから送っていたり、GmailやOutlookなどのプロバイダ以外に、営業メール配信サービスや顧客管理システムからもメールを送っている場合、それらすべてをSPFレコードに登録する必要があります。

2. DKIM認証の失敗（`<dkim>fail</dkim>`）

DKIM（DomainKeys Identified Mail）は、メールに電子署名をつけて、そのメールが途中で改ざんされていないこと、そして正規の送信元から送られたことを証明する仕組みです。

DKIM認証が失敗する主な原因は、メール送信サーバーでDKIM署名が正しく設定されていない、あるいはDNSにDKIMの公開鍵が正しく登録されていないことです。場合によっては、メールが転送されたり、内容がわずかに変更されたりしただけでも署名が無効になることがあります。

具体的な対処方法：メールの信頼性を取り戻そう！

DMARCレポートが示唆する問題を解決し、メールの信頼性を高めるための具体的なステップをご紹介します。

Step 1: SPFレコードの確認と修正

あなたのドメインのDNS管理画面にログインします。
これは、あなたがドメインを購入したサービス（お名前.com、Xserver、Google Domainsなど）や、レンタルサーバーの管理画面にあります。
DNSレコードの中から、TXTレコードを探します。
特に、「v=spf1 include:... ~all」のような記述があるものがSPFレコードです。
メールを送信しているすべてのサービスのIPアドレスやドメインがSPFレコードに含まれているか確認します。
もし、あなたがGmail for BusinessやMicrosoft 365を使っているなら、それぞれのサービスのヘルプページで推奨されるSPFレコードの記述を確認し、追加・修正してください。例えば、Google Workspaceの場合は「include:_spf.google.com」を含める必要があります。

例: v=spf1 include:_spf.google.com include:spf.sendgrid.net ~all
- include:の後に、利用しているメールサービスや配信サービスが指定するドメインを追加します。
- 末尾の「~all」は「推奨されない送信元からのメールはSoftFail」という意味です。厳格にしたい場合は「-all」に変えることもできますが、まずは「~all」で様子見が安全です。
SPFレコードチェッカーなどのツールで正しく設定されているか確認します。
「SPF record checker」と検索すると、無料で利用できるツールが見つかります。

Step 2: DKIM署名の確認と修正

メール送信に利用しているシステム（メールサーバー、メール配信サービス、CMSのメール機能など）の設定を確認します。
それぞれのサービスでDKIM署名を有効にするための設定項目があるはずです。
DKIMの公開鍵（パブリックキー）をDNSに登録します。
多くの場合、メールサービスや配信サービスが提供する「DKIM設定」の項目に、DNSに追加すべきTXTレコードの情報（ホスト名と値）が記載されています。これをDNS管理画面にコピー＆ペーストして追加します。
```
例: ホスト名: google._domainkey.yourdomain.com

値: v=DKIM1; p=MIGfMA0G...
```
DKIMレコードチェッカーなどのツールで正しく設定されているか確認します。

Step 3: DMARCポリシーの見直し（重要かつ慎重に！）

DMARCレポートのXMLファイルにある <p>none</p> は、現在のあなたのドメインのDMARCポリシーが「none（何もしない）」であることを示しています。つまり、認証に失敗したメールが検出されても、受信側は特にブロックしたり隔離したりしない、という設定です。

この段階では、レポートを受け取って状況を把握するだけなので、正当なメールが届かなくなるリスクはありません。

SPFとDKIMの設定が改善され、DMARCレポートで「fail」や「softfail」の数が減ってきたら、将来的にDMARCポリシーをより厳しくすることを検討できます。

p=quarantine (隔離): 認証に失敗したメールを迷惑メールフォルダに振り分けるよう、受信側に推奨します。
p=reject (拒否): 認証に失敗したメールを完全に拒否するよう、受信側に推奨します。

注意！ p=quarantine や p=reject に変更する際は、SPFとDKIMの設定が完璧であることを十分に確認してください。誤った設定のまま厳しくすると、正当なメールが受信者に届かなくなるという重大な問題が発生する可能性があります。段階的に変更し、DMARCレポートを継続的に監視しながら進めましょう。