DMARC（Domain-based Message Authentication, Reporting and Conformance）レコードは、DNSベースのポリシーとして機能し、受信メールサーバーにあなたのドメインからのメールの処理方法を指示します。2026年に堅牢なメール認証プロトコルを実装する組織にとって、正確なDMARCレコード構文の理解は極めて重要です。
DMARCレコードは、セミコロンで区切られたタグ-値ペアで構成され、特定のDNSロケーション_dmarc.yourdomain.comにTXTレコードとして公開されます。各コンポーネントは、ポリシー実施からフォレンジック報告設定まで、認証チェーンにおいて独自の機能を持っています。
I. DMARCレコードDNS構造概要
基本構文形式
DMARCレコードは、特定の順序要件を持つ標準化されたタグ=値形式に従います：
v=DMARC1; p=policy; rua=mailto:[email protected]; ruf=mailto:[email protected]; sp=subdomain_policy; pct=percentage; adkim=alignment; aspf=alignment; rf=format; ri=interval; fo=options必須タグと任意タグ
必須タグ：
v（バージョン）p（ポリシー）
任意タグ：
rua（集計レポート）ruf（フォレンジックレポート）sp（サブドメインポリシー）pct（パーセンテージ）adkim（DKIM整合性）aspf（SPF整合性）rf（レポート形式）ri（レポート間隔）fo（失敗オプション）
II. バージョンタグ（v）
構文
v=DMARC1バージョンタグは常にDMARCレコードの最初のコンポーネントである必要があり、現在はDMARC1という1つの値のみをサポートしています。これは、受信メールサーバーに対してレコードがDMARCポリシーであることを識別します。
例
v=DMARC1; p=none
v=DMARC1; p=quarantine; rua=mailto:[email protected]エッジケース
- バージョンタグが欠如するとレコード全体が無効になる
- バージョンタグが最初の位置以外に現れると解析エラーが発生する
DMARC1以外の値はレコード拒否を引き起こす
III. ポリシータグ（p）
構文
p=none|quarantine|rejectポリシータグは、DMARC認証チェックに失敗したメールを受信サーバーがどう処理すべきかを定義します。
ポリシー値の説明
none： 監視モード – 失敗したメッセージに対してアクションなし
v=DMARC1; p=none; rua=mailto:[email protected]quarantine： 失敗したメッセージをスパム/迷惑メールフォルダに配信
v=DMARC1; p=quarantine; pct=25; rua=mailto:[email protected]reject： 失敗したメッセージをSMTPレベルで完全にブロック
v=DMARC1; p=reject; rua=mailto:[email protected]エッジケース
- ポリシー実施は受信側の実装に依存する
- 一部の受信者は評判上の理由でquarantineをrejectとして扱う場合がある
- ポリシーの段階的展開パターンに従うべき（none → quarantine → reject）
IV. 集計レポートURI（rua）
構文
rua=mailto:[email protected],mailto:[email protected]認証統計を含むXML集計レポートを受信するメールアドレスを指定します。
設定例
単一受信者：
rua=mailto:[email protected]複数受信者：
rua=mailto:[email protected],mailto:[email protected]外部ドメインレポート：
rua=mailto:[email protected]エッジケース
- 外部ドメイン受信者にはDNS認可レコードが必要
- 多くの受信者によってレポートが日単位で生成される（24時間サイクル）
- ruaタグが欠如するとDMARCパフォーマンスの可視性が失われる
- 一部の受信者はレポート送信先にサイズ制限を課す
V. フォレンジックレポートURI（ruf）
構文
ruf=mailto:[email protected]個別認証失敗の詳細フォレンジックレポートの受信者を定義します。
例
ruf=mailto:[email protected]
v=DMARC1; p=quarantine; ruf=mailto:[email protected],mailto:[email protected]エッジケース
- プライバシーの懸念により、多くの受信者がフォレンジックレポートを送信しなくなっている
- フォレンジックレポートには完全なメッセージヘッダーと潜在的に機密データが含まれる
- 外部ドメイン受信者には明示的なDNS認可が必要
- メールトラフィックが多いドメインでは量が圧倒的になる可能性がある
VI. サブドメインポリシー（sp）
構文
sp=none|quarantine|rejectサブドメインレベルで明示的なDMARCレコードが存在しない場合のサブドメインのポリシー継承を確立します。
設定例
より厳しいサブドメインポリシー：
v=DMARC1; p=none; sp=quarantine; rua=mailto:[email protected]一致するポリシー：
v=DMARC1; p=reject; sp=reject; rua=mailto:[email protected]エッジケース
- サブドメイン固有のDMARCレコードがsp設定を上書きする
- spが存在しない場合、デフォルトの動作は親ドメインポリシーをサブドメインに適用する
- 組織のサブドメインは異なるポリシーアプローチが必要な場合がある
VII. パーセンテージタグ（pct）
構文
pct=1-100DMARCポリシー実施の対象となる失敗メッセージの割合を制御します。
例
段階的展開：
v=DMARC1; p=quarantine; pct=10; rua=mailto:[email protected]完全実施（デフォルト）：
v=DMARC1; p=reject; pct=100; rua=mailto:[email protected]エッジケース
- pctタグが省略された場合のデフォルト値は100
- 段階的ポリシー展開とテストに有用
- ランダムサンプリングは一貫性のないユーザー体験を生み出す可能性がある
- すべての受信者がパーセンテージ仕様を遵守するわけではない
VIII. DKIM整合性モード（adkim）
構文
adkim=r|sDKIM署名ドメインとFromヘッダードメイン間の整合性要件を定義します。
整合性モード
緩和（r）- デフォルト：
v=DMARC1; p=quarantine; adkim=r; rua=mailto:[email protected]- 組織ドメイン整合性を許可（subdomain.example.comがexample.comと整合）
厳格（s）：
v=DMARC1; p=quarantine; adkim=s; rua=mailto:[email protected]- 正確なドメイン一致が必要
エッジケース
- 緩和整合性は正当なサブドメインメールサービスに対応
- 厳格整合性はサブドメインスプーフィングを防ぐが、正当なメールフローを阻害する可能性がある
- 複数のDKIM署名は整合性について独立して評価される
IX. SPF整合性モード（aspf）
構文
aspf=r|sSPF Return-PathドメインとFromヘッダードメイン間の整合性要件を指定します。
例
緩和SPF整合性：
v=DMARC1; p=none; aspf=r; adkim=s; rua=mailto:[email protected]厳格SPF整合性：
v=DMARC1; p=quarantine; aspf=s; rua=mailto:[email protected]エッジケース
- 転送シナリオはモードに関係なくSPF整合性を破ることが多い
- サードパーティメールサービスは慎重なReturn-Path設定が必要
- 緩和モードは組織ドメイン構造に対応
X. レポート形式（rf）
構文
rf=afrf|iodefフォレンジックレポートの形式設定を指定します。
形式オプション
認証失敗レポート形式（afrf）- デフォルト：
v=DMARC1; p=none; rf=afrf; ruf=mailto:[email protected]インシデントオブジェクト記述交換形式（iodef）：
v=DMARC1; p=none; rf=iodef; ruf=mailto:[email protected]エッジケース
- 多くの受信者はrf仕様に関係なくafrfをデフォルトとする
- iodef形式は実際にはほとんど実装されていない
- 形式設定はレポートシステムによって無視される場合がある
XI. レポート間隔（ri）
構文
ri=seconds集計レポート生成の特定間隔を要求します。
例
日次レポート（86400秒）：
v=DMARC1; p=none; ri=86400; rua=mailto:[email protected]週次レポート（604800秒）：
v=DMARC1; p=none; ri=604800; rua=mailto:[email protected]エッジケース
- 多くの受信者はri値に関係なく独自のスケジュールでレポートを生成する
- 標準的な実践は日次レポート生成
- より短い間隔は主要メールプロバイダーによってほとんど遵守されない
XII. 失敗オプション（fo）
構文
fo=0|1|d|sフォレンジックレポート生成をトリガーする条件を制御します。
失敗オプションの説明
fo=0（デフォルト）： SPFとDKIMの両方が失敗した場合にレポート生成
v=DMARC1; p=none; fo=0; ruf=mailto:[email protected]fo=1： SPFまたはDKIMのいずれかが失敗した場合にレポート生成
v=DMARC1; p=none; fo=1; ruf=mailto:[email protected]fo=d： DKIMが失敗した場合にレポート生成
v=DMARC1; p=none; fo=d; ruf=mailto:[email protected]fo=s： SPFが失敗した場合にレポート生成
v=DMARC1; p=none; fo=s; ruf=mailto:[email protected]エッジケース
- 複数の値を組み合わせることが可能：
fo=1:d:s - フォレンジックレポートは受信者によって無効化されることが増加
- 大量ドメインではレポート量を最小化するためにfo=0を使用すべき
XIII. 高度な設定例
エンタープライズ展開
v=DMARC1; p=reject; sp=quarantine; adkim=r; aspf=r; pct=100; rua=mailto:[email protected],mailto:[email protected]; ruf=mailto:[email protected]; fo=1; rf=afrf; ri=86400段階的実装
v=DMARC1; p=none; pct=100; rua=mailto:[email protected]; ruf=mailto:[email protected]; fo=1サブドメイン重視ポリシー
v=DMARC1; p=none; sp=reject; adkim=s; aspf=s; rua=mailto:[email protected]XIV. DNS公開要件
DMARCレコードは、適切なDNS設定で_dmarc.yourdomain.comにTXTレコードとして公開する必要があります：
TTLの考慮事項
- 推奨TTL：ポリシー変更には300-3600秒
- より低いTTL値はより高速なポリシー更新を可能にする
- より高いTTL値はDNSクエリ負荷を軽減する
レコード制限
- ドメインごとに単一のDMARCレコード（複数レコードは失敗を引き起こす）
- 最大レコード長はDNSプロバイダーによって異なる
- 長いレコードはTXTレコード分割が必要な場合がある
XV. 一般的な構文エラー
スペースの問題
# 不正 - タグ名にスペース
v = DMARC1; p = none
# 正解
v=DMARC1; p=none大文字小文字の区別
# 不正 - 値の大文字小文字が重要
v=dmarc1; p=NONE
# 正解
v=DMARC1; p=none区切り文字の問題
# 不正 - セミコロンの代わりにカンマ
v=DMARC1, p=none
# 正解
v=DMARC1; p=noneDMARCポリシーを実装する組織は、Skysnag Protectを使用してDMARCパフォーマンスを監視し、レコード構文を検証し、詳細な認証レポートを受信することで利益を得られます。このプラットフォームは、メール認証状態のリアルタイム可視性を提供し、メール配信に影響する前に設定問題を特定するのに役立ちます。
XVI. 重要なポイント
DMARCレコード構文には、必須のバージョンとポリシータグを持つ正確な形式が必要で、任意タグはレポートと整合性制御を提供します。成功した実装には、各コンポーネントの機能の理解、適切なDNS公開、段階的ポリシー拡大が必要です。集計レポートによる定期的な監視は認証の効果を確保し、フォレンジックレポートは特定の失敗パターンの特定に役立ちます。
適切なDMARC設定は、構文ルールが正しく遵守されれば、正当なメール配信を維持しながらドメインをスプーフィング攻撃から保護します。組織は監視ポリシーから始めて、構文を徹底的に検証し、サードパーティDMARCサービスを使用する際には外部レポート認可を実装すべきです。
