DMARC生成ツール
正しいDMARCレコードを数秒で作成。ポリシーを選び、レポートの宛先を入力して、DNSに公開するTXTレコードをコピーするだけ。無料・登録不要。
公開先の正確なホスト名の表示用です。レコード自体には含まれません。
まずnoneで観察し、レポートが正常なら強化します。
毎日のXMLサマリーの送信先。複数はカンマで区切ります。
詳細(sp・アライメント・ruf)
未設定ならサブドメインはpを継承します。未使用のサブドメインは狙われやすいため、強化後はrejectが有力です。
緩和:サブドメインも一致扱い(mail.yourdomain.co.jpの署名がyourdomain.co.jpに有効)。厳格:完全一致のみ。通常は緩和で十分です。
SPF(Return-Path)側も同様です。
メール単位の失敗例で、メール内容を含みます。大手はほぼ送信しません。
DMARCレコード
DNSにTXTレコードとして公開します。
_dmarc.yourdomain.co.jpv=DMARC1; p=none;レコードをクリックで全体を選択
種類:TXT/TTL:プロバイダーの既定値(例:3600)で十分
公開後の手順
DMARCレコード生成ツールとは
このDMARCレコード生成ツール(DMARC作成ツールとも呼ばれます)は、構文を手書きしなくてもレコードを作成できます。DMARCレコードはDNS上の1つのTXTエントリで、SPFとDKIMのアライメントに失敗したメールの扱いと、レポートの送信先を受信側のメールサーバーに伝えます。構文は単純ですがミスに厳しく、タグの位置の誤りやmailto:の付け忘れがあると、受信側はレコード全体を無視します。このツールはわかりやすい選択肢からレコードを組み立て、よくあるミス(レポート宛先の未設定、別ドメインの宛先、無効なメールボックス)を指摘し、DNSプロバイダーに貼り付ける正確なホストと値を表示します。公開後はDMARCチェックで検証し、DMARC設定の完全ガイドをご覧ください。
生成ツールの機能と警告内容
| 注記 | 意味 | 対処法 |
|---|---|---|
| rua未設定 | レコードは公開できますが、集計レポートはどの受信側からも届かず、自社ドメインで誰が送信しているか把握できません。 | 公開前にレポートの宛先を追加します。今後のポリシー判断はすべてレポートが基になります。 |
| 無効なアドレスを除外 | 有効なメールボックスでないアドレスは、壊れた形で公開せずにレコードから除外します。 | 入力ミスを直して再追加します。不正な宛先があると、公開中のタグが無効になることがあります。 |
| p=noneを選択 | 監視モード:受信側は失敗を報告しますが、なりすましメールも含めすべて配信します。 | 出発点として正解です。正規メールの合格をレポートで確認後、quarantine、次にrejectへ移行します。 |
| ruf(失敗レポート)を追加 | 失敗レポートはメール単位のデータを含み、大手の受信側の多くはまったく送信しません。 | 特定の調査が必要で、機密性の高い内容を扱えるメールボックスがある場合のみ追加します。 |
| 別ドメインのレポート宛先 | 別ドメインへのレポート送信には、宛先ドメインでの許可レコードの公開が必要です。ないと受信側は送信しません。 | 宛先ドメインに外部レポートの許可レコードを公開するか、自社ドメインのアドレスを使います。 |
| pct・rf・riは非対応 | RFC 9989で廃止されたタグです。生成ツールは出力しないため、レコードは常に最新です。 | 古いガイドでpctの追加を勧めていても無視し、ポリシーを段階的に変えて強化します。 |
できること・できないこと
選択内容から構文的に正しいレコードを組み立て、公開しても機能しない原因になりやすいミスを指摘します。処理はすべてブラウザ内で完結します。DNSを照会しないため、ドメインで現在公開中の内容はわからず、代わりに公開することもできません。
メールがより厳しいポリシーに進める状態かどうかも判断できません。それがわかるのは集計レポートだけです。そのため安全な手順は、p=noneで公開し、届いたレポートを読み、正規の送信元がすべて一致してから強化することです。公開後はDMARCチェックでレコードを確認してください。
関連するチェックと用語
メール認証ナレッジベース
DMARCレコードの作成方法は?
有効なレコードに必要な判断は3つです。まずポリシー(p)を選びます。最初はnoneにすると、何もブロックせずに受信側からレポートが届きます。次にruaアドレスを設定します。自社ドメインで誰が送信しているかを示す集計レポートを毎日受け取るメールボックスです。最後に、生成された値をDNSのホスト_dmarc.yourdomain.co.jpにTXTレコードとして公開します。正確な文字列は上の生成ツールが組み立てるため、実際に決めるのはポリシーとレポートの宛先だけです。
DMARCレコードの公開先は?
ドメインのDNSを管理している場所で公開します。Cloudflare、GoDaddy、Route 53、レジストラ、MSPのDNSコンソールなどです。新しいTXTレコードを作成し、ホスト(名前)欄に_dmarcと入力し(_dmarc.yourdomain.co.jpの完全な形を求めるプロバイダーもあります)、生成した値を貼り付けて保存します。反映は通常数分ですが、最大1時間ほどかかることがあります。その後、DMARCチェックで反映を確認します。
p=none、quarantine、rejectのどれから始めますか?
自社ドメインで送信するサービスをすべて把握し、SPFとDKIMのアライメントを検証済みでない限り、p=noneから始めます。noneは監視モードです。何もブロックされませんが、ドメインを使う送信元がすべてレポートでわかります。何年も前にマーケティング担当者が登録したツールも含みます。正規のメールがすべて合格しているとレポートで確認できたら、quarantine(失敗したメールは迷惑メールへ)、次にreject(失敗したメールは拒否)へ移行します。監視せずにいきなりrejectにすると、自社の請求書まで止めてしまいます。
ruaタグとは?宛先には何を使いますか?
ruaは、受信側が集計レポートを送る宛先です。集計レポートは、自社ドメインを名乗るメールをどのIPが送り、SPF、DKIM、アライメントに合格したかをまとめた毎日のXMLサマリーです。専用のメールボックス(dmarc-reports@yourdomain.co.jp)も使えますが、実用的なのはDMARC監視サービスのアドレスです。数十の受信側から届く生のXMLを手作業で読むのは大変だからです。Palisadeはこの部分を自動化します。レポートを収集し、送信元の名前がわかる形に変換し、何を修正すべきかを示します。
ruf(失敗レポート)タグは必要ですか?
通常は不要です。rufはメール単位の失敗サンプルを要求しますが、Gmailを含む大手メールボックスプロバイダーの多くはプライバシー上の理由で送信しないため、カバー範囲は限られます。サンプルにはメール本文が含まれることもあり、取り扱いにも注意が必要です。実際の作業に使うのは集計レポート(rua)です。rufは、特定の調査が必要で、機密データを扱えるメールボックスを用意できる場合にだけ追加します。
adkimとaspf(アライメント)の意味は?厳格にすべきですか?
SPFとDKIMのドメインがFromドメインとどこまで一致する必要があるかを決めます。緩和(既定)はサブドメインの一致を認めます。mail.yourdomain.co.jpはyourdomain.co.jpと一致します。厳格は完全一致が必要です。ほぼすべてのドメインは緩和のままにすべきです。正規のサービスはサブドメインから送信することが多く、厳格にするとセキュリティ上の効果は小さいわりに、それらが失敗します。厳格は、送信元が1つだけとわかっている厳重に管理されたドメインでのみ検討してください。
pctタグの役割と、廃止される理由は?
pctは、quarantineまたはrejectポリシーを失敗メールの一定割合にだけ適用し、段階的にポリシーを強化するためのタグです。実際には受信側の実装がまちまちで混乱を招き、DMARCbis(RFC 9989として公開された改訂版DMARC規格)で完全に廃止されます。段階的に進めたい場合、現在の方法は割合によるサンプリングではなく、各段階でレポートを確認しながらnone → quarantine → rejectと進めることです。
この生成ツールとDMARCチェックの違いは?
生成ツールは公開すべきレコードを作成し、チェックはドメインで現在公開中のレコードを読み取って評価します。一般的な流れは、ここでレコードを作成し、DNSに公開してから、チェックで正しく反映・解析されるかを確認する、というものです。自社や顧客の管理ドメインを診断する場合は、まずチェックで現状を確認してから、何を変えるか決めてください。
DMARCレコードで使える全タグを解説します。
- vバージョン
- バージョンタグはDMARCレコードに必須で、値は「DMARC1」に限られます。値が正しくない場合やタグがない場合、DMARCレコードは無効とみなされ、無視されます。
- pポリシー
- DMARCポリシータグは、DMARCに失敗したメールについて3つの値を取ります。noneは隔離・拒否を求めず、quarantineは不審なメールとしての扱いを、rejectは受信拒否を求めます。最終的な処理は受信側が決め、p=noneでも別の仕組みで振り分けや拒否をする場合があります。集計レポートは、ruaタグで別途要求します。
- rua集計レポートの送信先
- 集計レポートの送信先を「mailto:」形式のURIで指定します。受信側のメールボックスプロバイダーがこの宛先に集計レポートを送ります。必須ではありませんが、省略するとレポートは届きません。
- ruf失敗レポートの送信先
- 失敗(フォレンジック)レポートの送信先を「mailto:」形式のURIで指定します。失敗レポートを送る受信側プロバイダーはここへ届けますが、送らない事業者も多くあります。このタグがないと失敗レポートは届きません。
- spspポリシー
- サブドメインのポリシーは、特に指定がない限り、前述のメインドメインのポリシータグ(p=)を継承します。指定できる値はドメインのポリシーと同じく「none」「quarantine」「reject」です。ただし、現在の運用ではあまり使われていません。
- adkimDKIMアライメント
- DKIM署名のアライメント、つまりDKIMのドメインとヘッダーFromの送信元ドメインとの一致を指定するタグです。値は「r」(relaxed)と「s」(strict)です。既定の「r」はドメインの部分一致を許容し、「s」はドメインの完全一致を求めます。
- aspfSPFアライメント
- SPFアライメント、つまりSPFのドメイン(送信元)とヘッダーFromのドメインとの整合性を指定するタグです。値は「r」(relaxed)と「s」(strict)の2つです。既定は「r」で、ドメインの部分一致を許容します。一方「s」では、ドメインの完全一致が必要です。
- fo失敗レポートの条件
- 失敗レポートのオプションは「0」「1」「d」「s」です。既定の「0」は、SPFとDKIMのアライメントがどちらもパスしない場合にのみ失敗レポートを生成します。「1」は、SPFかDKIMのどちらかがパス以外の結果になった場合に使います。「d」はDKIMの検証失敗、「s」はSPF関連の問題についてレポートを生成します。失敗レポートを実際に受け取るには、「ruf」タグの指定が必要です。
- rf失敗レポートの形式
- 失敗レポートの形式は「afrf」と「iodef」の2つから選べます。
- pct適用割合(旧仕様)
- 旧来の適用割合タグは、DMARCに失敗したメールの一部にだけquarantineやrejectを適用するよう受信側に求めるものでした。受信側の実装がばらついたため、RFC 9989でpctは廃止されました。新しいレコードでは省略し、集計レポート、ポリシー全体の変更、送信量の少ないサブドメインで段階的に移行します。
- riレポート間隔
- レポート間隔は、XMLレポートを受け取る頻度を秒単位で指定します。標準値は86400秒で、1日1回のレポートにあたります。ただし、指定した間隔にかかわらず、インターネットサービスプロバイダー(ISP)は通常、独自のスケジュールでレポートを送ります。多くの場合、それも1日1回です。