世界の規制・送信者ルール・技術要件の要素のイメージ画像

DMARC要件とは？世界各地の規制・送信者ルール・技術要件

世界規制と主要プロバイダのDMARC要件


著者: Ahona Rudra
翻訳: 東條 百々朱

この記事はPowerDMARCのブログ記事 What Are DMARC Requirements? Global Rules, Policies, and Compliance の翻訳です。
Spelldataは、PowerDMARCの日本代理店です。
この記事は、PowerDMARCの許可を得て、翻訳しています。

主なポイント

  1. GoogleとYahooは、大量送信者に対してSPF、DKIM、DMARCなどのメール認証を求めています。
    Gmailでは2025年11月以降、送信者要件を満たさないメールに対する取り締まりが強化され、一時的または恒久的に拒否される可能性があります。
  2. Microsoftも、2025年5月からOutlook.com、Hotmail.com、Live.com宛てに1日5,000通を超えるメールを送信するドメインを対象に、SPF、DKIM、DMARCの要件適用を開始しました。
  3. 政府機関や規制対象業界では、メールセキュリティ対策の一環としてDMARCの導入を求めたり、強く推奨したりする動きが広がっています。
  4. 技術面では、SPFまたはDKIMによる認証に加え、認証されたドメインと「From:」ヘッダに表示されるドメインとのアライメントが必要です。
  5. 組織は、メール到達率への影響を監視しながら、DMARCポリシーをp=noneからp=quarantine、最終的にはp=rejectへ段階的に移行することが推奨されます。
  6. 2026年5月には、DMARCbisがRFC 9989、RFC 9990、RFC 9991として公開されました。
    これにより、DMARCの中核仕様、集約レポート、失敗レポートがStandards Track文書として整理されました。
  7. PCI DSS v4.0.1では、自動化されたフィッシング対策の導入が求められています。
    DMARCは、この要件への対応を支える有力な管理策の1つですが、規格がすべての組織へDMARCを一律に指定しているわけではありません。

DMARC要件は、もはや単なる技術上の推奨事項ではありません。
現在では、各国・地域の政策、業界のコンプライアンスフレームワーク、メールサービス提供者の送信者ルールが重なり合う、重要な運用要件となっています。
政府機関や公共部門では、公式ドメインをなりすましから保護するため、DMARCを正式なメールセキュリティ要件として採用する動きが見られます。

また、PCI DSSをはじめとするセキュリティ基準でも、フィッシング対策やメール認証は、より広範なセキュリティ管理の一部として重視されています。
同時に、Google、Yahoo、Microsoftなどのメールサービス提供者は、特に大量のメールを送信する事業者に対して、より強力な認証を求めています。
この変化により、DMARCは単にドメインスプーフィングを防ぐための技術ではなくなりました。

現在では、メール到達率、ブランド保護、顧客からの信頼、規制対応に直接影響する重要な仕組みです。
多くの組織にとって、DMARC要件を満たさないことは、メールの拒否や迷惑メール判定、フィッシングリスクの増加、コンプライアンス上の不備につながります。
2026年5月にDMARCbisが正式公開されたことで、この流れはさらに明確になりました。

従来のDMARC仕様であるRFC 7489は情報提供目的の文書でしたが、RFC 9989を中心とする新仕様はStandards Trackとして公開されています。
これは、DMARCがメール基盤を構成する標準技術として定着したことを示しています。
本ガイドでは、DMARCの導入を後押しする各地の規制やガイダンス、メールサービス提供者の要件、SPF・DKIM・アライメントなどの技術的な基盤について解説します。

DMARC要件とは？

DMARC要件とは、Domain-based Message Authentication, Reporting, and Conformanceを正しく運用するために、ドメイン所有者が満たすべき技術面およびポリシー面の条件です。
これらの要件は、大きく次の3つに分けられます。

1つ目は、政府機関や業界基準による規制・コンプライアンス上の要件です。
2つ目は、Google、Yahoo、Microsoftなどのメールサービス提供者が定める送信者要件です。
3つ目は、DMARCを正しく機能させるために必要なSPF、DKIM、ドメインアライメント、DNSレコードなどの技術要件です。

DMARCは、Sender Policy Framework（SPF）とDomainKeys Identified Mail（DKIM）を利用するメール認証プロトコルです。
送信メールが「From:」ヘッダに表示されたドメインから、正当に送信されたものであるかを検証します。

認証に失敗した場合、DMARCポリシーは受信メールサーバに対して、そのメールを通常どおり配信するか、隔離するか、拒否するかを示します。
ドメインがDMARC要件を満たすには、一般的に以下の条件が必要です。

Googleも、DMARCを使用するにはSPFまたはDKIMを有効にし、第三者送信元の送信サービスを含めて認証状況を確認するよう案内しています。
大きく変わったのは、要件を満たさない場合の影響です。
現在では、DMARCの設定不備がメール到達率やブランドへの信頼、規制上の評価へ直接影響する可能性があります。

DMARC要件の種類

DMARC要件は、以下の3つのカテゴリに分類できます。

規制・コンプライアンス上の要件
政府機関や業界団体が定めるサイバーセキュリティ基準です。
米国連邦政府のBOD 18-01のようにDMARCポリシーを具体的に指定しているものもあれば、NIS2やPCI DSSのように、より広いリスク管理やフィッシング対策の一環としてメール認証が利用されるものもあります。
メールサービス提供者の要件
Google、Yahoo、Microsoftなどが定める送信者ルールです。
特に大量送信者は、SPF、DKIM、DMARCの設定、迷惑メール率の管理、購読解除機能などの要件を満たさなければ、メールが遅延、隔離、拒否される可能性があります。
技術要件
SPF、DKIM、DMARCレコード、ドメインアライメント、PTRレコードなど、DMARCを正しく機能させるために必要な設定です。
これら3つの層を理解することが、DMARCコンプライアンスを達成し、維持するうえで重要です。

世界各地のDMARC要件

DMARCに関する義務や推奨事項は、国、地域、業界、組織の種類によって異なります。
一部の政府機関ではp=rejectが明示的に求められていますが、すべての国や民間企業に共通する世界統一のDMARC義務があるわけではありません。
各組織は、自社が属する法域、業界、契約上の要件を個別に確認する必要があります。

地域・制度 主な位置付け DMARCに関する扱い
米国連邦政府 明確な義務 BOD 18-01により対象機関へp=rejectを要求
英国公共部門 政府ガイダンス・個別要件 公共部門向けメールセキュリティ施策でDMARCを重視
欧州連合・NIS2 リスクベースのサイバーセキュリティ義務 DMARCを名指しで一律義務化するものではないが、メール保護策として利用可能
オーストラリア、カナダ、ニュージーランドなど 政府ガイダンスや組織別基準 政府ドメインを中心にメール認証の導入を推奨または要求
PCI DSS 自動化されたフィッシング対策 DMARCは対応を支える手段だが、規格本文で一律指定されてはいない
米国
米国連邦政府は、DMARCを国家レベルで明確に義務付けた代表的な例です。
2017年、米国国土安全保障省はBinding Operational Directive 18-01（BOD 18-01）を発行しました。

この指令では、対象となる連邦政府機関に対し、最初にp=noneでDMARCを導入し、その後1年以内にp=rejectへ移行することを求めています。
BOD 18-01は、政府ドメインに対するなりすましを防ぎ、DMARCレポートを通じて不正利用を把握することを目的としています。
英国
英国では、National Cyber Security Centre（NCSC）が公共部門向けのメールセキュリティ対策を推進しています。
政府機関や公共部門の組織では、DMARC、SPF、DKIMを利用して公式ドメインを保護することが重視されています。
ただし、適用対象や最低ポリシーは組織や制度によって異なるため、最新のNCSCガイダンスと所属機関の要件を確認する必要があります。
欧州連合
NIS2 Directiveは、エネルギー、金融、医療、デジタルインフラストラクチャなどの重要分野へ、リスクに応じた技術的・組織的なセキュリティ対策を求めています。
ただし、NIS2本文がすべての対象組織に対してDMARCを名指しで一律に義務付けているわけではありません。
DMARCは、フィッシング、ドメインスプーフィング、ビジネスメール詐欺への対策として、NIS2対応を支える技術的管理策の1つになり得ます。
その他の地域
オーストラリア、カナダ、ニュージーランド、オランダ、インド、中東諸国などでも、政府ドメインや規制対象組織を中心にメール認証の導入が進んでいます。
ただし、「必須」「推奨」「最低ポリシー」の扱いは制度ごとに異なります。
地域別の表を掲載する場合は、各国の規制当局や政府機関が公開している最新文書を確認し、対象組織と適用範囲を明記することが重要です。

Google、Yahoo、MicrosoftのDMARC要件

政府や業界規制に加え、メールサービス提供者は受信トレイ到達の条件としてメール認証を求めています。
特に大量送信者は、これらの要件を満たさない場合、メール配信へ直接影響を受けます。

大量送信者とは？
Googleでは、個人用Gmailアカウントへ1日あたり5,000通を超えるメールを送信するドメインを、大量送信者として扱います。
Yahooも大量送信者向けの要件を設けていますが、判定方法や適用条件はGoogleと完全に同一とは限りません。
Microsoftは、Outlook.com、Hotmail.com、Live.com宛てに1日5,000通を超えるメールを送信するドメインへ要件を適用しています。
要件の概要
メールサービス提供者 DMARCに関する最低要件 主な追加要件
Google 最低p=none SPF、DKIM、アライメント、TLS、購読解除、低い迷惑メール率
Yahoo DMARCレコードを公開 SPF、DKIM、購読解除、苦情率や無効アドレスの管理
Microsoft 最低p=none SPF、DKIM、適切なDNS設定と送信衛生

Yahooは、送信ドメインごとにDMARCポリシーを公開し、すべてのメールをDKIMで認証することを強く求めています。
Googleでは、2025年11月から送信者要件を満たさないメールへの取り締まりが強化され、一時的または恒久的な拒否が発生する可能性があります。
Microsoftは2025年5月から要件適用を開始し、準拠していない送信者に対してフィルタリングやブロックなどの措置を取る可能性があると説明しています。

LDMARCbis：新しいDMARC標準

2026年5月、IETFはDMARC関連仕様を次の3つのRFCとして公開しました。

RFC 9989
DMARCの中核仕様です。
従来のRFC 7489と、Public Suffix Domain向けのRFC 9091を置き換えます。
RFC 9990
DMARCの集約レポート形式を定義します。
RFC 9991
個別の認証失敗に関する失敗レポートを定義します。

これらはStandards Track文書として公開されており、DMARCの仕様をより明確に整理しています。

DMARCbisが運用へ与える影響

DMARCbisでも、基本的な考え方は変わりません。
SPFまたはDKIMの少なくとも一方が認証に成功し、「From:」ヘッダのドメインとアライメントする必要があります。

主な変更点には、組織ドメインの判定方法の改善や、レポート仕様の分離・明確化などがあります。
すでにSPF、DKIM、DMARCを適切に運用し、レポートを監視している組織は、基本的に新仕様へ対応しやすい状態にあります。

PCI DSSとDMARCの関係

決済カード情報を扱う組織にとって、フィッシング対策は重要なコンプライアンス要件です。
PCI DSS v4.0.1の要件5.4.1では、従業員をフィッシング攻撃から検知・保護するためのプロセスと自動化された仕組みを導入することが求められています。

ただし、PCI DSSがすべての対象組織へDMARCを名指しで一律に義務付けている、という説明は正確ではありません。
DMARC、SPF、DKIMは、次の点でPCI DSSのフィッシング対策を支援できます。

DMARCだけでPCI DSS要件を満たせるわけではなく、セキュアメールゲートウェイ、URL・添付ファイル検査、従業員教育、インシデント対応などを組み合わせる必要があります。

DMARC要件を満たさない場合に起きること

DMARC要件を満たしていない場合、メール到達率、ブランド、セキュリティ、コンプライアンスへさまざまな影響が生じます。

メール到達率への影響
状況 想定される影響
DMARCレコードがない ドメインの不正利用を把握・制御しにくくなります
GoogleやYahooの要件を満たしていない メールが遅延、隔離、拒否される可能性があります
迷惑メール率が高い 送信者評価が低下し、受信トレイへ届きにくくなります
SPFまたはDKIMがアライメントしていない 認証自体が成功してもDMARCでは失敗する場合があります
DNSやPTRの設定が不適切 受信サーバから信頼性の低い送信元と判断される可能性があります
ブランドへの影響
DMARCポリシーを設定していない場合、攻撃者が自社ドメインを「From:」ヘッダへ設定し、フィッシングメールを送信する可能性があります。
顧客が自社ブランドを装った詐欺メールを受信すると、実際の送信者が攻撃者であっても、ブランドへの信頼が損なわれることがあります。

なお、DMARCで防げるのは主に自社ドメインを直接使用するなりすましです。
brand-secure.exampleのような類似ドメインや、表示名だけを偽装する攻撃には、別途ドメイン監視や受信側のセキュリティ対策が必要です。
規制・契約上の影響
政府調達、業界基準、取引先との契約などでメール認証が求められている場合、DMARCの未導入や設定不備が監査指摘や契約上の問題につながることがあります。
ただし、罰金や事業停止などの具体的な影響は、適用される規制、カードブランド、契約、監督機関によって異なります。

基本要件：SPFとDKIM

DMARCは、SPFとDKIMの認証結果を利用します。
技術的には、SPFまたはDKIMの一方が正しくアライメントすればDMARCに成功できますが、実際の運用では両方を設定することが推奨されます。
Googleも、大量送信者にSPF、DKIM、DMARCのすべてを求めています。

Sender Policy Framework（SPF）

SPFは、自社ドメインに代わってメールを送信できるサーバをDNS TXTレコードで指定する仕組みです。
受信サーバは、メールの送信元IPアドレスがSPFレコードで許可されているかを確認します。
DMARCでSPFを利用する場合、SPF認証に使用されたエンベロープFromのドメインが、「From:」ヘッダのドメインとアライメントしている必要があります。

DNSルックアップ回数の上限
SPFでは、include、a、mx、redirectなどによって発生するDNSルックアップを10回以内に抑える必要があります。
上限を超えるとPermErrorとなり、DMARCでもSPF認証の成功として扱われません。
複数のメール配信サービスを利用している組織は、不要なincludeを削除し、送信元を整理する必要があります。
複雑なメール送信環境
マーケティング、CRM、請求、ヘルプデスクなど、多数の外部サービスが自社ドメインを使用している場合、SPFレコードが複雑になりやすくなります。
その場合は、サブドメインの分離、SPFマクロ、マネージドSPFなどを利用し、設定の簡素化を検討します。

DomainKeys Identified Mail（DKIM）

DKIMは、送信メールのヘッダと本文へ暗号学的な署名を付加します。
受信サーバは、DNSで公開されている公開鍵を使用し、署名後にメールが改竄されていないかを確認します。

DMARCでDKIMを利用する場合、DKIM署名のd=タグで指定されたドメインが、「From:」ヘッダのドメインとアライメントしている必要があります。
DKIM署名自体が有効でも、d=ドメインがESPのドメインで、「From:」が自社ドメインの場合は、DMARCのDKIMアライメントには成功しません。

認証方式 主な確認内容 転送への耐性
SPF 送信元IPアドレスが許可されているか 転送で失敗しやすい
DKIM 署名対象のヘッダや本文が改竄されていないか SPFより耐性があるが、本文やヘッダが変更されると失敗する場合がある

DMARCの設定手順

SPFとDKIMが正しく設定され、認証結果を確認できたら、DMARCレコードを公開します。
レコードに誤りがあると、レポートを受信できなかったり、正当なメールが認証に失敗したりする可能性があります。

1.送信元を把握する
自社ドメインを使用してメールを送信するすべてのサービスを一覧化します。
社内メールだけでなく、マーケティングツール、CRM、請求サービス、サポートシステム、採用ツールなども対象です。
2.SPFとDKIMを設定する
各送信元について、SPFまたはDKIMの少なくとも一方がアライメントするよう設定します。
可能であれば、両方を設定してください。
3.DMARCレコードを公開する
_dmarc.example.comへDNS TXTレコードを公開します。
導入初期は、次のようなp=noneのレコードから開始できます。

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com;
4.レポートを分析する
正当な送信元、未承認の送信元、アライメントの失敗、設定ミスを確認します。
5.ポリシーを段階的に強化する
正当なメールの認証に問題がないことを確認したら、p=quarantineへ移行します。
その後、影響を監視しながらp=rejectへ移行します。

DMARCレコードの構造

DMARCレコードはv=DMARC1から始めます。 


v=DMARC1; p=none; rua=mailto:reports@example.com;
タグ 目的 必須か
v=DMARC1 DMARCのバージョンを示します 必須
p= none、quarantine、rejectのいずれかを指定します 必須
rua= 集約レポートの送信先を指定します 推奨
ruf= 失敗レポートの送信先を指定します 任意
sp= サブドメインへ適用するポリシーを指定します 任意
pct= ポリシーを適用する割合を指定します 任意
adkim= DKIMアライメントの厳格度を指定します 任意
aspf= SPFアライメントの厳格度を指定します 任意

rufによる失敗レポートは、すべてのメールサービス提供者が送信するわけではありません。
また、メール内容や個人情報が含まれる可能性があるため、利用前にプライバシーや法的要件を確認してください。

その他のDNS要件

大量送信者は、DMARC以外のDNS設定も確認する必要があります。

PTRレコード
送信元IPアドレスの逆引きDNSが正しく設定され、ホスト名から同じIPアドレスへ正引きできる状態が望まれます。
MXレコード
受信メールを扱うドメインでは、MXレコードが正しく設定されている必要があります。
TLS
送信時の通信ではTLSを使用します。
Googleの送信者ガイドラインでも、メール送信時のTLS利用が要件に含まれています。

DMARCポリシーの違い

ポリシー 処理内容 主な利用段階
p=none 受信側へ特別な処理を求めず、主にレポートを収集します 導入初期
p=quarantine 認証に失敗したメールを迷惑メールなどへ隔離するよう求めます 段階的な強制適用
p=reject 認証に失敗したメールを拒否するよう求めます 完全な強制適用

DMARCポリシーは、受信側に対する処理の要請です。
受信メールサーバは、DMARC以外のシグナルや独自ポリシーも考慮するため、必ず指定どおりに処理されるとは限りません。
RFC 9989も、受信側がドメイン所有者の処理要請へ必ず従うわけではないことを明記しています。

推奨される導入方法

最初はp=noneでレポートを収集し、すべての正当な送信元を特定します。
次に、SPFやDKIMの設定ミス、アライメント不一致、転送による問題を修正します。
正当なメールの認証が安定したら、p=quarantineへ移行します。

影響を確認したうえで、最終的にp=rejectへ移行します。
監視を行わずにいきなりp=rejectへ設定すると、請求書、パスワードリセット、マーケティングメールなどの正当なメールが拒否される可能性があります。

大規模環境でDMARCを管理する方法

DMARCは、一度レコードを公開すれば終わる仕組みではありません。
新しいクラウドサービスの追加、送信経路の変更、ベンダの切り替え、ドメインの追加に応じて、継続的な管理が必要です。

DMARCレポートを理解する

DMARCでは、主に集約レポートを通じて、自社ドメインを使用するメールの状況を確認できます。
集約レポートは通常XML形式で提供されるため、送信量の多い組織では専用の分析ツールを利用した方が効率的です。

レポートの種類 主な内容
集約レポート（RUA） 送信元IP、認証結果、アライメント結果、ポリシー処理などの統計情報
失敗レポート 個別の認証失敗に関する情報
提供状況は受信側によって異なります
第三者送信元を管理する
DMARC導入で最も多い課題の1つが、外部のメール送信サービスです。
以下のようなサービスが自社ドメインを使用していないか確認してください。
  • マーケティングプラットフォーム
  • CRM
  • 請求・決済システム
  • ヘルプデスク
  • 採用管理システム
  • イベント管理サービス
  • アンケートツール
  • クラウドストレージの通知機能
p=quarantineやp=rejectへ移行する前に、それぞれの送信元でSPFまたはDKIMがアライメントするよう設定する必要があります。

複数ドメインを一元管理する

複数のブランド、国・地域、製品ごとにドメインを運用している場合、DMARCレコードとレポートを個別に管理する負担が増えます。
一元管理できるプラットフォームを利用すると、次の作業を効率化できます。

社内の専門知識を高める

外部サービスを利用する場合でも、DMARC、SPF、DKIMの基本を理解する担当者を社内に置くことが重要です。
特に、マーケティング部門や営業部門が新しいメール配信サービスを導入する際は、DNS管理者やセキュリティ担当者へ事前に連絡する手順を整備してください。

強制適用後に利用できる機能

BIMI
BIMIは、対応するメールサービスで送信者のブランドロゴを表示する仕組みです。
一般的に、DMARCポリシーをp=quarantineまたはp=rejectへ設定し、メールサービスごとの追加条件を満たす必要があります。
BIMIはメールの安全性を保証するものではありませんが、ブランドの視認性と信頼性を高める効果が期待できます。
MTA-STSとTLS-RPT
MTA-STSを設定すると、自社ドメイン宛てのメール配送でTLSを使用するよう送信側へ求められます。
TLS-RPTを併用すると、TLS接続や証明書に関する問題をレポートで確認できます。
DMARCが送信者ドメインの認証を扱うのに対し、MTA-STSはメール配送経路の暗号化を強化します。

PowerDMARCでDMARC要件への対応を進める

DMARCを取り巻く要件は今後も変化していく可能性があります。
Google、Yahoo、Microsoftは送信者認証を重視しており、政府機関や業界基準でもフィッシング対策への要求が高まっています。
DMARCへ適切に対応するには、以下の作業が必要です。

PowerDMARCは、最初のDMARCレコード公開から、p=rejectへの移行、その後の継続運用までを支援します。
Hosted DMARC、レポート分析、送信元の可視化、マネージドサービスなどにより、現在の要件を満たし、将来の変更にも対応しやすい環境を構築できます。
今すぐPowerDMARCの利用を開始してください。

よくある質問

1.DMARCには何が必要ですか？
SPFまたはDKIMの少なくとも一方を設定し、「From:」ヘッダのドメインとアライメントさせる必要があります。
実務上は、SPFとDKIMの両方を設定することが推奨されます。
また、DNSへDMARCレコードを公開し、必要に応じて集約レポートの送信先を指定します。
2.DMARCは現在必須ですか？
すべての組織へ世界共通で義務付けられているわけではありません。
ただし、GoogleやYahooへ大量のメールを送る送信者、Microsoftの大量送信者要件の対象となるドメイン、米国連邦政府機関などでは、DMARCが要件となっています。
対象外の組織でも、ドメインスプーフィング対策として強く推奨されます。
3.DMARCにはDKIMが必要ですか？
DMARCでは、SPFまたはDKIMの一方が認証とアライメントに成功すれば合格できます。
そのため、プロトコル上は必ずしもDKIMだけが必須というわけではありません。
ただし、メール転送ではSPFが失敗しやすく、大量送信者向け要件でもDKIMを求められるため、SPFとDKIMの両方を設定することが推奨されます。
4.DMARCはいつから必須になりましたか？
適用先によって異なります。
米国連邦政府機関では、2017年のBOD 18-01によって導入とp=rejectへの移行が求められました。
GoogleとYahooは2024年から大量送信者向け要件を適用し、Microsoftは2025年5月から高ボリューム送信者への要件適用を開始しました。
5.DMARCの導入にはどのくらいの時間がかかりますか？
環境の規模によって異なります。
単一のドメインと少数の送信元であれば、初期設定は数日で完了することがあります。
一方、複数のドメインや多数のクラウドサービスを利用している組織では、送信元の調査、認証設定、監視、ポリシー移行に数週間から数か月かかる場合があります。
6.DMARCを実装しないとどうなりますか？
自社ドメインを直接使用したなりすましを制御しにくくなります。
また、大量送信者要件を満たしていない場合、Gmail、Yahoo、Outlook.comなどへのメールが遅延、隔離、拒否される可能性があります。
送信者評価やブランドへの信頼にも悪影響が生じる可能性があります。
7.DMARCbisとは何ですか？
DMARCbisは、2026年5月にRFC 9989、RFC 9990、RFC 9991として公開された新しいDMARC仕様です。
中核プロトコル、集約レポート、失敗レポートを個別のStandards Track文書として整理し、従来のRFC 7489を置き換えました。
SPFまたはDKIMによる認証とドメインアライメントという基本的な仕組みは維持されています。
8.Microsoftは大量送信者にDMARCを求めていますか？
はい。
Microsoftは、Outlook.com、Hotmail.com、Live.com宛てに1日5,000通を超えるメールを送信するドメインへ、SPF、DKIM、DMARCの設定を求めています。
要件に準拠していない送信者は、メールのフィルタリングやブロックなどの影響を受ける可能性があります。