DMARC

1. DMARC Alignment (Fromアドレス詐称検出)

このセクションのポイント: DMARC Alignmentは、SPFまたはDKIMで認証されたドメインと、メールヘッダのFromドメインが一致しているかを確認するプロセスです。これにより、第三者による正当なサーバ経由のなりすまし（SPF Bypass等）を防ぎます。

DMARC Alignmentチェックとは？

SPFは、送信を許可したMTAのリストをDNSから取得し、送信元の正当性を検証します。
しかし、共用MTA環境ではSPFが突破されやすいという課題があります。
また仕様上の問題もあり、SPF Bypass攻撃では、SPFの認証で参照するドメインがHeaderFromとHELO/EHLOの2つを選べることを利用し、Header Fromとは異なるドメインから送信しつつ、HELO/EHLO検証でSPFで合格させる手法が用いられます。

一方、DKIMは、各MTAがメール本文に署名を付与して改竄防止を実現しますが、署名ドメイン（d=タグ）とHeader Fromの一致を検証しないため、攻撃者は自身のドメインで署名しながらHeader Fromを偽装することが可能です。

そこでDMARCは、SPFやDKIMの検証結果に加え、Fromアドレスと認証済み識別子との一致（Alignment）をチェックすることで、なりすましメールを検出します。
いずれかの検証が合格し、かつAlignmentが一致すれば、そのメールは正当と判断されます。

DMARC Alignment一致

Header Fromのドメインと、メールヘッダ内の検証済みドメインが一致している状態です。
(SPFベースのDMARC Alignmentチェックで使うEnvelope FromはSMTPコマンドで指定されるため、ユーザーが直接確認できることは少ないですが、ここでは説明の便宜上、Return-Pathとして表示される値を参照しています。)

DMARC Alignment不一致

Header Fromのドメインと、メールヘッダ内の検証済みドメインが一致しない状態です。

SPF、DKIMそれぞれを基準としたDMARC Alignmentチェック

DMARCは単にSPFやDKIMの検証結果を利用するだけでなく、RFC7489 Section 6.6.2に基づいた処理プロセスを実施します。
以下の手順で、DKIMやSPFの検証結果がDMARC評価に反映されます。

1. RFC5322.Fromドメインをメールから抽出する。
2. DNSでDMARCポリシーレコードを問い合わせ、存在すれば評価を続行し、無ければ終了する。
3. DKIM署名検証チェックを実施し、各署名の"d="タグの値を取得する。
4. SPF検証チェックを実施し、使用されたドメイン名を記録する。
5. 認証済み識別子とRFC5322.Fromドメインの一致（Identifier Alignment）を確認する。
6. ポリシーに基づき、認証失敗メールの処理を決定する。

SPFまたはDKIMのいずれかが合格し、さらにAlignmentが一致すればメールは正当と判断されます。
転送メールでは、多くの場合、送信MTAが最初に送信したMTAと違うのでSPFが失敗しますが、DKIMが合格すれば問題ありません。
転送メール検証の難点には、ARC仕様で対応できます。

DKIMを基準としたDMARC Alignmentチェック

メールヘッダーのFromに記載されたドメインと、DKIM署名内のd=タグに記載されたドメインが一致する署名が1つ以上存在するかどうかを検証します。

SPFを基準としたDMARC Alignmentチェック

メールヘッダーのFromに記載されたドメインと、SMTPセッション中に指定されるEnvelope From（通常、Return-Pathヘッダーに転記される）のドメインが一致するかどうかを検証します。
(Envelope FromはSMTPコマンドで指定されるため、ユーザーが直接確認できることは少ないですが、ここでは説明の便宜上、Return-Pathとして表示される値を参照しています。)

SPFベースのDMARC AlignmentチェックにおけるEnvelope FromとReturn-Pathの関係

SPF検証では、SMTPセッション中に送信者が提示する情報として、HELO/EHLOで提示されたホスト名や、MAIL FROMコマンドで指定されるEnvelope Fromのドメインが利用されます。
DMARCのSPF Alignmentチェックでは、SPF認証に使用されたIdentifier、通常はMAIL FROMに対応するEnvelope Fromのドメインと、メールヘッダーのFromのドメインとの整合性（Alignment）が評価されます。
なお、Return-Pathは通常、受信サーバーでEnvelope Fromの値に基づいて生成されるため、多くの場合、実際のEnvelope Fromと同一のドメイン情報が記録されます。しかし、転送処理でのSRSや受信サーバー独自の処理により、これらの値が異なるケースも存在します。

Envelope FromはSMTPセッション中にMAIL FROMコマンドで指定される送信元アドレスであり、バウンス通知の宛先として利用されます。
一方、Return-Pathは通常、受信サーバーがEnvelope Fromの値に基づいて自動生成するヘッダーで、実際のEnvelope Fromの情報を反映しています。
そのため、Return-Pathを確認することで、間接的にEnvelope Fromの値を把握できる場合が多いですが、SRSなどによる転送処理が行われると、Return-Pathのドメインが変更されることがあります。

また、MAIL FROMが空の場合、SPF検証ではHELO/EHLO情報から合成されたアドレスが使用され、通常はReturn-Pathも空となるため、バウンスメールなど特定のケースでこの挙動が見受けられます。

2. ドメイン所有者からの処理の明示的指示

このセクションのポイント: 送信ドメイン側が受信側に「認証失敗時の扱い（何もしない・隔離・拒否）」を指示できます。最終的には p=reject を目指すことで、なりすましメールを完全に排除可能です。

従来、SPFやDKIMでは受信側メールサーバが検証結果に基づいてメールの処理（受信、隔離、拒否）を決定していました。
しかしDMARCでは、ドメイン所有者がメール処理の方法を明示的に指定できます。

DMARCはMTAやMDAと連携し、SPF・DKIM検証結果に基づいて以下の処理を指示します。

p=none

認証失敗や不適合メールに対して既存のメール処理を変更せず、フィードバックのみを行います。

p=quarantine

認証失敗メールを隔離し、迷惑メールフォルダへ振り分けるよう指示します。

p=reject

認証失敗メールの受信自体を拒否するよう指示します。

これらのポリシーは、DNSのTXTレコードとして公開され、受信側サーバが参照します。

目標とすべきポリシーはreject

最終的に設定目標とすべきポリシーはp=rejectです。
p=rejectにすると、SMTPコネクションを張っている時点で、DMARCに適合していないと、コネクションを切断されてしまいます。
結果として、迷惑メールボックスにすら入りません。

p=quarantineをまずは適用することが推奨されているものの、p=quarantineでは、迷惑メールボックスに入ったことを送信側が検知できません。
そこで、弊社では、最初からp=rejectにすることをお勧めしています。
そうすれば、送信時にDMARCで合格できなくて送信に失敗したことが即座に判明するからです。

また、p=quarantineでは、なりすましメールが減らないことも、過去の分析データから判明しています。
p=rejectにすると、大体2～3週間ほどで、DMARCのコンプライアンス率は99%を超えます。
なりすましメールを送っている攻撃者も、送っても無駄なドメインについては、送信しなくなるからです。

攻撃者がp=rejectにしたドメインについて、引き続き攻撃する場合には、全く関係の無いドメインを使って、SPF/DKIM/DMARCを合格させてメールを送ってきます。
メールクライアントの多くがアドレスを表示せず、名前だけを表示する点を利用して、ヘッダーFromのアドレスも関係のないドメインを使い、なりすましメールを送ります。
これについては、DMARCでは防御できないため、BIMIを実装することで視覚的に防御することになります。

p=noneについての補足

p=noneは「全てのメールをそのまま受信する」指定ではなく、DMARC未設定時の従来の処理を変更しないことを示します。
従って、SPF、DKIM単体検証の時のように、受信MTA側の処理判断に従います。
詳細はRFC7489をご参照ください。

To enable Domain Owners to receive DMARC feedback without impacting existing mail processing, discovered policies of "p=none" SHOULD NOT modify existing mail disposition processing.

ドメイン所有者が既存のメール処理に影響を与えずにDMARCフィードバックを受け取るため、"p=none"のポリシーはメール処理を変更すべきではありません。

尚、現在、p=noneのドメイン名を利用して、なりすましメールを送る攻撃が多発しているので、できるだけ早期にp=rejectにすることをお勧めします。

受信側MTAによる送信側ポリシーの上書き

DMARCにおいては、送信ドメイン側のポリシーを、受信側が上書きできます。
これにより、信頼できる送信者のポリシーが不十分な場合や、特定の状況に応じた緩和策が適用可能です。
上書き理由は、RUAレポートの中に明示的に記載される必要があります。

上書き理由については、以下のものがあります。

forwarded

メッセージは既知の転送サービス（forwarder）を経由して中継された、またはローカルのヒューリスティック（推定ロジック）により転送された可能性が高いと判断された。
この場合、認証（authentication）が通ることは期待されていません。

sampled_out

DMARCポリシーの pct 設定により、ポリシー適用対象からサンプリングで外された。
例えば、p=quarantine pct=10で設定している場合に、都度、抽選が行われて、ポリシー適用の対象にならなかった。)

trusted_forwarder

メッセージの認証失敗は、受信側で管理されている「既知かつ信頼できる転送者（trusted forwarder）」のリストに結び付く他の証拠によって予期されたものである。

mailing_list

ローカルのヒューリスティックにより、そのメッセージはメーリングリスト経由で届いたと判断された。
そのため、元のメッセージの認証が成功することは期待されない。

local_policy

メール受信側のローカルポリシーにより、そのメッセージはドメイン所有者が要求するポリシー適用（処理）対象から除外された。

other

上記の分類に該当しない、何らかのポリシー例外が発生した。
詳細は PolicyOverrideReason の "comment" フィールドに記載されます。

3. DMARCレポート

このセクションのポイント: 自社ドメインが世界中でどのように使われているか（正規・不正問わず）を可視化するため、RUAレポート（統計）の受信と分析は必須です。

DMARCレポートは、自社ドメイン名義で受信されたメールの統計情報を、受信MTAから定期的（通常1日1回）に送信される監査レポートです。
ここで重要なのは、送信されたメールではなく「受信されたメール」の情報である点です。
なりすましメールは自社のメールサーバから送信されるケースが少ないため、受信側のレポートがセキュリティ監視に非常に有用です。

RUAレポート・RUFレポート

DMARCレポートには、以下の2種類があります。

RUA

"Reporting URI(s) for aggregate data" の略。
受信メールのSPF、DKIM、DMARCの検証結果の統計情報がXML形式で送信されます。
メールの詳細データは含まれず、個人情報も一切入っていません。

RUF

"Reporting URI(s) for failure data" の略。
認証に失敗したメールのヘッダ情報がXML形式で送信されます。
宛先、件名、Fromアドレスなどの詳細が含まれます。
現在、殆どのメール配信プラットフォームが送って来ないです。

RUAレポート確認の重要性

p=reject設定後に「これで安全」と考えがちですが、RUAレポートを継続的に確認することで以下の効果が期待できます。

継続的な監視と改善

なりすましメールによる攻撃は、必ず、Webサイトとセットで行われます。
なりすましメールがどの地域から送信されているのかを把握し、Webサイト側のsecureログやaccessログの失敗の箇所を確認して突き合わせることで、攻撃候補としてプロファイリングがされているかどうかを確認することが可能です。

新たな脅威への対応

攻撃手法の変化に応じた迅速な対策が可能になります。
例えば、2025年は、国内の多くの企業で、Microsoft365のExchange Onlineが持つDirect Sendという機能が悪用される事例が多発しました。

誤設定や不正アクセスの検出

システムの設定ミスや不正アクセスの兆候を早期に把握できます。

セキュリティポリシーの遵守

組織のセキュリティ方針に沿った運用が維持されているか確認できます。

コンプライアンス・レポートの元データ

定量的なデータとして、コンプライアンス報告の基礎資料となります。

サイバーデューデリジェンス

M&Aなどの際、セキュリティリスク評価の根拠データとして利用できます。

DNSの遅延に伴うメール配信率の最適化

SPF/DKIM/DMARCは、DNSと密接な関係があり、DNSの遅延が、Temperrorを発生させます。
SPFは仕様上20秒タイムアウトが明記されていますが、DKIMは仕様上タイムアウトが制定されていません。
従って、受信側MTAがタイムアウト値を決めることが可能です。
RUAレポートでエラーを確認して、DNSのパフォーマンス対策を講じるための重要なデータとなります。

このように、DMARCの運用にはp=reject設定後もRUAレポートの継続的な確認が不可欠です。

4. DMARCの構文

このセクションのポイント: DMARCポリシーはDNSのTXTレコードとして定義されます。必須タグ（v, p）とオプションタグ（rua, ruf, pct等）を組み合わせることで、柔軟な制御が可能です。

DMARCは、前述の機能を実現するために、DNSにTXTレコードとして公開されるポリシーです。
ポリシーは以下のタグと値のペアで定義されます。

v=DMARC1

DMARCのバージョンを示します。現在のバージョンは "DMARC1" です。

p=none|quarantine|reject

ポリシーを示します。
noneはモニタリングのみ、quarantineは隔離、rejectは拒否を意味します。

sp=none|quarantine|reject（オプション）

サブドメインに適用するポリシーを指定します。指定がない場合、APEXドメインのポリシーが適用されます。

rua=mailto:address（オプション）

アグリゲートレポート送信用のメールアドレスを指定します。通常、24時間ごとに送信されます。

ruf=mailto:address（オプション）

フォレンジックレポート送信用のメールアドレスを指定します。認証失敗メールの詳細情報が含まれます。

pct=0-100（オプション）

DMARCポリシーを適用するメールトラフィックの割合を示します。
例：pct=50なら全体の50%のメールに適用（指定がない場合は100%）。

adkim=r|s（オプション）

DKIMのアラインメントモードを指定します。
rはリラックス（サブドメインも含む）、sは厳格（一致のみ）です（デフォルトはリラックス）。

aspf=r|s（オプション）

SPFのアラインメントモードを指定します。
rはリラックス、sは厳格です（デフォルトはリラックス）。

例えば、以下のようなDMARCレコードが考えられます。

v=DMARC1; p=reject; sp=quarantine; rua=mailto:dmarc_agg@example.com; ruf=mailto:dmarc_for@example.com; adkim=s; aspf=s; pct=100;

この設定は、APEXドメインのメールに対しては認証失敗時に拒否、サブドメインでは隔離、レポートは指定アドレスへ送信し、DKIMおよびSPFは厳格な一致を要求、かつ全メールに適用されることを示します。

5. DMARCの限界

DMARCはメールセキュリティを向上させるための有用な技術ですが、いくつかの限界も存在します。

認証ステータスの確認

メールクライアントがDMARC検証ステータスを明示的に表示しない場合、詳細はメールヘッダの確認が必要です。

自社管理外のドメインからの送信によるなりすまし

DMARCは自社で管理しているドメインについての認証を行います。
攻撃者が自社で管理していないドメインを使い、適切なSPF・DKIM・DMARC設定を行いメールを送信した場合、DMARC検証は合格してしまいます。
これは、多くのメールソフトで、メールの送信元の表示で名前だけ表示して、メールアドレスを表示しない仕様を利用した攻撃になります。

DMARCの限界を超えるためのBIMI

DMARCにも限界があるため、追加の信頼性向上策として、BIMI (Brand Indicators for Message Identification) が登場しました。

FAQ

Q1. DMARCは、SPFとDKIMの認証の合否を使うだけですよね？

A. いいえ、DMARCは、SPFとDKIMの認証が合格していると、ヘッダーFromの詐称を防ぐために、Alignmentチェックという検査を行います。
以下のいずれかで一致すれば、DMARCは合格となります。

1. DKIM署名ドメインとヘッダーFromのドメインが一致しているものがあるか？(DKIM署名は複数存在しうるため)
2. EnvelopeFromとヘッダーFromのドメインが一致しているか？

Q2. DMARCで指定したポリシーは絶対なんですよね？

A. いいえ、受信MTAは、送信側のポリシーについて上書きする事が可能です。
上書き理由は、DMARCのRUAレポートの中に明示的に記載されます。

Q3. RUAレポートやRUFレポートの受信が面倒なので、外していいですよね？

それは、攻撃者に対して、自社がログを確認しない会社だと教えているようなものです。
2025年に攻撃を受けて事業が停止した企業は、まさにこの状態でした。
RUAやRUFレポートは、必ず、受信するように設定しましょう。
また、攻撃者は、人の特性を巧みに利用します。
自社ドメインのメールだけで受信している場合には、攻撃者はDMARCレポートは解析していないだろうと推測してきます。
（理由は、皆さん、お分かりですよね。面倒だからです！）
商用のDMARCレポート分析ツールのアドレスで受信している場合には、きちんと分析しているという、攻撃者に対するアピールになります。

Q4. DMARCに合格しているのに、メールが届きません！

メールのフィルタリングは、多くの場合、多層フィルタが実装されています。
DMARCに合格しているだけでは、メールの到達（Deliverability）は保証されません。
DMARCは「本人確認」に過ぎず、「通行手形」ではないからです。
まずは、IPレピュテーションやコンテンツフィルタで引っかかっていないかを確認しましょう。

Q5. DMARCでp=rejectに設定すると、設定不備のメールが届かなかったり、メーリングリストが届かなくなりますよね？

早とちりをしないように！
まず、DMARCのp=noneだからといって、受信していい、という意味ではありません。
送信ドメインとしてはポリシーの指定をせず、これまでの受信側の処理のままで良いです、という意味です。
受信側では、従来どおり、SPFやDKIMなどを使った判定と受信処理が行われます。
p=noneであっても、SPFやDKIMに不備があると、受信しないメールサービスは多いですし、更に受信の敷居を上げてきています。
メーリングリストについては、ARCの実装が必要で、Gmail/Google Workspaece、Microsoft365は、自社ドメインのDKIMを設定していれば、自動でARCが有効になります。
また、Google Groupsは、送信元ドメインがp=rejectであれば、ヘッダFromとReturn-Pathをグループのアドレスに書き換えてくれます。
p=rejectは、自社ドメインの信頼の証であり、評価を上げる効果があるのです。

Q6. DMARCでp=rejectにしても、なりすましメールは無くならないですよね？

はい、無くなりはしません。
しかし、導入した御社については、確実になりすましメールが激減します。
DMARCの導入やp=reject化は、世界からなりすましメールを撲滅するため、世界を救うためにやるわけではありません。
効果が及ぶのは、自社ドメインのみです。
そして、p=rejectにすれば、2～3週間程度で、全体の1%未満にまで、なりすましメールが減ります。
これは、p=rejectにしたドメインにおいて、共通の事象です。
世界を救うことはできませんが、自社と自社のお客様、取引先を守るには十分ですよね。