DMARCとは？ 定義、仕組み、そしてその重要性

DMARC（Domain-based Message Authentication, Reporting, and Conformance）は、ドメイン所有者がSPFおよびDKIMの検証に失敗したメールの処理方法を制御できる電子メール認証プロトコルです。受信メールサーバーに対し、認証されていないメールを監視、隔離、または拒否するよう指示することで、フィッシング、スプーフィング、およびビジネスメール詐欺からドメインを保護します。

DMARCは現在、元のRFC 7489に代わってRFC 9989（2026年5月）によって規定されています。RFCの更新前に正しく設定されていた既存のレコードは引き続き有効であるため、移行する必要はないという点に留意することが重要です。

DMARCとは何の略ですか？ 正式名称

DMARC は、Domain-based Message Authentication, Reporting, and Conformance（ドメインベースのメッセージ認証、報告、および適合性）の略です。この名称の各部分は、プロトコルが実際に行う機能に対応しています：

• ドメインベース：DMARCは、個々のメッセージ単位ではなく、ドメインレベルで機能します。自分のドメインから送信されたと主張するすべてのメールを管理するDNSポリシーを1つ公開します。
• メッセージ認証：SPFおよびDKIMの結果を確認し、それらが表示されている「From:」アドレスと一致しているかどうかを検証することで、そのメールが実際にあなたのドメインから送信されたものであることを確認します。
• レポート：受信サーバーからは、お客様のドメインを使用してメールを送信しているユーザーや、認証の結果に関するレポートが送信されます。
• 準拠：送信者は、検証に失敗したメールの処理方法を受信者に指示するポリシー（「なし」、「隔離」、「拒否」）を公開し、受信者はそれに従います。

DMARCはどのように機能するのですか？

DMARCは、受信メールがSPFまたはDKIMの検証に合格しているかどうかを確認し、その結果が「From:」フィールドに表示されているドメインと一致していることを確認することで機能します。その後、DNSに公開したポリシーを適用します。DMARCはSPFとDKIMを基盤としており、これら2つの方式が単独では備えていない機能を補完するものです。

ご自身のドメインから送信されたと主張するメールが届くと、受信サーバーは両方のチェックを実行し、いずれかが「From:」ドメインと一致するかどうかを確認した上で、DNSで公開されているポリシーを適用します。最後に、何が起こったかを正確に把握できるよう、レポートが送信されます。

メール認証の仕組み：SPF、DKIM、DMARC

以下は、メールが送信された瞬間から、そのレポートが受信トレイに戻ってくるまでの全流れです：

1. メールの送信：サーバーが、「From:」アドレスにあなたのドメインを使用してメッセージを送信します。
2. SPF チェック：受信サーバーは、送信元の IP アドレスがお客様のドメインの SPF レコードで許可されているかどうかを確認します。
3. DKIM チェック：受信側は、DNS に公開されている公開鍵を用いてメッセージの DKIM 署名を検証し、メッセージが転送中に改ざんされていないことを確認します。
4. DMARCの評価と整合性確認：DMARCは評価結果を確認するだけでなく、SPFまたはDKIMによって認証されたドメインが、表示されている「From:」ヘッダーのドメインと一致しているかどうかも確認します。少なくとも一方が合格し、かつ両者が一致している必要があります。
5. ポリシーの適用：公開されているポリシーに基づき、受信側はメッセージを通常通り配信（なし）、スパムフォルダへ送信（隔離）、またはメッセージをブロック（拒否）します。
6. レポートの送信：受信側は、通常24時間以内に、検知した内容をまとめた集計レポートをあなたに返信します。

DMARCアラインメントとは何ですか？

アライメントとは、SPF や DKIM の検証に合格したドメインと、受信者が「From:」フィールドで実際に目にするドメインとを結びつける仕組みです。あるドメインに対して SPF や DKIM の検証に合格したメッセージであっても、「From:」ヘッダーには送信者のドメインが表示される場合があります。アライメントは、認証されたドメインと「From:」ドメインが一致することを必須条件とすることで、この不一致を解消します。

アライメントモードには2種類あります：

• 緩やかな整合性（デフォルト）では、組織ドメインレベルでの一致が認められるため、mail.example.com は example.com と整合します。
• 厳密な位置合わせには、完全な一致が必要です。

アラインメントが行われない場合、攻撃者は自身が管理するドメインを使用してSPFを通過させつつ、依然として送信元アドレスを偽装することが可能になります。これこそが、DMARCが解消するために導入された抜け穴なのです。

2種類のアライメントの種類や、どのような設定をいつ行うべきかについては、当社のDMARCアライメントガイドで詳しくご確認ください。

DMARC、SPF、DKIM：これらがどのように連携するか

DMARCはSPFやDKIMに代わるものではなく、これらに依存しています。これら3つのプロトコルは、認証の問題のそれぞれ異なる部分を扱っており、DMARCはそれらを統合する役割を果たしています。

各プロトコルの詳細については、当社のDMARC、SPF、DKIMガイドをご覧ください。

SPFの働き

SPF（Sender Policy Framework）は、特定のドメインのメール送信を許可されるIPアドレスやサーバーを定義するものです。受信サーバーは、エンベロープの「From」（Return-Path）アドレスを、公開されているSPFレコードと照合します。その限界として、SPFは受信者が実際に目にする「From:」ヘッダーを保護しないため、メッセージがSPFの検証を通過しても、偽装された「From:」ドメインが表示される可能性があります。

DKIMの機能

DKIM（DomainKeys Identified Mail）は、各メッセージに暗号署名を付加します。受信者は、DNSに登録された公開鍵を用いてその署名を検証し、メッセージが転送中に改ざんされていないことを確認するとともに、署名元のドメインを特定します。その限界として、SPFと同様に、DKIMでは「From:」ヘッダーに表示されているドメインとは異なるドメインでも有効とみなされる可能性があるため、これだけでは「From:」のなりすましを防止することはできません。

なぜDMARCが不可欠なのか

SPFとDKIMはそれぞれ個別の認証メカニズムですが、いずれも検証に失敗した場合の受信側の対応を規定しておらず、検証結果を「From:」ドメインと関連付けることもありません。DMARCは、これらの欠けていた部分を補完します。つまり、SPFとDKIMを連携させ、「From:」ドメインとの整合性を要求し、適用ポリシーを公開し、レポート機能を有効にします。DMARCがなければ、SPFとDKIMの両方が導入されていても、なりすまし攻撃が成功してしまう可能性があります。

SPF・DKIM・DMARCの比較表

DMARCポリシー：「なし」、「隔離」、「拒否」

DMARCポリシーは、認証や整合性のチェックに失敗したメールに対して、受信サーバーがどのように処理すべきかを指定するものです。DMARCポリシーには3種類あり、それぞれが前のポリシーよりも厳しい適用レベルとなっています。

p=なし（モニター）

強制措置は一切行われません。配信に失敗したメールも引き続き配信され、誰があなたに代わって送信しているかを確認できるよう、レポートが送信されます。これは、新しい導入環境において、まず取るべき適切な第一歩です。

コンプライアンスに関する注意：「p=none」は、GmailおよびYahoo!の大量送信者に関する要件、ならびにPCI DSS v4.0のフィッシング対策要件を満たしません。これらの要件は厳格な遵守が求められています。

p=検疫（緩やかな実施）

配信に失敗したメールは、受信トレイではなくスパムまたは迷惑メールフォルダに振り分けられます。正当で認証済みのメールには影響ありません。コンプライアンスに関する注記：この隔離措置は、Gmail、Yahoo、Microsoft、およびPCI DSS v4.0の要件を満たしています。

p=却下（完全施行）

配信に失敗したメールは即座に拒否され、受信トレイやスパムフォルダには一切届きません。これは最も強力な保護レベルです。コンプライアンスに関する注記：「reject」は現在のすべての要件を満たしています。RFC 9989 における注意点として、ユーザーがメーリングリストに投稿するドメインの場合、「p=quarantine」を設定する方が、より安全な恒久的なポリシーとなる可能性があります。これは、メーリングリストでは認証が破綻し、正当なメールが拒否されてしまうことが多いためです。

DMARCレポートとは何ですか？

DMARCは、可視性データを提供してくれる唯一のメール認証プロトコルです。これらのレポートこそが、強制適用に移行する前にDMARCをp=noneで公開する最大の理由です。これらのレポートには、あなたのドメインを名乗ってメールを送信しているすべての送信元が表示されるため、ブロックを開始する前に、正当な送信者がすべて通過していることを確認することができます。

アグリゲートレポート（RUA）

集計レポートとは、お客様のドメインからのメールを処理したすべての受信メールサーバーから送信される、日次のXML形式の要約レポートです。 各レポートには、送信元IPアドレス、メッセージ量、SPFの合格/不合格、DKIMの合格/不合格、DMARCの総合結果、および適用された処理が記載されています。これらは、レポートなしではポリシーを安全に強化できないため重要です。隔離や拒否に移行する前に、すべての正当な送信者が合格していることを確認する必要があります。生のXMLを手作業で読み解くのは非効率であるため、ほとんどのチームでは当社のDMARCレポートアナライザーを使用して、レポートを読みやすいダッシュボードに変換しています。

レポートの閲覧が初めての方は、DMARCレポートの読み方に関するステップバイステップガイドをご覧いただき、わかりやすい手順をご確認ください。

不具合報告（RUF）

失敗レポート（以前はフォレンジックレポートと呼ばれていました）は、個々のメールがDMARCの検証に失敗した際に送信される、メッセージ単位の通知です。これらは集計レポートよりも詳細な情報を提供します。プライバシーに関する注意：Google、Microsoft、Yahooは現在、失敗レポートを送信していません。したがって、お使いのドメインに失敗レポートが届く場合は、小規模なプロバイダーからのものです。これらのレポートを処理するためのプロセッサを設定している場合にのみ、レコードにruf=タグを含めてください。

DMARCはどのような脅威から保護するのでしょうか？

DMARCの主な役割は、攻撃者があなたのドメインから送信されたように見せかけたメールを送信するのを阻止することです。これにより、メールを悪用した攻撃のうち、最も被害の大きい3つのタイプをカバーすることができます。

なりすましメール

なりすまし攻撃では、攻撃者が、例えば [email protected] といった、あなたのドメインとまったく同じように見えるメールアドレスからメールを送信します。p=reject に設定された DMARC は、これらのメッセージがあなたのドメインの認証および整合性チェックを通過できないため、受信トレイに届く前にブロックします。

フィッシング攻撃

フィッシングメールは、貴社のブランドを装い、顧客や従業員を騙して認証情報や金銭をだまし取ろうとするものです。DMARCを強制適用することで、攻撃者は貴社のドメインを送信元として使用できなくなり、その結果、貴社から実際に送信されたかのように見える、最も説得力のあるフィッシングメールを排除することができます。

ビジネスメール詐欺(BEC)

BEC攻撃では、CEOやCFO、あるいは信頼できるベンダーを装い、電信送金や機密データの提供を要求してきます。DMARCは、攻撃者が貴社の実際のドメインを偽装する「正確なドメイン型BEC」を阻止します。なお、表示名が「CEO名」と表示されるものの、その背後にあるドメインが貴社とは無関係である「表示名偽装」については、攻撃者が貴社のドメインを一切使用していないため、DMARCでは阻止できません。

DMARCを導入するメリット

1. 特定ドメインを標的としたフィッシングやなりすましを阻止：ドメインのなりすましは受信者に届く前にブロックされるため、顧客や従業員に対する最も巧妙な攻撃を排除します。
2. ブランドの評判を守る：顧客が、貴社から送信されたように見せかけた詐欺メールを受け取らなくなるため、ブランドへの信頼を維持できます。
3. メールの配信率を向上させます。認証済みのメールは受信者から信頼され、受信トレイに届く可能性が高くなりますが、認証されていないメールはスパムとしてマークされてしまうことがあります。
4. 完全な可視性を提供：集計レポートには、忘れ去られたサービスや無許可の送信者を含め、お客様のドメインからメールを送信しているすべての送信元が表示されます。
5. BIMIを有効にする：対応している受信トレイでメッセージの横にBIMIブランドロゴを表示するには、p=quarantine または p=reject ポリシーが前提条件となります。
6. コンプライアンス要件を満たします：エンフォースメントレベルのDMARCは、PCI DSS v4.0、Google/YahooおよびMicrosoftの一括送信者に関する規則、ならびにCISA BOD 18-01の要件を満たすのに役立ちます。

2026年のDMARC準拠要件

コンプライアンスは、組織がDMARCを導入する最大の理由となっています。過去2年間で、主要なメールプロバイダーやいくつかの規制当局は、DMARCを「ベストプラクティス」から「必須要件」へと位置づけました。重要な点として、「p=none」の設定では、以下の要件のいずれも満たしておらず、これらの機関が求めているのは、強制措置（隔離または拒否）の実施です。

Gmail および Yahoo（2024年2月以降）

2024年2月以降、GmailとYahooは、1日あたり5,000通以上のメッセージを送信する大量送信者に対し、SPF、DKIM、および公開されたDMARCレコードの使用を義務付けています。Gmailは2025年11月、基準を満たさないメールを恒久的に拒否する措置を本格化させました。p=noneのレコードは、DMARCレコードを公開するための最低限の要件を満たしていますが、実際の保護をもたらすのは、その適用（隔離または拒否）です。

Microsoft Outlook（2025年5月以降）

マイクロソフトは2025年5月5日より、大量送信者に対する認証要件の適用を開始しました。これにより、認証に失敗した大量メールは、迷惑メールフォルダに振り分けられるのではなく、SMTPレベルで即座に拒否されることになります。DMARCは、1日あたり5,000通以上のメッセージを送信する送信者に対するマイクロソフトの認証要件の一部です。

PCI DSS v4.0（2025年3月以降）

PCI DSS v4.0.1の要件5.4.1では、決済カードデータを扱う組織に対し、SPFおよびDKIMに加え、DMARCを含む自動化されたフィッシング対策メカニズムの導入が求められています。これは2025年3月31日より必須となりました。「p=none」の監視専用レコードではこの要件を満たしません。監査人は、強制適用ポリシーの策定を期待しています。

CISA BOD 18-01（米国連邦ドメイン）

米国サイバーセキュリティ・インフラセキュリティ庁（CISA）の「拘束力のある運用指令 18-01」（CISA BOD 18-01）は、連邦行政機関のすべてのドメインに対し、DMARCをp=rejectで実装することを義務付けています。これは、単なる導入にとどまらず、強制力のあるレベルのポリシーを義務付けた初の政府指令でした。

世界各国のコンプライアンス要件や推奨事項について詳しく知りたい場合は、当社の「DMARCコンプライアンス要件ガイド（完全版）」をご参照ください。

2026年のDMARC導入状況：主要統計データ

PowerDMARCが発表した2026年のメールフィッシングおよびDMARCに関する統計データからは、世界的な傾向が明確に浮かび上がっています。すなわち、フィッシング攻撃は増加の一途をたどっており、DMARCの導入は拡大しているものの、まだ普遍的なものとは程遠く、導入しているドメインのほとんどは、実際になりすましをブロックできるレベルの適用には至っていないということです。

• 世界でアクセス数が最も多い上位1,000万ドメインのうち、有効なDMARCレコードを公開しているのは約18％に過ぎず、リジェクトポリシーを完全に適用しているのはわずか4％程度にとどまっています（2025年第2四半期の分析）。そのため、大多数のドメインがなりすましやブランド偽装のリスクにさらされたままとなっています。
• DMARCを公開しているドメインのうち、その大半は強制措置を講じていません。68.2%が「p=none」を、12.1%が「p=quarantine」を採用しており、厳格な「p=reject」ポリシーを採用しているのはわずか19.6%にとどまっています。
• 施行への意欲も低い。ポリシーを「なし」と回答した送信者のうち、1年以内にポリシーを強化する計画があるのはわずか25.5％にとどまり、61％は「規制や業務上の必要性に迫られた場合にのみ強化する」と回答している。
• 認証要件は、その効果が最も顕著に現れる分野で成果を上げている。GoogleとYahooが一斉送信者に対する要件を導入した後、GoogleはGmailに届く未認証メッセージが65％減少したと報告しており、2024年だけで2,650億通の未認証メッセージが減少した。
• その影響は甚大です。フィッシング関連の情報漏洩による平均的な損害額は約488万ドルに上り、ビジネスメール詐欺による報告された損失額は約29億ドルに達しました。

RFC 9989: 2026年版 DMARC 標準の更新

2026年5月、RFC 9989がRFC 7489に代わってDMARCの標準規格となりました。これは、2015年の最初の仕様策定以来、初めての大きな更新となります。既存のレコードは引き続き有効であるため、移行作業は必要ありません。ただし、非推奨となったタグを使用しているドメイン所有者は、新たな改良点を反映させるためにレコードの更新を検討してもよいでしょう。

変更点は、レコードで公開できるタグに対する、いくつかの実用的な改良です。主な変更点は以下の通りです：

• pct= は非推奨となりました。受信側に、失敗したメールの一部にのみポリシーを適用するよう指示していた旧式のパーセンテージタグは、プロバイダによって動作が予測不能であったため、削除されました。
• np= が追加され、正当なメールを一切送信しない、存在しないサブドメインに対して個別のポリシーを設定できるようになりました。これにより、攻撃者が作り出す可能性のあるサブドメインからのメールを拒否しつつ、正常にメールを送信しているサブドメインには影響を与えないようにすることができます。
• t= が追加され、テストや段階的な展開を示すようになりました。これにより、非推奨となった pct= タグよりも、より明確で標準化された方法で適用へと移行できるようになりました。

変更点の詳細については、当社のDMARC RFC 9989ガイドをご参照ください。

DMARCの限界：保護できないもの

DMARCは、正確なドメインを装ったなりすましに対して非常に効果的ですが、完全な不正防止策というわけではありません。そのため、DMARCがカバーできない範囲について明確にしておく価値があります：

• 攻撃者が「paypa1.com」や「paypal-secure.com」といった類似したドメインを登録する「類似ドメイン攻撃」に対しては、この対策は有効ではありません。これは、ご自身のドメインに設定されたDMARCが、他のドメインに対して権限を持たないためです。
• これにより、表示名が悪用されるケース――つまり、送信者名として表示される名前が自社ブランドのように見えるものの、実際のメールドメインはそれとは無関係であるようなケース――を防ぐことはできません。
• 乗っ取られた正規のアカウントについては、この対策では役に立ちません。なぜなら、乗っ取られた正規のアカウントから送信されたメールは、正しく認証されるからです。

DMARCの対象範囲を超える脅威については、当社の「類似ドメインチェッカー」を利用して、類似ドメイン、タイポスクワッティング、ホモグリフ攻撃の検知に向けた調査を開始することができます。

DMARCの導入方法

始めるのに、複雑な設定は必要ありません。以下の手順に従えば、すぐに始められます：

1.SPF、DKIM、DMARCレコードを確認してください：前述の通り、DMARCが機能するにはSPFまたはDKIMのいずれかが設定されている必要があります（できれば両方）。そのため、作業を開始する前に、これらのレコードが存在するかどうかを確認する必要があります。当社の「ドメインアナライザー」でドメインを分析することで、SPF、DKIM、DMARCレコードが存在するかどうか、および現在のレコードポリシーを一括で確認できます。

2.レコードがない場合は作成してください： 当社のDMARCジェネレーターツールを使用して有効な構文を作成し、DNSにレコードを登録してプロトコルを有効化してください。まずはポリシーを常に「none」に設定し、配信状況に自信が持てるようになったら、徐々に適用レベルを引き上げていくようにしてください。

3.DNSにレコードを追加します：DNS管理コンソールを開き、_dmarc.yourdomain.com の下に DMARC レコードを TXT レコードとして公開します。

4.DMARCチェッカーで確認する：最後に、24時間経過した後、当社のDMARCチェッカーツールでドメインを検証し、公開したレコードが有効でエラーがないかを確認してください。

DMARCの設定方法に関する完全な手順については、リンク先のブログに掲載されている詳細なステップバイステップのチュートリアルをご参照ください。

まとめ

DMARCは、単なるセキュリティ上の推奨事項から、必須の基準へと変化しました。これは、貴社のドメイン名を含むメールが真に貴社から送信されたものであることを世界に示すものであり、貴社がすでに対応を求められているメールボックスプロバイダーや規制当局からも、その導入がますます求められています。プロトコル自体は複雑ではありません。レコードを公開し、レポートを確認し、正当な送信者が順次対応するにつれてポリシーを厳格化していくだけです。真の課題は、監視段階から徹底した実施段階へと移行することにあります。

PowerDMARCは、監視と適用プロセスを代行するフルスタック型DMARC管理プラットフォームです。生のレポートを読みやすい分析結果に変換し、正当なメールをブロックすることなく「p=reject」を達成できるよう支援します。

よくあるご質問

DMARCとは何ですか？

DMARCレコードとは、_dmarc.yourdomain.com に公開されるDNSのTXTレコードのことです。このレコードには、DMARCポリシーと、レポートの送信先となるメールアドレスが記載されています。DMARCレコードを作成して公開することは、ドメインでDMARCを導入するための第一歩となります。

2026年にはDMARCの導入が義務付けられるのでしょうか？

はい、大量送信者にとってはそうです。GmailとYahoo!は、2024年2月以降、1日あたり5,000通以上のメールを送信するドメインに対してDMARCの導入を義務付けており、Microsoftも2025年5月からこの要件の適用を開始しました。また、PCI DSS v4.0では、2025年3月以降、決済カードデータ処理業者に対してDMARCの導入が義務付けられています。大量送信者でない場合でも、ドメインをなりすましから保護するため、DMARCの導入を強く推奨します。

DMARC、SPF、DKIMの違いは何ですか？

SPFは、特定のドメインに対してどのIPアドレスがメールを送信できるかを確認します。DKIMは、暗号署名を用いてメッセージの完全性を検証します。DMARCはこれら2つを統合し、表示されている「From:」ドメインと照合するとともに、適用ポリシーを追加し、レポート機能を提供します。完全なメール認証を行うには、これら3つすべてが必要です。

DMARCは何を防ぐのですか？

DMARCは、攻撃者があなたのドメインから送信されたように見せかけるメールを送信する「正確なドメインによるメールなりすまし」を防止します。これには、フィッシングメール、ブランドなりすまし、ビジネスメール詐欺などが含まれます。ただし、別のドメインが使用される「類似ドメイン攻撃」や「表示名のなりすまし」は防止できません。

DMARCを導入していない場合はどうなりますか？

DMARCが設定されていない場合、受信サーバーは、SPFおよびDKIMの検証に失敗した貴ドメインからのメールに対して、どのような対応を取るべきかという指針を持たないため、フィッシング攻撃において貴ドメインが自由になりすまされる可能性があります。2024年以降、DMARCが設定されていないことは、大量送信者にとっての配信率にも影響を及ぼすようになります。GmailやYahoo!メールが、正当なメールであっても拒否したり、配信優先度を下げたりする可能性があるためです。

DMARCはすべてのフィッシング攻撃を阻止できるのでしょうか？

いいえ。DMARCは、あなたのドメインを正確に偽装するフィッシング攻撃を防ぐことはできますが、類似ドメイン、表示名の悪用、あるいは乗っ取られた正規アカウントからの攻撃を防ぐことはできません。DMARCは、唯一の対策ではなく、より広範なメールセキュリティ戦略の一環として位置づけるべきです。

• について
• 最新記事

マイサム・アル・ラワティ

サイバーセキュリティの専門家、CEO（ PowerDMARCのCEO

マイサムは技術起業家であり、サイバーセキュリティの専門家であり、15年以上の業界経験を持つPowerDMARCのCEO兼創設者である。Maithamはマンチェスター大学でグローバルMBAを取得し、CISSP、CISM、CRISC、ISC2 CCSPなど様々な専門資格を持つ。

最新記事 by Maitham Al Lawati(全て見る)

• DMARCの設定方法：完全なステップバイステップ設定ガイド（2026年） - 2026年6月20日
• DMARCレポートの読み方：RUAとRUFの完全ガイド - 2026年6月10日
• DMARCとは？ 定義、仕組み、その重要性 - 2026年4月28日