DMARCの疑問に、
お答えします

DMARC（Domain-based Message Authentication, Reporting & Conformance）は、SPFまたはDKIMのチェックが失敗したときに受信メールサーバーが取るべき動作を指示するメール認証プロトコルです。あなたのドメインから送信されたように見えるメールを攻撃者が送るのを防ぎ、ブランドと受信者をフィッシングやなりすまし（スプーフィング）から保護します。DMARCはRFC 7489で定義されています。

はい。あなたのドメインがメールを送信する場合も、送信しない場合でも、DMARCが必要です。DMARCがなければ、誰でもあなたのドメインになりすましてメールを送信できます。GoogleとYahooは現在、1日あたり5,000通以上を送信するドメインに対し、少なくともp=noneを要求しています。PCI DSS v4.0は、顧客対応ドメインにDMARCを求めています。メールを送信しないドメインは、なりすましを防ぐためにp=rejectを公開すべきです。

まず、ドメインにSPFとDKIMが設定されていることを確認してください。次に、_dmarc.yourdomain.com にp=noneとrua=レポートアドレスを含むDNS TXTレコードを公開します。集計レポートを少なくとも90日間監視し、すべての正当な送信元の認証を修正してから、段階的にp=quarantine、最終的にp=rejectへ移行します。レコードを検証するには、DMARC Checkerをご利用ください。

p=noneでDMARCレコードを公開するのは数分で済みます。p=rejectで完全な適用に到達するには、通常9〜18か月かかります。各フェーズ（none、quarantine、reject）では、すべての正当な送信元を特定してその認証を修正するために、最低90日間の監視が必要です。サードパーティの送信元が少ない組織は、より早く進められる場合があります。

DMARCレコードは、_dmarc.yourdomain.com に公開されるDNS TXTレコードです。一般的なレコードは次のようになります：v=DMARC1; p=reject; rua=mailto:dmarc@example.com; ruf=mailto:forensic@example.com; adkim=r; aspf=r。v=とp=のタグは必須で、その他はすべて任意ですが推奨されます。すべてのタグの詳細な解説については、DMARCとはのページをご覧ください。

SPFは、送信サーバーがドメインのDNSレコードによって許可されているかを検証します。エンベロープ送信者（Return-Path）をチェックします。DKIMは暗号署名を付加し、メッセージが転送中に改ざんされていないことを証明します。DMARCはこれらを結び付けます。SPFまたはDKIMのいずれかが合格し、かつ表示されるFromヘッダーのドメインと整合（アライメント）することを要求し、認証が失敗したときに受信者が取るべき動作を指示します。レコードをテストするには、SPF CheckerとDKIM Lookupをご利用ください。

いいえ。ドメインは _dmarc.domain.com に正確に1つのDMARC TXTレコードを持たなければなりません。複数のDMARCレコードはPermErrorを引き起こし、受信者はそれらすべてを無視します。複数のアドレスにレポートを送る必要がある場合は、rua=タグにカンマ区切りで列挙してください：rua=mailto:dmarc@example.com,mailto:reports@example.com。

DMARCアライメントとは、表示されるFromヘッダーのドメインが、SPFまたはDKIMに合格したドメインと一致しなければならないことを意味します。リラックス（relaxed）アライメント（デフォルト）はサブドメインの一致を許可し、mail.example.com は example.com と整合します。ストリクト（strict）アライメントはドメインの完全一致を要求します。アライメントは、攻撃者が自分のドメインでSPFを通しつつFromヘッダーであなたのドメインをなりすますことを防ぎます。

p=noneポリシーは、DMARCに失敗したメッセージに対して受信サーバーが適用措置を取らないよう指示します。認証結果にかかわらず、メッセージは通常どおり配信されます。目的は監視です。受信者は引き続き集計レポートを送信し、ドメイン所有者にすべての送信元の可視性を提供します。適用に移る前に、必ずp=noneから始めてください。

p=quarantineポリシーは、失敗したメッセージをスパムまたは迷惑メールフォルダに振り分けるよう受信サーバーに指示します。メッセージは依然として存在し、受信者は見つけることができますが、疑わしいものとして印が付けられます。これはp=none（監視）とp=reject（完全なブロック）の間にある中間の適用ステップです。完全な進行については、DMARCポリシーのガイドをご覧ください。

p=rejectポリシーは、失敗したメッセージをSMTPレベルで拒否するよう受信サーバーに指示します。受信者はメッセージを一切目にせず、送信サーバーはバウンスを受け取ります。これは最も強力なDMARC保護であり、すべてのドメインにとって最終的な目標です。p=rejectに到達するには、まずp=noneとp=quarantineの各フェーズを通じた徹底的な監視が必要です。

pct=タグは、失敗したメッセージのうちどの割合に適用措置を行うかを制御します。pct=25では、失敗したメッセージの25%だけが隔離または拒否され、残りはp=noneとして扱われます。これにより適用を段階的に展開できます。pct=10から始め、数週間かけて25、50、そして100へと増やしてください。pct=を省略した場合、デフォルトは100です。

集計レポート（RUA）は、あなたのドメインから送信されたと主張するすべてのメッセージの認証結果を要約し、受信メールサーバーが毎日送信するXMLファイルです。どのIPアドレスがメールを送信したか、SPFとDKIMが合格したか、どのポリシーが適用されたかを示します。集計レポートはDMARC監視の基盤であり、適用の判断に必要なデータを提供します。DMARC Reportは、これらのXMLファイルを視覚的なダッシュボードに変換します。

フォレンジックレポート（RUF）は、メッセージごとの失敗の詳細を提供します。認証に失敗した具体的なメール、送信者のIP、From/Return-Pathの不一致、どのメカニズムが失敗したかなどです。フォレンジックレポートは、進行中のなりすまし試行を調査するのに役立ちますが、集計レポートほど受信者に広くサポートされていません。プライバシー上の懸念から、一部の受信者はRUFレポートをまったく送信しません。

生のDMARC集計レポートは、手作業では読みにくいXMLファイルです。DMARC ReportのようなDMARCレポートアナライザーを使用して、XMLを送信者の認証状況、アライメント結果、ポリシー措置を示す視覚的なダッシュボードに変換してください。このツールは、送信者をベンダー別（Google Workspace、Microsoft 365、SendGridなど）に自動分類し、対応が必要な失敗を強調表示します。

よくある原因：DMARCレコードにrua=タグが含まれていない、rua=のメールアドレスにタイプミスがある、またはレポートを発生させるのに十分なメール量が送信されていない（受信者は通常、レポートを毎日まとめます）。rua=が認証対象とは別のドメインを指している場合は、外部検証用のDNSレコードが必要です。DMARCレコードを公開してからレポートが届き始めるまで、24〜72時間見込んでください。レコードの構文を検証するには、DMARC Checkerをご利用ください。

ほとんどの受信者は、通常UTCの深夜に、24時間ごとに1回集計レポートを送信します。GoogleやMicrosoftのような一部の大規模受信者は、1日に複数のレポートを送信することがあります。受け取るレポートの量は、あなたのドメインからのメールを処理する受信者の数によって異なります。人気のあるドメインでは、多数の受信者から1日に数百のレポートを受け取ることがあります。

p=noneからp=rejectへの道のりは、通常9〜18か月かかります。各フェーズには最低90日が必要です。監視と送信元の特定のためのp=none、中間的な適用のためのp=quarantine、そして完全な保護のためのp=rejectです。サードパーティの送信元が少なく、メールインフラがシンプルな組織はより早く進められますが、適用を急ぐと正当なメールがブロックされます。

正当な送信者がp=quarantineでDMARCに失敗すると、そのメールはスパムに入ります。p=rejectでは完全にブロックされます。これを修正するには：集計レポートを確認して失敗している送信者を特定し、そのSPF includeまたはDKIM署名を設定し、アライメントが合格することを確認してください。pct=タグを使って適用を段階的に展開することで、すべてのメールに影響する前にこうした問題を検出できます。

隔離は意味のある保護を提供します。なりすましメッセージは受信トレイから消えます。しかし、配信を完全に防ぐため、p=rejectが推奨される目標です。一部のコンプライアンスフレームワーク（PCI DSS v4.0、連邦機関向けのCISA BOD 18-01）は、明示的にp=rejectを要求しています。さらに、p=rejectは、対応するメールクライアントでブランドロゴを表示するBIMIの資格を得るために必要です。

はい。従来のメール転送は、転送サーバーのIPが元のドメインのSPFレコードに含まれていないため、SPFアライメントを壊す可能性があります。DKIMは署名がメッセージ自体に付加されているため、通常は転送でも維持されます。このため、受信者がメールを転送するドメインでは、DKIMアライメントが特に重要です。ARC（Authenticated Received Chain）はこの問題に対処するために設計された新しいプロトコルですが、その普及はまだ拡大中です。

DMARCは、ますます多くの標準や組織によって要求されています。GoogleとYahooは、一括送信者（1日5,000通以上）に少なくともp=noneを要求します。PCI DSS v4.0は、顧客とのコミュニケーションに使用されるドメインにDMARCを求めています（2025年3月施行）。CISA BOD 18-01は、米国連邦機関にp=rejectを義務付けています。多くのサイバー保険契約や調達プロセスでも、現在DMARCの適用が要求されています。

2024年2月以降、GoogleとYahooは、すべての一括送信者（Gmail/Yahooユーザーへ1日5,000通以上）に対し、有効なrua=アドレスを備えた少なくともp=noneのDMARCポリシーを要求しています。さらに、送信者はSPFとDKIMを適切に設定し、マーケティングメールにワンクリック登録解除ヘッダーを含め、スパム苦情率を0.3%未満に維持する必要があります。非準拠の送信者は、配信のスロットリングや拒否を経験します。

はい。PCI DSS v4.0（2025年3月施行）は、カード会員データを処理する組織に対し、顧客対応のコミュニケーションに使用されるドメインでDMARCを実装するよう要求します。具体的には、要件5.4.1で、フィッシング対策メカニズムにドメインベースの認証（DMARC、SPF、DKIM）を含める必要があると定めています。ほとんどのPCI評価者は、コンプライアンスのためにp=rejectまたはp=quarantineを期待します。

サイバーセキュリティ・インフラストラクチャセキュリティ庁（CISA）が発行した拘束的運用指令（Binding Operational Directive）18-01は、米国連邦行政府のすべての機関にp=rejectでのDMARC実装を要求しています。この指令は政府部門におけるDMARCの採用を大幅に増加させ、他の組織や業界からもベストプラクティスの基準としてしばしば引用されています。

DMARCは、医療ドメイン名のなりすましを防ぐことでHIPAAコンプライアンスを支援し、保護対象保健情報（PHI）の漏洩につながりうるフィッシング攻撃のリスクを低減します。HIPAAはDMARCを明示的に指名していませんが、Security Ruleは電子PHIを保護するための安全対策を要求しており、メール認証は合理的かつ適切な措置と見なされます。フォレンジックレポート（RUF）はメッセージ内容を含む場合があるため、医療機関は集計レポート（RUA）のみを使用するか、フォレンジックレポートがHIPAAに準拠して取り扱われるようにすべきである点に注意してください。