メールが「届かない」を解決する常識。DMARCレポートを生成AIで読み解くヒント

生成AI

山田義智

2026年04月13日

リンクをコピーしました

はじめに

皆さん、こんにちは。株式会社メンバーズデブオプスリードカンパニーの山田です。

皆さんは「DMARC（ディーマーク）」という言葉を耳にしたことはありますか。

恥ずかしながら、私は業務で直接触れるまで、名前すら聞いたことがない状態でした。
しかし、調査を進めるうちに、DMARCは単なるセキュリティ設定ではなく、「メールを確実に届けるための必須条件」であることを知りました。

私自身、初心者として調べながら進めてきたため、本記事の内容がすべての環境にそのまま合致するわけではありません。

本記事では、作業を少しでも楽にするために私が実践した、生成AIにDMARCレポート解析を手伝ってもらう方法を紹介します。「一つの実践例」として、皆さんの環境に合わせた設定を考える際の参考にしていただければ幸いです。

DMARCとは？

DMARC（Domain-based Message Authentication, Reporting, and Conformance）は、SPFとDKIMをベースにした「送信ドメイン認証」の仕組みです。

最大の特徴は、DMARC自体が新しい認証を行うのではなく、「SPF/DKIMの結果をどう評価し、どう処理するか」というポリシー（方針）をドメイン所有者が宣言する点です。

DNSにDMARCレコード（TXTレコード）を公開することで、以下の3つの役割を果たします。

1.認証の整合性確認（アライメント）

SPFやDKIMが「技術的に成功しているか」だけでなく、実務的な整合性をチェックします。

役割: 「差出人（Fromヘッダー）のドメイン」と「SPF/DKIM認証に使ったドメイン」が一致しているかを確認します。
メリット: SPF単体では防げない「差出人名の偽装」を検知し、なりすましメールをより厳格に排除できます。

2.ポリシーの適用指示

認証に失敗したメールを、受信側でどう扱うかをドメイン所有者側から指示します。

none（監視）: 何もせずそのまま通す。導入初期の現状把握に適しています。
quarantine（隔離）: 迷惑メールフォルダへ振り分ける。
reject（拒否）: 受信そのものを拒否する。最も強力な保護状態です。

3.可視化（レポート機能）

世界中の受信サーバーから、自社ドメインを名乗るメールの統計情報を受け取れます。

役割: 「どこから、何通送られ、認証に成功したか」という集計レポート（RUA）を取得します。
メリット: 第三者による悪質ななりすましメールや、自社内での設定漏れ（新しいSaaSの導入など）を正確に把握できます。

これらを、DNSのDMARCレコードで表明します。DMARCが未設定、あるいは設定不備があると、正当なビジネスメールでも迷惑メール扱いになったり、最悪の場合は受信拒否されるリスクがあります。

2024年以降なぜ必須に？DMARCが必要な背景

背景にあるのは、なりすまし手法の高度化と、それに対する主要メール事業者の姿勢の変化です。

SPFやDKIMだけでは防げない「なりすまし」

これまで普及してきたSPFやDKIMは、あくまで「送信サーバー」や「電子署名」が正当であることを証明するものでした。しかし、「メールの差出人名（ヘッダーFrom）」を偽装する巧妙な攻撃を防ぎきれない課題がありました。この「認証の隙間」を埋めるのがDMARCです。

2024年、メール運用のルールが激変

2023年10月、GoogleはGmailのスパム対策強化を発表しました。2024年2月以降、特定の送信者に対してSPF/DKIMに加えてDMARC対応を強く求める方針を発表し、1日5,000通以上のメールを送る送信者への義務化が始まり、 Microsoftなどの他事業者も同様の基準を適用し、業界全体の標準となりました。
現在は、1日5,000通未満の送信者に対しても、SPF/DKIMの設定や、迷惑メール率の維持が厳格に求められています。

「やっておくと良い」から「必須」へ

この規制強化の結果、DMARCが未設定のドメインから送られたメールは、たとえ正当なビジネスメールであっても「受信を拒否される」「迷惑メールフォルダに振り分けられる」事態が実際に起こっています。

現在、DMARC対応はセキュリティ向上のためのオプションではなく、「メールを相手に届けるためのインフラとしての必須条件」に変わりました。

DMARC準拠に必要な「3つの要素」

DMARCを設定したつもりでも、準拠（Pass）しないケースは多いです。
まず、DMARCが正しく機能するために必要な要素を整理します。

1.SPF（Sender Policy Framework）

SPFは、送信元IPが「許可されたサーバーか」を検査する仕組みです。
DNSにSPFレコードを置き、受信側は受信時に参照して判断します。

Passとなる具体例：

DNSの設定値（TXTレコード）: v=spf1 ip4:192.0.2.1 ~all
実際の送信元IP: 192.0.2.1
判定: 受信サーバーが送信元IPをチェックし、「リストにある正規のサーバーだ」と判断し、SPF Passとなります。
（注：SPFは、エンベロープFrom（Return-Path）のドメインに基づき認証されます）

2.DKIM（DomainKeys Identified Mail）

DKIMは、メールに電子署名を付与し、改ざんやなりすましを検知する仕組みです。
公開鍵はDNSに置かれ、受信側が検証します。

Passとなる具体例：

DNSの設定値（CNAME/TXT）: 署名を検証するための「鍵」を公開しておく。
届いたメールのヘッダー: DKIM-Signature: v=1; d=example.jp; s=s1; ...（電子署名が付いている）
判定: 受信側がDNSの鍵を使って署名を計算し、一致すればDKIM Passとなります。

3.DMARC Alignment（アライメント）

DMARCの落とし穴になりやすいのが部分です。
SPF/DKIMがPassしていても、アライメントが崩れるとDMARCはFailになります。
From（ヘッダー上の送信者ドメイン）と、SPF/DKIMで認証したドメインが一致していることが重要です。

Passとなる具体例（SPFアライメント）：

ヘッダーFrom（差出人）: info@example.jp
Return-Path（配送用住所）: bounces@example.jp（または bounces@mail.example.jp などのサブドメイン）
判定: 「名乗っているドメイン」と「SPF認証したドメイン」が一致しているため、DMARC Passとなります。

Passとなる具体例（DKIMアライメント）：

ヘッダーFrom（差出人）: info@example.jp
DKIM署名のドメイン（d=）: d=example.jp
判定: 「ヘッダーFromで名乗っているドメイン」と「DKIM署名のd=タグに記載されたドメイン」が一致しているため、DMARC Passとなります。

DMARCがFailとなる3大エラーと具体的な対策

SPFやDKIMの認証結果が「Pass」であっても、DMARCが「Fail」判定されるケースは非常に多いです。
その多くは、ドメインが一致していない「アライメントエラー」が原因です。遭遇頻度が高い順に、具体的な事例を整理します。

1.外部SaaS利用時の「DKIMアライメント不一致」

SendGridやAWS SES、Salesforceなどの外部サービスを利用し、初期設定のまま送信した場合に発生します。

状況： 認証自体はSaaS側のドメイン（共通鍵）で行われるため成功しますが、メールの差出人（From）が自社ドメインであるため、不一致と見なされます。
具体例（NG例）：
- ヘッダーFrom（差出人）： info@example.jp
- DKIM署名ドメイン（d=）： sendgrid.net （SaaS側のドメイン）
- DMARC判定： example.jp ≠ sendgrid.net なので Fail

対策： 各サービスの管理画面で「独自ドメイン署名（Custom DKIM）」を設定し、署名ドメインを自社の example.jp に変更します。

2.Return-Pathの不一致によるSPFアライメントの失敗

SPFの認証対象である「裏側の住所（Return-Path）」が、差出人のドメインと異なる場合に発生します。

状況： 配信サービスがエラー通知を受け取るために、デフォルトではサービス側のドメインをReturn-Pathに使用します。
具体例（NG例）：
- ヘッダーFrom： info@example.jp
- Return-Path（エンベロープFrom）： bounces@u123.sendgrid.net
- DMARC判定： SPF認証自体はPassしますが、ドメインが不一致のため、DMARC Passには寄与しません。
- 対策： SaaS側で「MAIL FROMドメイン」の設定を行い、Return-Pathを自社ドメインのサブドメイン（例：bounces@em123.example.jp）に変更します。

3.SPFの「DNSルックアップ10回制限」によるエラー

SPFレコード内の include が多すぎることで発生する、技術的な制限による失敗です。

状況： DNSを参照する回数が合計10回を超えると、受信側は評価を中断し「permerror」となります。
NGレコードの例： v=spf1 include:_spf.google.com include:sendgrid.net include:salesforce.com include:hubspot.com ... ~all （一見少なく見えても、include 先がさらに複数のドメインを参照していると、合計10回を容易に超えてしまいます）
対策： 不要な設定を削除するか、ドメイン名の代わりにIPアドレスを直接記述する（Flattening）対応を検討してください。

実運用でよくある3つの発生シナリオ

多くのエンジニアが公開しているトラブルシュートの記録を読み解いていく中で、共通する典型的な失敗パターンが見えてきました。
DMARCに取り組む方が同じ場所で躓かないよう、特に注意すべき3つのシチュエーションを紹介します。

1. 新しい配信ツールの「部分的な導入」

配信プラットフォームやMAツールなどを新しく導入した際、「SPFの設定（includeの追加）だけで満足してしまう」ケースが多いです。

起こりやすい状況：マニュアルに従ってDNSにSPFレコードを追加し、テスト送信で spf=pass を確認して安心してしまう状況。
判定のイメージ：
- Fromドメイン（表示上の差出人）：example.jp
- Return-Path（メールの返送先）：bounces@provider.net（プロバイダ側のドメイン）
- 結果：ドメインが一致（アライメント成功）していないため、DMARCは Fail となります。

対策：新しいツールを導入する際は、SPFの追加だけでなく、管理画面に「独自ドメイン署名（Custom DKIM）」や「Sender Authentication」といった、ドメインを自社名義に統一する設定項目がないか必ず確認してください。（※名称はサービスによって異なりますが、「独自ドメイン」や「認証」に関する項目に隠れていることが多いです）

2.システム拡張に伴う「DNS更新の漏れ」

部署ごとに異なる配信サーバーを使っていたり、新しくサブドメインの運用を開始する際に発生するシナリオです。

起こりやすい状況：メインドメイン（example.jp）の設定が完了している安心感から、新設したサブドメイン（news.example.jp）でのSPF/DKIM設定を失念してしまう状況。
判定のイメージ：
- Fromドメイン（差出人）：news.example.jp
- 親ドメインのポリシー：p=reject（「認証失敗は拒否」がサブドメインにも継承される）
- サブドメインの状態：SPF/DKIMが未設定
- 結果：親ドメインの厳しいルールが適用され、メールがすべて受信拒否（Reject）されます。
対策：送信元を増やす際は、それがサブドメインであっても「別ドメイン」として扱い、個別にSPF/DKIM設定を完了させてください。 設定後は、後述する「DMARCレポート」を活用し、予期せぬサブドメインからFailが出ていないかを継続的に監視することが重要です。

メーリングリストや転送サービスの影響

自社側の設定に不備がなくても、受信側が行う「自動転送」によって認証の整合性が崩れてしまう、DMARC運用において避けて通れないシナリオです。

起こりやすい状況：宛先のアドレスが別のメールアドレスへ転送される設定（Gmailへの転送など）になっている場合や、メーリングリストを経由して配信される状況。
判定のイメージ：
- 配送ルート：自社サーバ ➔ 転送サーバ（中継） ➔ 最終受信者
- SPF判定：Fail（転送サーバのIPアドレスは、自社のSPF許可リストにないため）
- DKIM判定：Pass（転送時に本文が改ざんされなければ、署名は有効なまま維持される）
- DMARC結果：Pass（SPFがダメでも、DKIMが生き残っていればDMARCは成功する）
対策（教訓）：転送によってSPFが機能しない状況を補完できるのは「DKIMのアライメント」です。「SPFさえ通ればいい」という考えは転送環境で通用しません。転送先までメールを届けるためには、SPFだけに頼らず、自社ドメインによるDKIM署名を確実に実装しておくことが、運用の安定に繋がります。

DMARCレポート（XML）を生成AIで読み解いてみる

DMARCを導入すると、受信サーバーからXML形式のレポート（集計レポート）が届くようになります。

私自身、メール技術やDNSについて知識が浅く、最初は「どこを見れば原因が分かるのか」が掴めませんでした。

そこで試したのが、DMARCレポートを生成AIに解析させる方法です。

<aside> 🔐

実際のレポートをAIに渡す場合は、

外部公開や学習に使われない設定か
ドメイン名やIPをマスクするか
社内ルール上問題ないか

を必ず確認してください。
</aside>

AI活用のメリット

複雑なXML構造を短時間で要約できる
「どのIPが、何に失敗しているか」を自然言語にできる
対応方針（SPF整理、DKIM独自署名など）の候補を出しやすい

検証用：サンプルXMLレポート

サンプルを用意します（架空の失敗例）。

<?xml version="1.0" encoding="UTF-8" ?>
<feedback>
  <report_metadata>
    <org_name>Example Receiver</org_name>
    <email>noreply-dmarc-support@example.com</email>
    <report_id>1234567890</report_id>
    <date_range>
      <begin>1711152000</begin>
      <end>1711238399</end>
    </date_range>
  </report_metadata>
  <policy_published>
    <domain>your-company.jp</domain>
    <adkim>r</adkim>
    <aspf>r</aspf>
    <p>none</p>
    <sp>none</sp>
    <pct>100</pct>
  </policy_published>
  <record>
    <row>
      <source_ip>192.0.2.1</source_ip>
      <count>5</count>
      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>fail</dkim>
        <spf>fail</spf>
      </policy_evaluated>
    </row>
    <identifiers>
      <header_from>your-company.jp</header_from>
    </identifiers>
    <auth_results>
      <dkim>
        <domain>unknown-sender.net</domain>
        <result>fail</result>
        <selector>default1</selector>
      </dkim>
      <spf>
        <domain>your-company.jp</domain>
        <result>softfail</result>
      </spf>
    </auth_results>
  </record>
</feedback>

AIに解析させるためのプロンプト例

あなたはメールセキュリティのスペシャリストです。以下のDMARCレポート（XML）を解析してください。

1.このレポートで「認証に失敗している」送信元IPはどれですか？
2.SPF、DKIM、DMARCのそれぞれの結果を要約してください。
3.なぜ失敗しているのか、考えられる原因と対策を初心者にもわかるように解説してください。

[ここにXMLを貼り付け]

生成AIは、例えば次のように「どこが失敗で、何を疑うべきか」を整理して返してくれます。