DMARC — ドメインベースのメッセージ認証、レポーティング、コンフォーマンス
このRFCが存在する理由
SPFとDKIMは強力ですが、それぞれ重大なギャップがあります。SPFはエンベロープ送信者ドメインを検証しますが、ユーザーには見えません。DKIMは署名者が選択したドメイン(ESP のドメインである可能性があります)を検証しますが、ユーザーが実際に読むFrom:ヘッダーのスプーフィングを防ぐことはできません。どちらか一方だけでは、攻撃者がFrom:ヘッダーをスプーフィングするのを防ぐことはできません。
DMARCは2つの概念を導入することでこのギャップを埋めます:
-
識別子の整合: SPFまたはDKIMの少なくとも1つが合格し、かつその認証ドメインが
From:ヘッダードメインと整合する必要があります。 -
ドメイン所有者ポリシー: ドメイン所有者は、整合に失敗したときに受信者が何をすべきかを宣言するDNSレコードを公開します。監視(
p=none)、隔離(p=quarantine)、または拒否(p=reject)です。
DMARCは集約レポート機構も定義し、ドメイン所有者がインターネット全体でどのようにドメインが使用(および悪用)されているかを示す日次XMLレポートを受け取ることができます。
仕組み
DMARC評価フロー
From: user@example.comのメッセージが到着します。- 受信者はエンベロープ送信者ドメインに対してSPFをチェックします。SPFが合格し、エンベロープドメインが
example.com(または整合モードに応じてサブドメイン)と一致する場合、SPFは「整合」です。 - 受信者はDKIMをチェックします。有効な署名に
d=example.com(またはサブドメイン)がある場合、DKIMは「整合」です。 - SPFまたはDKIMの少なくとも1つが合格し、かつ整合している場合、DMARCは合格します。
- DMARCが失敗した場合、受信者は
_dmarc.example.comのポリシーをクエリして適用します。
DMARC DNSレコード
実際の整合
# エンベロープ: MAIL FROM:<bounce@mail.example.com>
# ヘッダー: From: sales@example.com
# DKIM署名: d=example.com
# SPFチェック:
SPFドメイン: mail.example.com (エンベロープから)
Fromドメイン: example.com
SPF整合(リラックス): mail.example.com <-> example.com = 合格(同じ組織ドメイン)
# DKIMチェック:
DKIM d= ドメイン: example.com
Fromドメイン: example.com
DKIM整合: example.com <-> example.com = 合格(完全一致)
DMARC結果: 合格(SPFとDKIM両方が整合)
主要な技術的詳細
ポリシータグ
| タグ | 値 | 説明 |
|---|---|---|
v |
DMARC1 |
バージョン(必須、最初に置く必要があります) |
p |
none、quarantine、reject
|
ドメインのポリシー(必須) |
sp |
none、quarantine、reject
|
サブドメインのポリシー(pがデフォルト) |
rua |
mailto: URI(複数可) |
集約レポートの送信先(カンマ区切り) |
ruf |
mailto: URI(複数可) |
フォレンジック/失敗レポートの送信先 |
adkim |
r(リラックス)、s(ストリクト) |
DKIM整合モード。リラックスはサブドメインを許可します。 |
aspf |
r(リラックス)、s(ストリクト) |
SPF整合モード。リラックスはサブドメインを許可します。 |
pct |
0~100 | ポリシーを適用する失敗メールの割合(段階的なロールアウト用) |
fo |
0、1、d、s
|
失敗レポートオプション |
整合モード
リラックス整合(デフォルト、adkim=r / aspf=r): 認証ドメインとFrom:ドメインが同じ組織ドメインを共有します。例えば、mail.example.comはexample.comと整合します。
ストリクト整合(adkim=s / aspf=s): 認証ドメインはFrom:ドメインと完全に一致する必要があります。mail.example.comはexample.comと整合しません。
集約レポート(rua)
DMARCをサポートする受信者は、ruaアドレスに日次集約レポートをXML形式で送信します。これらのレポートには以下が含まれます:
- あなたのドメインを使用した送信IPアドレス
- 各ソースのSPFとDKIM合格/不合格結果
- 適用されたDMARCポリシーと処理(なし、隔離、拒否)
- ソースIPごとのメッセージ数
これらのレポートは、認可されていない送信者を発見し、誤った設定の正当な送信元を特定し、ポリシーをnoneからrejectに厳しくする前に信頼を構築するために非常に貴重です。
外部宛先検証
ruaまたはrufアドレスが別のドメイン(例えばrua=mailto:reports@analytics.com)にある場合、受信ドメインはそれを認可するDNSレコードを公開する必要があります:
このレコードがない場合、レポート送信者はDMARCレポートをサービス拒否ベクトルとして使用することから保護するため、外部アドレスにレポートを配信しません。
一般的な間違い
-
すぐに
p=rejectに進む: 最初にp=noneで監視することなく拒否ポリシーを導入すると、忘れられたソース(マーケティングプラットフォーム、CRMシステム、あなたに代わって送信するSaaSアプリ)からの正当なメールがサイレントに遮断される可能性があります。常にp=noneから開始し、レポートを分析し、整合の問題を修正してから、段階的にアップグレードしてください。 -
サブドメインポリシーを忘れる:
sp=がない場合、サブドメインはドメインのポリシーを継承します。p=rejectを設定しても、サブドメインが適切な認証なしにメールを送信している場合、これらのメッセージは拒否されます。sp=を使用してサブドメインポリシーを独立して制御してください。 -
ruaを設定していない: 集約レポートのないDMARCは手探りです。レポートはあなたのドメインとしてメールを送信している人と認証が機能しているかどうかを教えてくれます。常にruaを設定してください。 -
整合を誤解する: SPFとDKIMの合格があれば十分だと思うのは一般的な間違いです。また、
From:ヘッダードメインと整合する必要があります。ESPがbounce@esp.comをエンベロープ送信者として使用し、d=esp.comとしてDKIMで署名する場合、どちらもあなたのFrom:ヘッダーと整合しないため、DMARCは失敗します。 -
pct=0を「監視のみ」として使用する:pct=0は技術的には「失敗の0%にポリシーを適用する」ことを意味しますが、一部の受信者はそれを異なる方法で解釈します。監視用にはp=noneを使用し、pct=0をより厳しいポリシーと共に使用しないでください。 -
メーリングリストの破損: 従来のメーリングリストはエンベロープ送信者を書き直しますが
From:ヘッダーは保持し、SPF整合を破損し、時々DKIM(リストがメッセージを変更する場合)も破損します。これは既知の問題です。ARCはこれを解決するために作られました。
配信可能性への影響
-
一括送信者向けの必須: 2024年2月以降、Gmailは1日5,000件以上のメッセージを送信するドメインに、最低でもDMARCポリシー(
p=none)を持つことを要求しています。Yahooには同様の要件があります。これにより、DMARCは真摯な送信者にとって任意ではなくなります。 -
ブランド保護:
p=rejectポリシーは、攻撃者がフィッシングキャンペーンであなたのドメインをスプーフィングするのを防ぎます。これはあなたの顧客とあなたのドメインの評判を保護します。 - 受信トレイの配置改善: 強力なDMARCポリシー(隔離または拒否)を持つドメインは、認証の成熟度を示しています。多くの受信者はこれを評判スコアリングの要因として考慮します。
-
BIMI適格性: Brand Indicators for Message Identification(BIMI)は
p=quarantineまたはp=rejectのDMARCポリシーを必要とします。BIMIは対応するメールクライアントでメッセージの横にあなたのブランドロゴを表示します。 -
あなたのメールエコシステムへの可視性: 集約レポートはあなたのドメインとしてメールを送信しているすべてのIPを表示します。この可視性だけでも、
p=noneでもDMARCをデプロイする価値があります。