DMARC(Domain-based Message Authentication, Reporting and Conformance)レコードは、年間120億ドル以上の損失をもたらす巧妙なフィッシングやスプーフィング攻撃から組織を保護する、メール認証の基盤として機能します。効果的なメールセキュリティポリシーを実装し、ドメインレピュテーションを保護するためには、正確な構文と設定オプションを理解することが不可欠です。
適切に設定されたDMARCレコードは、DNSに公開されるポリシー指示セットとして機能し、受信メールサーバーに認証チェックに失敗したメールの処理方法を指示します。この包括的なガイドでは、DMARCの構文のすべてのコンポーネントを詳しく解説し、堅牢なメール保護を設定するために必要な技術的な詳細を提供します。
DMARCレコード構造の理解
DMARCレコードは、DNSのTXTレコードとして公開される特定のタグ値形式に従います。レコードは、プライマリドメインの下の_dmarcサブドメインに配置する必要があり、完全なDNSエントリ_dmarc.yourdomain.comを作成します。
基本的なDMARCレコード形式
v=DMARC1; p=none; rua=mailto:[email protected]すべてのDMARCレコードはバージョンタグで始まり、ポリシー指示を含みます。セミコロンは各タグ値ペアを区切り、セミコロンの後のスペースは任意ですが、可読性のために推奨されます。
必須タグと任意タグ
DMARCレコードには、必須タグと任意タグの両方が含まれます:
必須タグ:
v(バージョン)p(ポリシー)
任意タグ:
rua(集計レポートURI)ruf(フォレンジックレポートURI)fo(フォレンジックオプション)aspf(ASPF整合性モード)adkim(ADKIM整合性モード)pct(パーセンテージ)rf(レポート形式)ri(レポート間隔)sp(サブドメインポリシー)
完全なDMARCタグリファレンス
バージョンタグ (v)
構文: v=DMARC1
バージョンタグはDMARC仕様のバージョンを識別し、レコードの最初のタグでなければなりません。現在、DMARC1のみが有効な値です。
例:
v=DMARC1; p=quarantine; rua=mailto:[email protected]検証: バージョンタグは大文字小文字を区別し、表示されたとおりに正確に表記する必要があります。逸脱があるとDMARCレコード全体が無効になります。
ポリシータグ (p)
構文: p=none|quarantine|reject
ポリシータグは、メッセージがDMARC整合性チェックに失敗した際に、受信メールサーバーが取るべきアクションを指定します。
ポリシーオプション:
- none: 監視モード、失敗したメッセージに対してアクションなし
- quarantine: 失敗したメッセージをスパム/迷惑メールフォルダーに配送
- reject: 失敗したメッセージをSMTPレベルで拒否
例:
v=DMARC1; p=none; rua=mailto:[email protected]
v=DMARC1; p=quarantine; pct=25; rua=mailto:[email protected]
v=DMARC1; p=reject; rua=mailto:[email protected]ベストプラクティス: p=noneから開始してトラフィックパターンを監視し、その後段階的にp=quarantine、最終的にp=rejectに移行して最大限の保護を実現します。
集計レポートURI (rua)
構文: rua=mailto:[email protected] または rua=https://example.com/dmarc
集計レポートURIは、XML集計レポートを送信する場所を指定します。これらのレポートには、メッセージ認証結果の統計データが含まれます。
例:
rua=mailto:[email protected]
rua=mailto:[email protected],mailto:[email protected]
rua=https://dmarc-collector.example.com/reports複数の宛先: 複数のURIをコンマで区切ります。各宛先は集計レポートのコピーを受信します。
外部宛先: 外部ドメインにレポートを送信する場合、受信ドメインはレポート受信を許可するDMARCレコードを公開する必要があります。
フォレンジックレポートURI (ruf)
構文: ruf=mailto:[email protected]
フォレンジックレポートは、メッセージヘッダーや認証結果を含む、個別のメッセージ失敗に関する詳細情報を提供します。
例:
ruf=mailto:[email protected]
ruf=mailto:[email protected],mailto:[email protected]プライバシーに関する考慮事項: フォレンジックレポートには機密性の高いメッセージ内容が含まれます。このタグを設定する際は、適切なデータ処理とプライバシーコンプライアンスを確保してください。
フォレンジックオプション (fo)
構文: fo=0|1|d|s
フォレンジックオプションタグは、失敗したメッセージに対してフォレンジックレポートを生成するタイミングを制御します。
オプション:
- 0: SPFとDKIMの両方が失敗した場合にレポートを生成(デフォルト)
- 1: SPFまたはDKIMのどちらかが失敗した場合にレポートを生成
- d: DKIMが失敗した場合にレポートを生成
- s: SPFが失敗した場合にレポートを生成
例:
fo=1; ruf=mailto:[email protected]
fo=d:s; ruf=mailto:[email protected]整合性モードタグ
SPF整合性モード (aspf)
構文: aspf=r|s
SPF整合性チェックの厳密さを制御します:
- r: 緩和モード(デフォルト) – サブドメインの整合性を許可
- s: 厳密モード – 正確なドメインマッチが必要
DKIM整合性モード (adkim)
構文: adkim=r|s
DKIM整合性チェックの厳密さを制御します:
- r: 緩和モード(デフォルト) – サブドメインの整合性を許可
- s: 厳密モード – 正確なドメインマッチが必要
例:
v=DMARC1; p=quarantine; aspf=s; adkim=s; rua=mailto:[email protected]
v=DMARC1; p=none; aspf=r; adkim=r; rua=mailto:[email protected]パーセンテージタグ (pct)
構文: pct=1-100
ポリシー施行の対象となるメッセージの割合を指定します。段階的なポリシー展開に有用です。
例:
v=DMARC1; p=quarantine; pct=10; rua=mailto:[email protected]
v=DMARC1; p=reject; pct=100; rua=mailto:[email protected]デフォルト: 省略した場合、デフォルトは100(すべてのメッセージがポリシーの対象)です。
レポート形式 (rf)
構文: rf=afrf|iodef
フォレンジックレポートの形式を指定します:
- afrf: Authentication Failure Reporting Format(デフォルト)
- iodef: Incident Object Description Exchange Format
レポート間隔 (ri)
構文: ri=seconds
集計レポート間の間隔を秒単位で指定します。ほとんどの受信システムはこのタグを無視し、日次レポートを送信します。
例:
ri=86400 // 24時間を秒単位で表現サブドメインポリシー (sp)
構文: sp=none|quarantine|reject
サブドメインに明示的なDMARCレコードが存在しない場合のサブドメインポリシーを定義します。
例:
v=DMARC1; p=reject; sp=quarantine; rua=mailto:[email protected]
v=DMARC1; p=none; sp=none; rua=mailto:[email protected]高度な設定例
基本的な監視設定
v=DMARC1; p=none; rua=mailto:[email protected]; ruf=mailto:[email protected]; fo=1段階的展開を伴う厳密なポリシー
v=DMARC1; p=quarantine; pct=25; aspf=s; adkim=s; rua=mailto:[email protected]最大保護設定
v=DMARC1; p=reject; sp=reject; aspf=s; adkim=s; rua=mailto:[email protected]; ruf=mailto:[email protected]; fo=1企業向け複数宛先設定
v=DMARC1; p=quarantine; rua=mailto:[email protected],mailto:[email protected]; ruf=mailto:[email protected]; pct=50; fo=1検証とテストツール
DNSクエリ検証
DMARCレコードの公開を確認するために、これらのコマンドを使用します:
dig TXT _dmarc.example.com
nslookup -type=TXT _dmarc.example.com構文検証
Skysnag Protectなどのツールは、構文エラー、ポリシー競合、設定推奨事項をチェックする包括的なDMARCレコード検証を提供します。
よくある検証エラー
- バージョンタグの欠如: レコードは
v=DMARC1で始まる必要があります - 無効なポリシー値:
none、quarantine、rejectのみが有効です - 不正なメールアドレス形式: URIは適切なmailto:形式に従う必要があります
- 整合性モードの競合: 厳密モードと緩和モード間の一貫性を確保してください
- 無効なパーセンテージ値: 1-100の整数である必要があります
エッジケースとトラブルシューティング
複数のDMARCレコード
ドメインごとに1つのDMARCレコードのみが許可されます。複数のレコードがあると、すべてのメッセージでDMARC失敗が発生します。
サブドメインの継承
明示的なDMARCレコードがないサブドメインは、組織ドメインのポリシーまたは指定されている場合はspタグの値を継承します。
レコード長の制限
DNS TXTレコードには文字列あたり255文字の制限があります。長いDMARCレコードでは文字列の連結が必要な場合があります:
"v=DMARC1; p=quarantine; rua=mailto:very-long-email-address@" "example-domain-with-long-name.com; fo=1"レポート配信の問題
外部レポート宛先には適切なDNS認証が必要です。受信ドメインがあなたのドメインからのレポートを受け入れることを確認してください。
実装のベストプラクティス
段階的展開戦略
- フェーズ1:
p=noneでレポートを有効にしてベースラインを確立 - フェーズ2: 低いパーセンテージで
p=quarantineに移行 - フェーズ3: レポートを監視しながら段階的にパーセンテージを増加
- フェーズ4: 完全な保護のために
p=rejectを実装
監視とメンテナンス
定期的なDMARCレポート分析により、認証問題、未許可の送信元、潜在的なセキュリティ脅威が明らかになります。Skysnag Protectなどのツールは、レポート処理を自動化し、ポリシー最適化のための実用的な洞察を提供します。
SPFとDKIMとの統合
DMARCでは、SPFまたはDKIMのいずれかによる認証が正しく行われ、適切なアライメントが必要です。厳格なDMARCポリシーを導入する前に、両方のプロトコルが正しく設定されていることを確認してください。
重要なポイント
DMARCレコードの構文は、特定の検証要件を持つ正確なタグと値の形式に従います。監視ポリシーから開始し、集計レポートを分析しながら保護レベルを段階的に引き上げます。適切なアライメントモードの設定とパーセンテージベースの段階的ロールアウトにより、正規メールを妨げることなくスムーズな導入が可能になります。
すべてのDMARCタグを理解することで、組織は特定のセキュリティ要件に合わせた高度なメール認証ポリシーを実装できます。定期的な検証と監視により、進化するメール脅威に対する継続的な保護が確保されます。
包括的なDMARC管理とポリシーの自動最適化については、Skysnag Protectを活用し、メール認証の導入を効率化してください。
送信元のアイデンティティを保護し、ドメインの信頼性を守る準備はできていますか?今すぐご登録ください。
始めましょう