DMARCレコード構文の理解は、効果的なメール認証を実装するための基本です。DMARC(Domain-based Message Authentication, Reporting and Conformance)レコードは、SPFまたはDKIM認証に失敗したメールを受信メールサーバーがどのように処理すべきかを指示する特定のタグと値で構成されています。この包括的なガイドでは、実践的な例と検証手法を用いてすべてのDMARCタグを詳しく解説し、完璧なDMARCポリシーの構築をサポートします。
I. DMARCレコードの基本構造
DMARCレコードは、_dmarc.yourdomain.comというサブドメインにDNS TXTレコードとして公開されます。基本的な構文はセミコロンで区切られたタグ-値ペア形式に従います:
"v=DMARC1; p=quarantine; rua=mailto:[email protected]; ruf=mailto:[email protected]; sp=reject; adkim=s; aspf=s"各タグは、ドメインのメール認証ポリシーを定義する上で特定の機能を果たします。すべてのタグを詳しく見ていきましょう。
II. 必須DMARCタグ
v(バージョン)
構文: v=DMARC1
目的: DMARCバージョンの指定
必須: はい(最初のタグである必要があります)
バージョンタグは常にDMARC1である必要があり、レコードの最初のタグとして表示されなければなりません。他のバージョンは存在しません。
例:
v=DMARC1よくあるエラー: DMARC1以外を使用すると、レコードが無視されます。
p(ポリシー)
構文: p=none|quarantine|reject
目的: ドメインアライメント失敗時のアクションを定義
必須: はい
ポリシータグは、DMARC認証に失敗したメールに対して受信サーバーが何をすべきかを決定します:
p=none: 監視のみ、強制アクションなしp=quarantine: 失敗したメールをスパム/迷惑メールフォルダに配置p=reject: 失敗したメールを完全に拒否
例:
p=none # 監視フェーズ
p=quarantine # ソフト強制
p=reject # 完全強制ベストプラクティス: p=noneで監視を開始し、正規のトラフィック分析に基づいて徐々にp=quarantine、そしてp=rejectに進めます。
III. オプションポリシータグ
sp(サブドメインポリシー)
構文: sp=none|quarantine|reject
目的: サブドメインメッセージのポリシー
デフォルト: メインポリシー値を継承
サブドメインポリシーは、サブドメインからのメッセージに対して異なる処理を可能にします。
例:
v=DMARC1; p=quarantine; sp=rejectこの設定では、失敗したメインドメインメールは隔離されますが、失敗したサブドメインメールは拒否されます。
pct(パーセンテージ)
構文: pct=1-100
目的: ポリシーを適用するメッセージの割合
デフォルト: 100
失敗したメッセージのうち、ポリシーを適用すべき割合を指定することで、段階的なポリシー展開を可能にします。
例:
pct=25 # 失敗したメッセージの25%にポリシーを適用
pct=50 # 失敗したメッセージの50%にポリシーを適用
pct=100 # すべての失敗したメッセージにポリシーを適用(デフォルト)ユースケース: p=noneからp=quarantineに移行する際は、pct=10から始めて徐々に増やします。
IV. アライメントタグ
adkim(DKIMアライメント)
構文: adkim=r|s
目的: DKIM識別子アライメントモード
デフォルト: r(緩和)
adkim=r: 緩和アライメント(サブドメインマッチ許可)adkim=s: 厳格アライメント(正確なドメインマッチ必須)
例:
adkim=r # mail.example.comがexample.comの署名可能
adkim=s # example.comのみがexample.comの署名可能aspf(SPFアライメント)
構文: aspf=r|s
目的: SPF識別子アライメントモード
デフォルト: r(緩和)
aspf=r: 緩和アライメント(サブドメインマッチ許可)aspf=s: 厳格アライメント(正確なドメインマッチ必須)
例:
aspf=r # Return-Path: [email protected]がFrom: [email protected]で合格
aspf=s # Return-PathはFromドメインと正確に一致する必要があるV. レポートタグ
rua(集約レポート)
構文: rua=mailto:[email protected]
目的: 集約レポート用のメールアドレス
形式: 認証統計を含む日次XMLレポート
例:
rua=mailto:[email protected]
rua=mailto:[email protected],mailto:[email protected]複数アドレス: 冗長性のためにカンマで区切ります。
ruf(フォレンジックレポート)
構文: ruf=mailto:[email protected]
目的: 失敗レポート用のメールアドレス
形式: メッセージサンプルを含む個別失敗通知
例:
ruf=mailto:[email protected]
ruf=mailto:[email protected],mailto:[email protected]プライバシーノート: フォレンジックレポートにはメッセージ内容が含まれ、プライバシーに関する影響がある可能性があります。
ri(レポート間隔)
構文: ri=秒数
目的: 集約レポートの間隔
デフォルト: 86400(24時間)
例:
ri=3600 # 1時間ごとのレポート(非推奨)
ri=86400 # 日次レポート(デフォルト)
ri=604800 # 週次レポート制限: ほとんどの受信者はこのタグを無視し、いずれにせよ日次レポートを送信します。
fo(フォレンジックオプション)
構文: fo=0|1|d|s
目的: フォレンジックレポート生成の条件
デフォルト: 0
fo=0: SPFとDKIM両方が失敗した場合にレポートを生成fo=1: SPFまたはDKIMのいずれかが失敗した場合にレポートを生成fo=d: DKIMが失敗した場合にレポートを生成fo=s: SPFが失敗した場合にレポートを生成
例:
fo=1 # 認証失敗をレポート
fo=d # DKIM失敗のみレポート
fo=s # SPF失敗のみレポートVI. 高度なDMARCレコード例
監視設定
v=DMARC1; p=none; rua=mailto:[email protected]; ruf=mailto:[email protected]; fo=1このレコードは、強制せずにすべてのトラフィックを監視し、集約レポートとフォレンジックレポートの両方を生成します。
段階的強制
v=DMARC1; p=quarantine; pct=25; sp=none; rua=mailto:[email protected]; adkim=r; aspf=r失敗したメインドメインメッセージの25%に隔離ポリシーを適用し、サブドメインは監視します。
厳格な強制
v=DMARC1; p=reject; sp=reject; rua=mailto:[email protected]; adkim=s; aspf=sメインドメインとサブドメインの両方に厳格なアライメントでの完全強制。
エンタープライズ設定
v=DMARC1; p=reject; sp=quarantine; rua=mailto:[email protected],mailto:[email protected]; ruf=mailto:[email protected]; pct=100; adkim=s; aspf=r; fo=1; ri=86400複数のレポート送信先と混合アライメントポリシーを持つ完全なエンタープライズセットアップ。
VII. 一般的な構文エラーと検証
フォーマットミス
セミコロンの欠落:
❌ v=DMARC1 p=reject rua=mailto:[email protected]
✅ v=DMARC1; p=reject; rua=mailto:[email protected]誤ったタグ順序(vが最初である必要があります):
❌ p=reject; v=DMARC1; rua=mailto:[email protected]
✅ v=DMARC1; p=reject; rua=mailto:[email protected]無効なポリシー値:
❌ p=block
✅ p=reject
❌ p=spam
✅ p=quarantineメールアドレスの検証
不正なアドレス:
❌ [email protected] # mailto:が欠落
✅ rua=mailto:[email protected]
❌ rua=mailto:test@domain # 無効なドメイン
✅ rua=mailto:[email protected]パーセンテージ値
範囲外:
❌ pct=150 # 100を超える
✅ pct=100
❌ pct=0 # ゼロは許可されない
✅ pct=1VIII. DMARCレコード検証手法
DNSルックアップ検証
dig TXT _dmarc.example.com
nslookup -type=TXT _dmarc.example.comオンライン検証ツール
DMARCレコードチェッカーを使用して構文を検証し、一般的なエラーを検出します。これらのツールは以下を確認します:
- 適切なタグフォーマット
- 有効なポリシー値
- メールアドレス構文
- DNS伝播状態
手動検証チェックリスト
- バージョンタグ:
v=DMARC1が最初にあることを確認 - ポリシータグ:
p=が有効な値を持つことを確認 - セミコロン: すべてのタグがセミコロンで区切られていることを確認
- メール形式: レポートアドレスに
mailto:プレフィックスがあることを検証 - 数値範囲:
pct=が1-100、ri=が正の整数であることを確認 - アライメント値:
adkim=とaspf=がrまたはsのみを使用することを確認
DMARC実装のテスト
レコードを公開した後、以下を通じて認証結果を監視します:
- DMARC集約レポート
- メール配信ログ
- サードパーティ監視サービス
Skysnag Protectは、自動化されたレコード生成、検証、および継続的な監視を提供することで、DMARC実装を簡素化し、メール認証ポリシーが正しく機能することを保証します。
IX. 高度な設定の考慮事項
マルチドメイン組織
複数のドメインを管理する組織の場合、以下を検討します:
- 集中レポートアドレス
- 一貫したポリシー強制レベル
- サブドメインポリシーの継承
メールサービスプロバイダーとの統合
サードパーティのメールサービスを使用する場合:
- DKIM署名アライメントを確認
- SPFレコードのインクルードを調整
- ポリシー強制の影響をテスト
インシデント対応計画
DMARC関連の配信問題に備える:
- 集約レポートのトレンドを監視
- ポリシーロールバック手順を確立
- 正規送信者のインベントリを維持
X. 重要なポイント
DMARCレコード構文は、正確なフォーマットと各タグがメール配信に与える影響の慎重な考慮を必要とします。p=noneを使用した監視ポリシーから始め、集約レポートを分析しながらp=quarantineとp=rejectで段階的に強制します。メールインフラストラクチャに基づいて適切なアライメントモードを設定し、デプロイ前に必ずレコードを検証してください。DMARCの有効性は、正確なポリシー設定とともに適切なSPFおよびDKIM実装に依存することを忘れないでください。
これらの構文ルールと検証手法を理解することで、組織はなりすましから保護し、正規のメール配信を維持する堅牢なメール認証を実装できます。定期的な監視とポリシーの改善により、メールインフラストラクチャの進化に応じた継続的な有効性が保証されます。
