DNS DMARCポリシーレコードビルダー＆構文バリデータ

DNS DMARCポリシーレコードビルダー＆構文バリデータ

ポリシー適用（none/quarantine/reject）、rua/ruf集約レポート、アライメントタグを備えたRFC 7489準拠のDMARC DNS TXTレコードを生成・検証します。

プリセット:
Enforcement Percentage (pct=)100%
Domain: example.comPolicy: rejectPct: 100%
Security Health Scoreセキュリティ評価 A+ (100/100)

Maximum defense against spoofing, BEC attacks, and phishing impersonation.

100/100
DMARC DNS TXT Value
v=DMARC1; p=reject; rua=mailto:[email protected]!10m
BIND 9 / RFC 1035 Master Zone Syntax
_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=reject; rua=mailto:[email protected]!10m"
DNS Management Table
Host / Name_dmarc(or _dmarc.example.com)
Record TypeTXT
TTL3600 (or Auto)
Length: 60 charsUDP DNS: < 255 B (Single String)
RFC 7489 Valid
ポリシー状態p=reject (100%)
レポート配信1 RUA / 0 RUF
アライメントモードDKIM: Relaxed | SPF: Relaxed

RFC 7489 準拠構文

厳密なタグ順序とバリデーションにより、有効な v=DMARC1 タグを即座にフォーマットします。

完全ローカル・ブラウザ内ビルド

すべてのポリシー計算とパーサー実行はクライアント側で完結し、テレメトリは一切送信されません。

マルチプラットフォーム出力エンジン

BINDゾーンレコード、Cloudflare/Route53設定、dig CLI検証コマンド、RFC 7489 Section 7.1外部レポート承認レコードを生成します。

技術リファレンス＆アーキテクチャガイド

DNS DMARCポリシーレコードビルダー＆構文バリデータ — リファレンスガイド

ポリシー適用（none/quarantine/reject）、rua/ruf集約レポート、アライメントタグを備えたRFC 7489準拠のDMARC DNS TXTレコードを生成・検証します。

主要パラメータ＆設定項目

v (プロトコルバージョン)Enum ("DMARC1")

レコードがDMARCポリシー仕様であることを宣言します。TXT文字列の先頭に大文字で配置し、直後にセミコロンを付ける必要があります。

初期値: DMARC1
p (受信側ポリシー)Enum ("none" | "quarantine" | "reject")

メールがSPFおよびDKIM認証の両方に失敗した際に、受信MTAが適用する強制ポリシー。'none'は拒否せず監視のみ、'quarantine'は迷惑メールフォルダへ隔離、'reject'はSMTPトランザクション層で配送を即時拒否します。

初期値: none
sp (サブドメインポリシー)Enum ("none" | "quarantine" | "reject")

すべてのサブドメインに対して組織ポリシー'p'を上書き適用します。'sp=reject'を明示的に指定することで、未使用または新規サブドメインのなりすましを強固に防止できます。

初期値: 継承 (pと同一)
rua (集約フィードバックレポート先URI)URIリスト (mailto:address)

認証結果、送信元IPアドレス、送信総数をまとめた日次集約XMLレポートを受信するmailto: URIのカンマ区切りリスト。

初期値: なし
ruf (フォレンジック/失敗詳細レポート先URI)URIリスト (mailto:address)

認証失敗が発生した際に即時送信されるRFC 6591 AFRF形式のインシデント詳細レポートの受信先URIリスト。

初期値: なし
pct (ポリシー適用パーセンテージ)Integer (0 - 100)

ポリシー'p'または'sp'を適用する不合格メッセージの割合（%）。quarantine 25%から段階的に引き上げ、最終的に100% rejectへ安全に移行するために活用されます。

初期値: 100
adkim / aspf (アライメントモード)Enum ("r" | "s")

DKIMおよびSPFのドメイン一致判定の厳格度。'r'（緩和）は組織ルートドメイン一致（subdomain.example.comとexample.com）を許容し、's'（厳格）は完全なFQDN一致を要求します。

初期値: r (緩和)

プロの活用テクニック＆推奨設定

いきなりrejectを適用せず、3段階のフェーズ展開を実施する

まずは'p=none'で2〜4週間運用し、'rua'集約XMLレポートを解析して正規のサードパーティ送信サービス（SendGrid、Google Workspace、Zendesk等）を洗い出します。正当なメールの99%以上でSPF/DKIMが整った後、'p=quarantine; pct=25'から100%へ引き上げ、最終的に'p=reject'へロックします。

別ドメインのruaアドレスを指定する場合は外部送信許可レコードを公開する

自社ドメインが'example.com'で、'rua'の宛先が'mailto:[email protected]'のような別ドメインの場合、RFC 7489 第7.1項に基づき、受信側ドメインのDNSに'example.com._report._dmarc.thirdparty.com'（TXT: 'v=DMARC1;'）を公開する必要があります。これがないとDDoS防御のためレポート送信が抑制されます。

攻撃者は組織ドメインそのものではなく

攻撃者は組織ドメインそのものではなく、使われていないサブドメイン（例: billing.example.com）を偽装することが多々あります。'v=DMARC1; p=none; sp=reject; rua=mailto:...'と設定すれば、メインドメインのメール送受信に影響を与えずにサブドメインの偽装メールを即時遮断できます。

メール転送やメーリングリスト対策としてSPFよりもDKIMアライメントを重視する

メールが中継サーバや転送サービスを経由すると、送信元IPが変更されるためSPFアライメントはほぼ確実に失敗します。一方、暗号署名であるDKIMはヘッダーや本文が改ざんされない限り転送後も有効であるため、厳格なDMARC運用における誤判定防止の要となります。

よくあるトラブルと解決策

主要プロバイダ（Google、Yahoo、Microsoft等）からrua集約レポートが届かない

ruaタグの値に'mailto:'プレフィックスが付与されているか確認してください（例: 'mailto:[email protected]'）。また、外部ドメインに送信する場合は受信側ドメインに認証レコード（'送信元._report._dmarc.受信先'）が存在するか、受信メールボックスの容量制限に達していないかを検証してください。

'p=quarantine'や'p=reject'を導入後、マーケティングメールやCRMからの配信がスパム扱い・不達になる

集約XMLレポートを確認し、SPFまたはDKIMのアライメント不一致を特定してください。外部配信サービス側で自社Fromドメインと一致するDKIMセレクタ署名が設定されているか確認し、独自Return-Path（SPF）のCNAME設定を正しく完了させてください。

DNS診断ツールで「DMARCレコードが見つからない」または「重複レコードが存在する」と警告される

DMARCレコードは必ず'_dmarc.yourdomain.com'というサブドメインのTXTレコードとして公開する必要があります（ルートドメイン'@'ではありません）。また、'v=DMARC1'で始まるTXTレコードはドメインあたり厳密に1つのみ配置してください。複数存在する場合、RFC 7489によりすべてのポリシーが無効化されます。

よくある質問 (FAQ)

SPF、DKIM、DMARCの技術的な関係性と役割分担は？▼

SPF（RFC 7208）はエンベロープ送信元（MAIL FROM）と送信サーバIPの正当性を検証します。DKIM（RFC 6376）は公開鍵暗号によりヘッダーと本文の改ざん検知と送信元証明を行います。DMARC（RFC 7489）はこれら両プロトコルをユーザに見える'From:'ヘッダー（RFC 5322）と結びつけ（アライメント）、失敗時の処理指示とフィードバック集約を提供します。

DMARCをパスするにはSPFとDKIMの両方に合格する必要がありますか？▼

いいえ、必須ではありません。RFC 7489の仕様上、SPFアライメントまたはDKIMアライメントの「いずれか一方」が合格すれば、DMARC評価全体として合格（pass）と判定されます。ただし、転送耐性を高めるため両方の一致を整えることが推奨されます。

アライメントモードの緩和（'r'）と厳格（'s'）の違いは何ですか？▼

緩和モード（デフォルトの'r'）では、SPFのエンベロープドメインやDKIM署名の'd='ドメインが、Fromヘッダーと同一の組織ドメイン（ルートドメイン）であれば合格します（例: news.example.comとexample.com）。厳格モード（'s'）では、サブドメインを含むFQDNが完全一致しなければ不合格となります。

メーリングリストや自動転送によってDMARCが失敗するのはなぜですか？▼

転送サーバがエンベロープ送信元IPを自身のIPに書き換えるためSPF検証が失敗します。さらに、メーリングリストが件名にタグを追加したりフッターを挿入するとDKIM署名ハッシュが破損します。この業界課題を解決するため、経由地での検証結果を引き継ぐARC（Authenticated Received Chain, RFC 8617）の導入が進んでいます。

集約レポート（rua）とフォレンジックレポート（ruf）の違いは？▼

ruaは全送信元の送信量や認証結果を日次でまとめたXML集約データであり、本文は含まれません。一方、rufは認証失敗時に個々のメールヘッダーや本文の抜粋を含むリアルタイム障害レポートです。個人情報（PII）の漏洩やGDPR上のプライバシー懸念から、GoogleやMicrosoftなどの主要プロバイダはrufの配信を停止しています。

関連するおすすめ開発ツール

すべてのツール →
DNS CAA（認証局承認）レコードジェネレーターセキュリティ

RFC 8659 に準拠した DNS CAA レコードを生成し、SSL/TLS 証明書の発行権限を信頼できる認証局（Let's Encrypt、DigiCert、Sectigo など）に限定します。

ツールを開く→
DNS DKIM TXTレコード生成＆セレクタ設計 完全セキュリティ

RFC 6376準拠のDNS DKIM TXTレコード（v=DKIM1; k=rsa; p=...）の構築、セレクタ命名規則、255文字制限の分割手法、および認証検証手順を解説します。

ツールを開く→
MTA-STS ポリシー＆TLS-RPT DNSレコードジェネレーターセキュリティ

RFC 8461準拠のMTA-STSポリシーファイル、_mta-sts DNS TXTレコード、およびRFC 8460 TLS-RPTレポートレコードの生成仕様と運用ベストプラクティス。

ツールを開く→
JWTトークンデコーダー＆セキュリティインスペクターセキュリティ

ブラウザ上でJSON Web Tokenをデコードし、RFC 7519およびOIDCクレームの確認、有効期限の精密検査、HMAC署名のローカル検証を行う開発者向けユーティリティ。

ツールを開く→
高強度パスワード・パスフレーズ自動生成ツールセキュリティ

暗号論的擬似乱数生成器（Web Crypto CSPRNG）を用いた高エントロピーパスワード、覚えられるDicewareパスフレーズ、PIN、APIトークンをブラウザ内で瞬時に安全生成。NIST SP 800-63B準拠。

ツールを開く→
暗号学的ハッシュ値・チェックサム一括計算ツールセキュリティ

SHA-256、SHA-512、MD5、SHA-1、SHA-3、Keccak、CRC32をブラウザ内で瞬時に一括算出。Web Crypto APIによる100%クライアントサイド完結。

ツールを開く→