DMARCとは？ わかりやすく10分で解説

「取引先からの請求書メールに見えた」「社内ドメインを名乗る不審メールが届いた」――メールの“なりすまし”は、ビジネスメール詐欺（BEC）やフィッシングの入口として今も定番です。DMARCは、SPF/DKIMという既存の認証結果に「このドメインのメールは、失敗したらこう扱ってほしい」という方針（ポリシー）とレポートを加え、受信側の判断を揃えるための仕組みです。この記事では、DMARCでできること／できないこと、仕組み、レコード例、導入手順と運用の落とし穴まで整理します。

DMARCとは

DMARCとはDomain-based Message Authentication, Reporting, and Conformanceの略で、送信ドメインのメール認証を強化するための仕組みです。SPFやDKIMの認証結果を受けて、受信側に対して「認証に失敗したメールをどう処理するか（隔離・拒否など）」をポリシーとして伝え、さらに認証状況を把握するためのレポート（報告）を受け取れるようにします。

DMARCの中核は、2つの技術であるSPF（Sender Policy Framework）とDKIM（DomainKeys Identified Mail）です。これらを使って「送信が正当か」「途中で改ざんされていないか」を検証し、その結果と送信者表示（From）との整合性をDMARCが評価します。

DMARCでは、DNSにDMARCレコードを公開し、認証に失敗したメールの扱い（例：受信はするが隔離する／受信自体を拒否する）を受信者に示します。これにより、なりすまし対策を受信側の実装に委ねるのではなく、送信ドメイン側の意思として明確に伝えられる点が特徴です。

DMARCが生まれた背景と必要性

DMARCが必要とされる理由は、ビジネスメール詐欺やフィッシング攻撃など、メールを悪用した攻撃が「送信者の表示（From）を偽装する」形で成立しやすいからです。SPFやDKIMだけでも認証はできますが、受信側が失敗メールをどう扱うかは一律ではありません。DMARCはこの差を埋め、「失敗したら隔離／拒否してほしい」というポリシーを明示することで、対策の実効性を上げます。

またDMARCは、レポートを通じて「自社ドメインがどこから送られているか」「どこで失敗しているか」を把握しやすくします。正規の送信サービス（メール配信、SaaS通知、CRMなど）が増えた環境では、可視化なしに強いポリシーへ移行すると正当なメールを落とす事故が起きがちです。DMARCは、段階導入を支えるための設計になっています。

DMARCがどのようにスパム防止に寄与するか

DMARCは「スパム全般を消し去る魔法」ではありませんが、自社ドメインのなりすましを減らすことで、結果として受信者側の迷惑メール・詐欺メールを減らすのに寄与します。受信側はDMARCポリシーに基づいて、認証に失敗したメールを隔離（Quarantine）したり拒否（Reject）したりできます。

さらに、DMARCレポートを通じて失敗理由（SPF不合格、DKIM不合格、Fromとの整合性不一致など）を把握できるため、送信ドメイン側は設定を改善できます。これにより、正規メールの到達性が安定し、運用トラブル（「届かない」「迷惑メールに入る」）の原因調査もしやすくなります。

DMARCの関連技術

DMARCを理解・運用するには、SPFとDKIMの役割の違いと、DMARC特有の「整合性（アライメント）」を押さえることが重要です。

SPF (Sender Policy Framework)

SPFは「このドメインからメールを送ってよい送信元（IPアドレスや送信サービス）をDNSで宣言する」仕組みです。受信側は、エンベロープFrom（Return-Path/MAIL FROM）に対してSPFレコードを引き、送信元IPが許可されているかを検証します。

注意点として、SPFは転送（フォワード）に弱い面があります。転送先では送信元IPが転送サーバのものになり、元のドメインのSPFに合致しないため失敗しやすくなります。この性質は、DMARC導入時の「正規メールが落ちる」原因になりやすいポイントです。

DKIM (DomainKeys Identified Mail)

DKIMは、送信側がメールに電子署名を付与し、受信側がDNS上の公開鍵で検証する仕組みです。署名により「送信ドメインが主張する内容で送られたこと」と「配送経路で改ざんされていないこと（署名対象の範囲内）」を確認できます。

DKIMは、転送があってもメール本文や署名対象ヘッダーが大きく改変されない限り、検証に成功しやすい傾向があります。ただし、メーリングリストの処理やゲートウェイの改変（フッター付与、件名書き換えなど）によって署名が壊れることもあります。

SPFとDKIMの関係性

SPFは主に「送信経路（どこから送られたか）」、DKIMは主に「内容の署名（何が送られたか）」を見ます。どちらも万能ではなく、片方だけに依存すると抜けが出ます。そこでDMARCは、SPFまたはDKIMのどちらか一方でも条件を満たせば合格とできる設計にしつつ、Fromとの整合性を加えて“なりすまし”対策の実効性を高めます。

DMARCが加える「整合性（アライメント）」

DMARCで重要なのは、SPFやDKIMが単に「成功したか」だけでなく、Fromヘッダーのドメインと整合しているかを評価する点です。例えばSPFが成功しても、エンベロープFromのドメインがFromと別物なら、DMARC的には不合格になる場合があります。

整合性には「緩和（relaxed）」と「厳格（strict）」の考え方があり、運用ではまず緩和（サブドメインを許容）で始め、必要に応じて厳格へ寄せていくのが一般的です。ここを理解していないと「SPF/DKIMは通っているのにDMARCが落ちる」状況に悩まされます。

DMARCの仕組み

DMARCは、(1)SPFとDKIMの評価、(2)Fromとの整合性評価、(3)ポリシーに基づく処理、(4)レポート送信、の流れで動きます。

DMARC認証のフロー

受信側は、受け取ったメールに対してSPFとDKIMを検証し、次にFromヘッダーのドメインに対するDMARCレコードをDNSで参照します。そして、SPFまたはDKIMのどちらかが合格し、かつFromとの整合性も満たす場合にDMARC合格となります。

DMARCに不合格の場合、受信側はDMARCレコードのポリシー（p=）に従って、通常配信、隔離、拒否といった処理を行います。ここで「受信側が必ず従う」と断言はできませんが、多くの主要メール基盤ではDMARCを評価し、判断材料として利用します。

DMARCポリシーの種類と特徴

DMARCのポリシーは主に3種類です。

• p=none：強制はせず、評価とレポート収集を行う（監視モード）
• p=quarantine：不合格メールを隔離（迷惑メール扱いなど）するよう促す
• p=reject：不合格メールを受信しない（拒否）するよう促す

現実的な導入は、まずp=noneで状況を把握し、問題のある送信元を潰し込み、段階的にquarantine→rejectへ移行する手順が安全です。最初からrejectにすると、正規サービスの設定漏れがそのまま配信障害になります。

DMARCレポート（報告）で何が分かるか

DMARCのレポートは、ドメインの所有者が「誰が自社ドメインを名乗って送っているか」を把握する助けになります。代表的なのは集計レポート（rua）で、送信元IP、SPF/DKIM/DMARCの合否、対象ドメインなどが集計されて届きます。

もう一つ失敗レポート（ruf）の指定もありますが、個別メッセージに近い情報を含み得るため、プライバシーや運用負荷の観点で受信側が送らない／制限するケースもあります。運用ではまずrua中心に考えるのが堅実です。

DMARCは「完全な保護」ではない

DMARCは強力ですが、これだけでフィッシングや詐欺がゼロになるわけではありません。攻撃者が「似た別ドメイン」を取得して送る、正規アカウントを乗っ取って送る、受信者を別チャネルへ誘導する、といった手口は残ります。DMARCは「自社ドメインのなりすましを減らす」軸で導入し、他の対策（アカウント保護、教育、URLフィルタ、ゲートウェイ対策）と組み合わせるのが前提です。

DMARCレコードの書き方

DMARCレコードはDNSにTXTとして公開します。基本の問い合わせ先は「_dmarc.example.com」のように、ドメイン直下の_dmarcサブドメインです。最小構成としては、バージョン（v）とポリシー（p）を設定します。

最小例（監視モード）

まずは次のような形で始めることが多いです。

v=DMARC1; p=none;

ただし、これだけだとレポートが来ません。運用目的が「可視化」なら、rua（集計レポート送付先）を設定するのが実務的です。

よく使う主なタグ

• rua：集計レポートの送付先（mailto:）
• ruf：失敗レポートの送付先（運用方針とプライバシー配慮が必要）
• adkim：DKIM整合性（r=緩和 / s=厳格）
• aspf：SPF整合性（r=緩和 / s=厳格）
• pct：ポリシー適用割合（段階移行に利用）
• sp：サブドメイン向けポリシー（必要に応じて）

例として、監視＋レポート収集を行い、整合性は緩和、という形なら次のようになります。

v=DMARC1; p=none; rua=mailto:dmarc-report@example.com; adkim=r; aspf=r;

レポート送付先を外部サービスにする場合は、DNS側で追加の許可設定が必要になることがあります（送付先ドメインの運用ルールに依存します）。このあたりは「レポートが来ない」原因として頻出です。

DMARCの導入手順

DMARCは「設定して終わり」ではなく、送信元の棚卸しと段階移行が成功の鍵になります。

1) 送信元の棚卸し（ここが最重要）

社内メールサーバだけでなく、SaaS通知、CRM/MAの配信、問い合わせフォーム、請求書送付サービスなど、「自社ドメインのFromを使う送信」がどこにあるかを洗い出します。ここが漏れると、後工程で正規メールが落ちます。

2) SPFとDKIMを整備する

DMARCはSPF/DKIMが土台です。SPFは送信元の許可を適切に反映し、DKIMは送信サービス側で署名が付与されるように設定します。送信サービスが複数ある場合は、SPFのincludeの乱立やDNS参照回数の上限など、設計面の注意が必要です。

3) p=noneで開始し、レポートで現状を掴む

最初はp=noneで運用し、ruaレポートを収集して「合格している正規送信」「失敗している正規送信」「怪しい送信（なりすまし）」を分類します。正規送信の失敗は、SPF/DKIM設定やFrom整合性の問題であることが多く、ここを潰していきます。

4) pctで段階的に強化する

いきなりrejectにするのではなく、quarantineへ移行し、pctで割合を上げていくと事故を減らせます。一定期間観測して問題が収束してからrejectへ進めるのが基本です。

5) 運用として継続監視する

新しい配信サービスの導入、システム更改、委託先変更などで送信元は変わります。DMARCは「変化がある前提」で、レポート監視と設定更新を運用に組み込むほど効果が安定します。

よくある落とし穴と対策

DMARC導入でつまずきやすいポイントを、原因と対策の形で整理します。

転送でSPFが失敗する

メール転送では送信元IPが変わるためSPFが失敗しやすくなります。DKIMが生きていればDMARC合格となる設計にできるため、DKIMを確実に整備することが重要です。転送や中継での改変が多い環境では、DKIM署名が壊れない運用設計（不要な改変を避ける、署名設計を見直す）も検討します。

「SPF/DKIMは成功しているのにDMARCが落ちる」

原因の多くはFrom整合性です。SPFで評価しているドメイン（エンベロープFrom）や、DKIMのd=ドメインが、Fromヘッダーのドメインと整合していないとDMARC不合格になります。配信サービスでFromを自社ドメインに見せたい場合、整合性を満たす設定（カスタムドメイン設定、DKIMの自社ドメイン署名など）が必要です。

サブドメインの扱いが曖昧

example.comでDMARCを設定しても、サブドメインの運用方針が曖昧だと抜けが出ます。必要に応じてspタグでサブドメイン向けポリシーを定め、どのサブドメインが送信に使われるかを整理します。

強いポリシーにしたら正規メールが届かなくなった

多くは棚卸し不足か、設定変更の影響範囲の見積もり不足です。p=noneでの観測期間を確保し、失敗している正規送信をゼロに近づけたうえで段階移行します。移行後も、レポートで想定外の失敗が増えていないかを継続監視します。

「ブラックリスト対策＝DMARC」で片付けてしまう

DMARCはなりすまし対策の中核ですが、送信IPの評判、コンテンツ品質、配信頻度、ユーザー苦情など、到達性に影響する要因は他にもあります。DMARCは「最低限の信頼の土台」として整備しつつ、配信設計全体（From運用、配信基盤、運用手順）で考えるのが現実的です。

まとめ

DMARCは、SPF/DKIMの認証結果に「From整合性」と「失敗時の扱い（ポリシー）」、そして「レポート」を加え、送信ドメインのなりすまし対策を実効的にする仕組みです。成功の鍵は、送信元の棚卸し、p=noneでの観測、段階的な強化、そして継続運用にあります。自社ドメインの信頼を守るための基盤として、無理のない手順で導入を進めることが重要です。