DMARCとは？仕組み・設定方法・BIMIまでわかりやすく解説【2026年最新】

メール配信の現場で「DMARC」という言葉を目にする機会が増えています。SPFやDKIMと並べて語られることが多いものの、この3つがどう違い、DMARCが実際に何をしているのかは、名前だけでは掴みにくい技術です。

DMARC（ディーマーク）とは、SPFとDKIMの認証結果をもとに、認証に失敗したメールをどう扱うかを送信側があらかじめ指定できる送信ドメイン認証技術です。「自社をかたるなりすましメールは受け取らないでほしい」という方針を、送信側から受信側に伝えられます。

この記事では、DMARCの定義と仕組みを軸に、レコードの書き方、設定・確認方法、レポートの活用、導入時の注意点までを、図とあわせて解説します。

DMARC（ディーマーク）とは

DMARCの正式名称は「Domain-based Message Authentication, Reporting, and Conformance」です。SPFやDKIMによる認証に失敗したメールの扱いを送信側が指定でき、あわせて認証結果のレポートを受け取れる点が、他の送信ドメイン認証技術との違いになります。

DMARCは単体で動作する技術ではなく、先行する2つの認証技術「SPF」と「DKIM」の認証結果を利用して機能します。そのため、SPFまたはDKIMの設定が前提になります。

SPF・DKIMとの違い

SPFとDKIMは、いずれも「そのメールが正規の送信元から送られたものか」を検証する技術です。

SPF（Sender Policy Framework）は、「このドメインのメールはこのサーバーから送信する」という情報をDNSに公開し、受信側が送信元IPアドレスの正当性を検証する仕組みです。DKIM（DomainKeys Identified Mail）は、メールに電子署名を付与し、送信ドメインの正当性とメール内容が改ざんされていないことを検証します。

3つの技術の違いは次の通りです。

SPF・DKIMそれぞれの仕組みや設定方法は、以下の記事で詳しく解説しています。

SPF・DKIMだけでは防げないなりすまし

SPFとDKIMには、共通する2つの弱点があります。

1つ目は、受信者に見える差出人（ヘッダーFrom）を直接は検証していない点です。SPFが検証するのは配送に使われるエンベロープFrom、DKIMが検証するのは署名に使われたドメインであり、いずれもメールソフトに表示される差出人そのものではありません。

2つ目は、認証に失敗したメールの扱いが受信側任せになる点です。受信するか迷惑メールに入れるかは受信サーバーの設定に委ねられ、送信側は関与できません。

そのため、攻撃者が自前のドメインでSPF・DKIM認証を通しながら、表示される差出人だけを有名企業に偽装する手口が成立します。この穴を塞ぐのがDMARCです。

DMARCでできること

DMARCが提供する機能は、大きく2つです。

1つ目は、認証に失敗したメールの扱い（ポリシー）を送信側が指定できることです。「なりすましの疑いがあるメールは、迷惑メールに入れてほしい」「受信を拒否してほしい」といった方針をDNS上で宣言し、受信側はそれに従って処理します。

2つ目は、認証結果のレポートを受け取れることです。DMARCの「R（Reporting）」にあたる部分で、自社ドメインがどこからどれだけ送信され、認証に合格・失敗しているかを、ドメイン所有者がデータで把握できます。

DMARCの仕組み

DMARC認証の全体の流れ

DMARCは、送信側が事前に方針を宣言し、受信側がそれを参照して実行する、という役割分担で動作します。

送信側は、認証に失敗したメールの扱いを「DMARCレコード」としてDNSに登録します。受信側はメールを受け取るたびにこのレコードを参照し、認証結果とアライメントを判定したうえで、合格したメールは受信トレイへ、不合格のメールは指定されたポリシーに従って処理します。

アライメントとは何か？

DMARCの判定で鍵になるのが「アライメント」です。アライメント（Alignment）とは、認証で使われたドメインと、受信者に表示される差出人（ヘッダーFrom）のドメインが一致しているかを確認することを指します。

SPFとDKIMでは、ヘッダーFromと照合する相手が次のように異なります。

この確認が必要なのは、認証だけでは差出人の偽装を防げないためです。攻撃者が自分の所有するドメイン（例：attacker.com）で正しくSPF・DKIMを設定すれば、認証そのものはpassします。しかし、受信者に表示される差出人を有名企業（例：example.com）に偽装されると、認証に使ったドメインと受信者が目にする差出人がバラバラのまま、認証だけが通ってしまいます。

DMARCはヘッダーFromとの一致まで確認するため、この手口を検出できます。

なお、一致の判定には、ドメインの完全一致を求める「strict（厳格）モード」と、サブドメインの違いを許容する「relaxed（緩和）モード」があり、既定はrelaxedモードです。relaxedであれば、mail.example.com と example.com のような親子関係のドメインも一致とみなされます。

DMARCが「合格」になる条件

DMARCが合格（pass）と判定されるのは、次の2つの条件のうちいずれか一方を満たしたときです。両方を満たす必要はありません。

SPFとDKIMのどちらか片方でも「認証のpass」と「アライメントの一致」の両方を満たせば合格です。「SPFとDKIMの両方がpassしないと合格しない」と誤解されがちですが、そうではありません。逆に、認証がpassしていてもアライメントが一致しなければ、その条件は満たされません。

メール配信システム利用時に注意が必要な理由（第三者署名の問題）

外部の配信サービスからメールを送る場合、初期設定のままだと、受信者に表示される差出人は自社ドメインなのに、認証に使われるドメインは配信サービスのものになることがあります。

DKIMでは、ヘッダーFromと異なるドメインで署名する方式を「第三者署名」、ヘッダーFromと同じドメインで署名する方式を「作成者署名」と呼びます。配信サービスが自社のドメインで署名すると第三者署名となり、DKIMアライメントは一致しません。

SPFも同様です。配信サービス経由では、エンベロープFrom（Return-Path）が配信サービスのドメインに書き換えられることが多く、その場合はSPFアライメントも一致しません。

両方のアライメントが一致しなければ、SPF・DKIMの認証自体は成功していても、DMARCは不合格になります。

解決策はシンプルで、配信サービス側で自社ドメインを使ったDKIM署名（作成者署名）を設定すればよいだけです。DKIM署名のドメインが自社ドメインになれば、ヘッダーFromと一致してDKIMアライメントを満たせます。

DMARCが必要とされる理由

なりすまし・フィッシング被害の現状

電子メールの仕様上、メールソフトに表示される差出人は送信者が自由に設定できます。そのため悪意のある第三者は、実在する企業のドメインを名乗り、その企業からのメールであるかのように偽装できます。

こうしたなりすましメールは、フィッシング詐欺やビジネスメール詐欺（BEC）の温床となっています。フィッシング対策協議会の月次報告によると、2026年1月のフィッシング報告件数は202,350件に達しました。

被害を受けるのは受信者だけではありません。ドメインをかたられた企業も「あの会社のメールは危ない」と受け取られ、信用を損ないます。

Gmail・Yahoo!メールのガイドラインで実質必須に

DMARCを取り巻く環境は、2024年を境に大きく変わりました。Googleが送信者ガイドラインを改定し、Gmailアカウント宛てに1日5,000件以上のメールを送信する送信者に対して、SPF・DKIM・DMARCの3つすべての設定を義務化したのです。Yahoo!メールも同様の要件を導入しており、対応しない場合はメールが迷惑メール判定されたり、受信を拒否されたりするリスクがあります。

日本国内でも、政府がクレジットカード会社等に対してDMARC導入によるフィッシング対策強化を要請するなど、行政レベルで導入が推進されています。

要件の詳細はGoogle公式の「メール送信者のガイドライン」で公開されていますまたガイドラインの詳細な要件と対応方法は、以下の記事でも詳しく解説しています。

DMARC導入で得られること

ポリシーを隔離（quarantine）や拒否（reject）まで引き上げると、自社ドメインをかたるなりすましメールが受信者に届く前に排除されます。顧客がフィッシング詐欺に遭うリスクを減らし、「ドメインを悪用された企業」としての信用低下も防げます。

メールの到達率にも関わります。GmailやYahoo!メールでは送信ドメイン認証の設定状況が迷惑メール判定に影響するため、DMARCを正しく設定した送信ドメインは信頼できる送信者と評価されやすくなります。

さらに、DMARCレポートによって自社ドメインからのメール送信の全体像をデータで把握できます。なりすましの検知だけでなく、把握していなかった部署が別のツールからメールを送っていたといった社内のシャドーITの発見や、認証設定の不備の洗い出しにも役立ちます。

業界標準として策定された技術

DMARCの仕様は、2012年にGoogle・Microsoft・Yahoo!・PayPalなどの大手メール事業者・企業の連合によって策定・公開されました。2015年にはRFC 7489として文書化されています（IETFの正式な標準ではなく、Informational＝情報提供扱いの文書）。

その後2026年5月、IETF（インターネット技術の標準化団体）から後継仕様となるRFC 9989（中核プロトコル）・RFC 9990（集計レポート）・RFC 9991（失敗レポート）の3文書が公開され、RFC 7489は廃止されました。これによりDMARCは、初めてIETFの標準化過程（Proposed Standard）に位置づけられた技術になっています。

レコードのバージョン表記はv=DMARC1のまま変わらず、既存の設定がそのまま無効になることはありません。大手メールプロバイダが主導して作られ、その後IETFの標準となった経緯からも、DMARCは一部のベンダーの独自技術ではなく、メールインフラ全体の標準として設計された技術だと分かります。

DMARCポリシーの3つの種類

DMARCポリシー（pタグで指定する値）には、以下の3種類があります。none→quarantine→rejectの順に制御が強くなります。

noneでもDMARC対応として成立します。Gmailの送信者ガイドラインが大量送信者に求めるDMARC設定も、最低要件はp=noneです。まずはnoneで導入してレポートを収集し、正規メールが確実に認証を通ることを確認してから段階的に強化するのが推奨されます。

DMARCレコードの書き方

DMARCレコードの基本構文

DMARCの設定内容は、「_dmarc.ドメイン名」というホスト名のTXTレコードとしてDNSに公開します。DNSに新しい仕組みを追加する必要はなく、一般的なテキストレコードをそのまま利用します。

ドメインが「example.com」の場合、最小構成のDMARCレコードは次のようになります。

_dmarc.example.com IN TXT “v=DMARC1; p=none; rua=mailto:dmarc-report@example.com”

この例は「DMARCバージョン1を使用し、認証失敗メールは通常どおり受信させ、集計レポートをdmarc-report@example.com宛てに送ってほしい」という宣言を意味します。

主なタグの意味と設定値

DMARCレコードで使用できる主なタグは以下の通りです。必須なのはvタグとpタグの2つで、それ以外は任意です。

spタグを指定しない場合、サブドメインには親ドメインのポリシーがそのまま適用されます。存在しないサブドメインを狙ったなりすましを防ぐには、np=rejectの指定が有効です。

なお、以前は適用割合を指定するpctタグが使われていましたが、受信側での解釈が統一されなかったため、2026年5月のRFC 9989で廃止されました（あわせてrf・riも廃止）。すでに設定している場合も直ちに問題は起きませんが、段階的な導入にはt=yによるテストモードの利用が推奨されます。

DMARCの設定方法

DMARCの設定は、大きく4つのステップで進めます。

手順1：SPFとDKIMを設定する

DMARCはSPF・DKIMの認証結果を利用するため、少なくともどちらか一方（推奨は両方）が正しく設定されていることが前提です。未設定の場合は、先にSPFレコードの登録とDKIM署名の設定を行います。

あわせて、自社ドメインからメールを送信しているシステムの洗い出しも行います。メールサーバーだけでなく、メール配信システム・CRM・問い合わせフォームなど、送信経路をすべて把握しておかないと、後のフェーズで正規メールが認証に失敗する原因になります。

DKIMの具体的な設定手順は、以下の記事を参考にしてください。

手順2：レポート受信用のメールアドレスを用意する

DMARCレポートの送付先となるメールアドレスを用意します。レポートは受信サーバーごとに送られてくるため、日常業務用のアドレスとは分けて、専用のメールボックスを作成するのがおすすめです。

手順3：DNSにDMARCレコードを登録する

利用しているDNSサービスの管理画面から、TXTレコードとしてDMARCレコードを登録します。ホスト名は「_dmarc.自社ドメイン」、値は前述の構文に従って記述します。初回は必ずp=noneから始めます。

手順4：動作確認を行う

設定後は、次の2点を確認します。

1つ目はレコードの公開確認です。コマンドラインでnslookup -type=txt _dmarc.example.comを実行し、登録した内容が返ってくるかを確認します。

2つ目は認証結果の確認です。GmailやOutlookなどDMARC対応プロバイダのアドレスに自社からテストメールを送り、メールヘッダー（メッセージのソース）を開いて「Authentication-Results」欄を確認します。

Authentication-Results欄のspf=、dkim=、dmarc=の値がすべてpassになっていれば、正常に認証されています。

DMARCレポートの見方と活用方法

DMARCレポートには2種類あり、性質が大きく異なります。

集計レポート（RUA）

集計レポート（Aggregate Report）は、受信サーバーが観測した認証結果の統計情報を、通常1日1回程度の頻度でまとめて送付してくれるレポートです。ruaタグで指定したアドレスにXML形式で届きます。

送信元IPアドレスごとのメール件数、SPF・DKIMの認証結果、適用されたポリシーなどが含まれており、「把握していない送信元から自社ドメインのメールが出ていないか」「正規の送信経路が認証に失敗していないか」を分析できます。

XMLをそのまま読むのは大変なため、実務ではDMARCレポートの可視化ツールや分析サービスを利用するのが一般的です。

失敗レポート（RUF）

失敗レポート（Failure Report／Forensic Report）は、認証に失敗した個々のメールについて、その詳細情報を送付してくれるレポートです。rufタグで指定します。

ただし、失敗レポートにはメール本文などの情報が含まれ得るため、プライバシー保護の観点から送付に対応していない受信プロバイダが多いのが実情です。運用の主軸は集計レポート（RUA）になります。

ポリシーを段階的に強化する進め方

DMARCポリシーは、いきなりrejectに設定するのではなく、段階的に強化することが推奨されています。急にrejectへ変更すると、設定漏れのある正規メールまで拒否されてしまうリスクがあるためです。

各フェーズでDMARCレポートを確認し、正規メールがすべて認証に合格していることを確かめてから次のフェーズへ進みます。ポリシーを強める前に影響を見たい場合は、t=yを指定してテストモードで運用する方法もあります。

DMARC導入時の注意点と限界

設定を誤ると正規のメールが届かなくなる

最大のリスクは、正規のメールが認証に失敗する状態のままポリシーを強化してしまうことです。メール配信システムやCRMなど、把握していない送信経路が残っていると、そこから送られる正規メールが隔離・拒否されてしまいます。noneから始めてレポートで送信経路を洗い出す手順を必ず守る必要があります。

類似ドメインや表示名の偽装は防げない

DMARCが防げるのは「自社ドメインそのもの」を差出人にしたなりすましです。一方で、次のような手口には効果がありません。

1つ目は類似ドメイン（ドッペルゲンガードメイン）です。example.comに対するexampIe.com（小文字のlを大文字のIに変えるなど）のように、本物に似せた別ドメインから送信する手口です。

2つ目は表示名の偽装です。差出人の表示名だけを「〇〇株式会社」と偽装し、実際のメールアドレスには攻撃者のドメインを使う手口です。

DMARCはドメイン認証の技術であり、受信者への注意喚起や迷惑メールフィルタなど、他の対策と組み合わせて運用することが前提です。

転送やメーリングリストでは正規メールも失敗しうる

メールが転送されたり、メーリングリストを経由したりすると、正規のメールでもDMARCに失敗することがあります。転送で送信元IPが変わるとSPFが失敗し、メーリングリストが件名や本文を書き換えるとDKIM署名が壊れるためです。

この「間接的な配送経路」の問題は、DMARCの仕様上まだ解決されていません。RFC 9989でも、利用者がメーリングリストに投稿するようなドメインについては、影響を評価しないままp=rejectを適用することに慎重な姿勢が示されています。自社の送信経路を把握したうえで、ポリシーを強める判断が必要です。

SPF・DKIMの整備が前提になる

DMARCは、SPF・DKIMが正しく設定され、かつアライメントを満たす構成になって初めて効果を発揮します。特に外部のメール配信サービスを利用している場合は、自社ドメインでのDKIM署名（作成者署名）が設定できるかを確認しておく必要があります。

DMARC導入の先にある「BIMI」とは

DMARCのポリシーをquarantineまたはrejectまで引き上げると、「BIMI（Brand Indicators for Message Identification）」を活用できるようになります。

受信トレイに自社ロゴを表示できる

BIMIとは、DMARC認証を利用して、受信トレイの送信者名の横に企業の公式ロゴマークを表示させる仕組みです。

表示にはDMARCポリシーの強化に加えて、ロゴを指定するBIMIレコードの公開が必要です。GmailなどBIMIに対応する一部のサービスでは、あわせてVMC（認証マーク証明書）の取得も求められます。

通常、受信画面の送信者アイコンは空白か名前の頭文字ですが、BIMIに対応すると、メールを開く前から「間違いなくあの企業からのメールだ」と一目で判別できるようになります。

BIMIを導入するメリット

BIMIには、なりすまし対策とメールマーケティング成果向上の両面で効果が見込めます。

実際にBIMIを導入するとどのような手順になるのか、担当者目線の体験談を以下の記事で紹介しています。

BIMIについて詳しく知りたい・相談したい場合

BIMIのメリットから導入ステップ、DMARC移行のロードマップ、設定チェックリストまでをまとめた「BIMI完全ガイド」を無料で用意しています。BIMIについてのお問い合わせや相談も可能です。

>>BIMI完全ガイドを無料でダウンロードする

>>BIMI導入について無料で相談・問い合わせする

DMARC対応にはメール配信システムの活用も選択肢になる

DMARC対応の前提となるのは、SPF・DKIMの正しい設定と、アライメントを満たす送信環境の整備です。メルマガなどの一斉配信を行う企業の場合、送信ドメイン認証に対応したメール配信システムを利用することで、この環境を整えやすくなります。

メール配信システムとは

メール配信システムとは、多数の宛先へ同時にメールを送信するためのシステムです。大規模なメール送信はスパムと見なされやすく、迷惑メールフォルダへの振り分けや不達が発生しがちですが、メール配信システムは到達率を高めるための技術と配信基盤を備えており、大量のメールを安全に配信できます。

送信ドメイン認証対応のシステムを選ぶメリット

送信ドメイン認証に対応したメール配信システムを使うメリットは以下の通りです。

DMARC運用の前提となる認証環境を自力でゼロから構築するのは負担が大きいため、実績のある配信システムの活用も選択肢になります。

おすすめのメール配信システム「ブラストメール」

ブラストメール（blastmail）は、15年連続で導入社数シェアNo.1（※）を獲得している日本最大級のメール配信システムです。導入実績は27,000社以上。SPF・DKIMといった送信ドメイン認証やGmail送信者ガイドラインに対応した配信基盤で、メルマガや一斉配信を確実に届けます。

「DMARC対応を進めたいが、まず認証に対応した配信環境を整えたい」という企業に最適な選択肢です。無料トライアルで実際の操作感を試せますので、ぜひ一度お試しください。

公式サイト：シェア1位のメール配信システム「ブラストメール」

※ミックITリポート2025年8月号「クラウド型eメール一斉配信サービスの市場動向と中期予測（売上高/アクティブ法人顧客数）」より

おすすめのメール配信システム「blastengine」

blastengine（ブラストエンジン）は、お客様のシステムとSMTPリレーやAPIで連携して、トランザクションメールや一斉配信を高速・確実に届けるメール配信サービスです。SPF・DKIM・DMARCといった送信ドメイン認証に標準対応しており、認証環境の構築をスムーズに進められます。

システムからの自動送信メールも含めてDMARC時代の認証要件を満たしたい企業や、メールサーバーの管理から解放されたいエンジニアにおすすめです。初期費用は無料、メールアドレスの入力だけでトライアルを開始できます。

ブラストエンジン公式サイト：https://blastengine.jp/

まとめ

DMARCは、SPF・DKIMの認証結果とヘッダーFromの一致（アライメント）を検証することで、受信者の目に映る差出人の偽装を防ぐ送信ドメイン認証技術です。認証失敗時のポリシーを送信側が指定でき、レポートによってドメインの悪用状況を可視化できる点が、他の認証技術にはない特長です。

Gmail・Yahoo!メールの送信者ガイドラインによってDMARC対応はすでに必須の領域に入っており、フィッシング被害が高止まりする中、対応の遅れは自社ドメインが狙われるリスクに直結します。まずはp=noneでのレコード公開とレポート収集から始め、段階的に対応を進めるのが現実的です。