
DMARCレコードとは?
DMARCレコードは、ドメインのDNS設定に追加する短い1行のテキストです。自社のドメインから送られたと名乗っているのに、セキュリティのチェックに失敗したメールをどう扱うかを、他のメールサーバーに伝えます。また、自社の名前で届いたメールについてのレポートを、どこに送るかも伝えます。
一文で言うと:DMARCは「私のドメインから送られたと名乗るメールが、実際には私からのものでなければ、迷惑メールフォルダに入れるかブロックし、レポートを送ってください」と伝える公開のルールです。
例で見るDMARC
問題
誰でもメールを送ることができ、From行に他人のアドレスを入れることもできます。たとえば、自社のドメインが example.com だとします。詐欺師が、自社の顧客に次のメールを送ります。
From: billing@example.com
Subject: Your invoice is overdue
Pay here: http://pay-now.example.net
顧客は example.com を見て信用します。しかし、このメールを送ったのは自社ではありません。
すでにある二つのチェック
GmailやOutlookなどのメールのプロバイダーは、すべてのメールに対して二つのチェックをすでに行うことができます。
- SPF:このメールは、
example.comがメールの送信を許可しているサーバーから送られたか? - DKIM:このメールには
example.comのデジタル署名が付いているか?
ただし、これらのチェックだけでは抜け穴があります。詐欺師は自分のドメインでこれらのチェックに合格できます。その一方で、From行には自社のドメインが表示されたままです。チェックと、顧客が目にするアドレスを結びつけるものがありません。
DMARCが追加するもの
DMARCはルールを一つ追加します。SPFかDKIMが、From行に表示されているのと同じドメインで合格しなければなりません。この一致をアライメントと呼びます。そのドメインでどちらのチェックも合格しなければ、メールはDMARCに失敗します。
DMARCでは、失敗したメールをどう扱うかも決められます。
DMARCレコードを部分ごとに見る
example.com のDNS設定に、次の行を追加します。
v=DMARC1; p=reject; rua=mailto:reports@example.com
各部分の意味は次のとおりです。
v=DMARC1:「これは私のDMARCのルールです。」p=reject:「example.comから送られたと名乗っているのにチェックに失敗したメールは、ブロックしてください。」rua=mailto:reports@example.com:「私の名前でメールを送っているすべての送信元について、毎日レポートを送ってください。」
偽のメールはどうなるか
- 詐欺師が
billing@example.comから送ったメールがGmailに届きます。 - GmailはSPFとDKIMを確認します。どちらのチェックも
example.comでは合格しません。 - Gmailは自社のDMARCレコードを読みます。そこには
p=rejectと書かれています。 - Gmailはメールをブロックします。顧客がそのメールを目にすることはありません。
自社の本物のメールは同じチェックに合格するので、通常どおり配信されます。
pの三つの選択肢
| 設定 | DMARCに失敗したメールの扱い | 使う時期 |
|---|---|---|
| p=none | 何もしない。通常どおり配信され、レポートが届く | 最初の段階。本物の送信元をすべて見つけるまで |
| p=quarantine | 迷惑メールフォルダに入る | 本物の送信元がすべて合格するようになったら |
| p=reject | 完全にブロックされる | 本物のメールが失敗しないと確信できたら |
多くのドメインの設定の進め方
p=noneから始め、毎日のレポートを読みます。- メール配信ツールやサポートデスクなど、自社のメールを送っている本物のサービスをすべて見つけます。それぞれが合格することを確認します。
p=quarantineに進み、次にp=rejectに進みます。これで、自社のポリシーに従う受信側では、誰も自社のドメインを偽装できなくなります。
そのため、多くのドメインは次のような監視だけを行うレコードから始めます。
v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com
このガイドの残りでは、DMARCレコードの各部分と、後から追加できるオプションを詳しく説明します。
SPF、DKIM、Fromアドレスをもう少し詳しく
DMARCはSPFとDKIMの上に成り立っています。SPFとDKIMについては別の解説で詳しく説明しています。要点は次のとおりです。
SPFは、そのドメインのメールを送ってよいサーバーの一覧です。受信サーバーは、メールがその一覧にあるサーバーから送られたかを確認します。
DKIMは、各メールに付けるデジタル署名です。受信サーバーは、DNSにある鍵で署名を確認します。署名が有効なら、メールは途中で変更されておらず、自社のドメインによって署名されたということです。
Fromアドレスは、受信者が受信トレイで目にする送信者のアドレスです。たとえば hello@example.com です。DMARCは、SPFかDKIMがこれと同じドメインで合格したかを確認します。
DMARCレコードの形
DNSのどこに置くか
DNSは、ドメインの公開の設定一覧です。DNSホストで編集します。DNSホストは通常、ドメインを購入した会社かホスティングのプロバイダーです。DMARCレコードはTXTレコードです。TXTレコードとは、プレーンテキストを入れるDNSの項目です。
レコードはホスト名 _dmarc の下に追加します。多くのDNSの管理画面では、末尾にドメインが自動で付きます。そのため _dmarc は _dmarc.example.com になります。
よくある間違いに注意してください。管理画面によっては、_dmarc だけを入力する前提になっています。そこに _dmarc.example.com と完全な名前を入力すると、レコードは _dmarc.example.com.example.com に作成されます。受信サーバーはそこではレコードを見つけられません。
書き方のルール
v=DMARC1で始める必要があります。これはレコードの最初の部分でなければなりません。DMARC1は大文字で書きます。v=dmarc1と書いたり、別の部分を先に書いたり、つづりを間違えたりすると、受信サーバーはレコード全体を無視します。その場合、ドメインにはDMARCのポリシーがないものとして扱われます。- 各部分はセミコロンで区切ります。セミコロンの前後に空白を入れてもかまいません。
- ポリシーがない場合。
pの部分がない、または間違っていて、ruaには有効なレポートの送り先があるとします。この場合、受信側はポリシーをp=noneとして扱います。pとruaの両方がない、または間違っている場合、受信側はそのドメインのDMARCを完全に無視します。 - DMARCレコードは一つだけ公開します。受信サーバーが
v=DMARC1で始まるTXTレコードを二つ以上見つけると、そのすべてを捨てます。このルールは、現在のDMARCの標準であるRFC 9989によるものです。レコードが二つあってもポリシーが二つになるわけではありません。ドメインがまったく保護されない状態になります。
レコードの確認方法
パソコンのターミナルでコマンドを実行すると、レコードを調べられます。
dig TXT _dmarc.example.com +short
nslookup -type=TXT _dmarc.example.com
LinuxとmacOSでは dig を使います。レコードが引用符に囲まれて1行で表示されます。Windowsでは nslookup を使います。DNSサーバーが返すレコードが表示されます。
コマンドで何も返ってこない場合、原因は二つのどちらかです。レコードがまだDNS全体に反映されていないか、間違ったホスト名で追加されたかです。
DMARCのすべてのタグと、必要なタグ
p=none のようなDMARCレコードの各部分を、タグと呼びます。2026年5月からの現在の標準には、11個のタグがあります。
| タグ | わかりやすく言うと何をするか | 指定できる値 | 省略した場合 | 必要か |
|---|---|---|---|---|
| v | 「これはDMARCレコードです」と示す。最初に置く必要がある | DMARC1 | 必須 | はい |
| p | ポリシー。失敗したメールをどう扱うか。ドメインとそのサブドメインに適用される | none、quarantine、reject | ruaが有効ならnoneとして扱われる | はい |
| rua | 毎日の集計レポートの送り先 | mailto: のアドレスを一つ以上、カンマ区切り | レポートが届かない | はい |
| sp | news.example.comなど、存在するサブドメイン用の別のポリシー | none、quarantine、reject | pと同じ | サブドメインに別のルールが必要な場合のみ |
| np | DNSに存在しないサブドメイン用のポリシー | none、quarantine、reject | spと同じ。spがなければpと同じ | 架空のサブドメインをブロックしたい場合のみ |
| adkim | DKIMのドメインがどこまで正確に一致する必要があるか。r=緩やか、s=厳格 | r、s | r | まれ。通常は緩やかを選ぶ |
| aspf | SPFのドメインがどこまで正確に一致する必要があるか。r=緩やか、s=厳格 | r、s | r | まれ。通常は緩やかを選ぶ |
| t | テストモード。受信側にポリシーを一段階ゆるく適用させる | y、n | n | より厳しいポリシーに移行する間のみ |
| ruf | 失敗した個々のメールについてのレポートの送り先 | mailto: のアドレスを一つ以上、カンマ区切り | レポートが届かない | まれ。プライバシー上の制限があるため |
| fo | 個々のメールのレポートのオプション | 0、1、d、s | 0 | rufを使う場合のみ |
| psd | パブリックサフィックスのドメインであることを示す | y、n、u | u | パブリックサフィックスか、DNSの一部を他に割り当てる大規模な組織の場合のみ |
緩やかと厳格の違いは次のとおりです。緩やかでは、サブドメインも一致とみなされます。そのため mail.example.com は example.com と一致します。厳格では、二つのドメインが完全に同じである必要があります。
2026年の標準では、古いタグが三つ廃止されました。割合のタグ(pct)、レポート形式のタグ(rf)、レポート間隔のタグ(ri)です。残っている pct=100 は害がありません。100未満の pct は、段階的な導入の間に、メールの一部だけにポリシーを適用するために使われていました。今はその役割を新しい t タグが担います。
多くのドメインに必要なもの:v、p、rua だけです。
- サブドメインに別のルールが必要な場合は、
spかnpを追加します。 psdはそのままにしておきます。必要なのは、DNSの一部を他に割り当てる大規模な組織(psd=n)か、co.ukのようなパブリックサフィックス(psd=y)を運用する場合だけです。- 緩やかな一致(
adkim=rとaspf=r)が初期設定で、ほぼすべてのドメインで問題なく機能します。アライメントのタグが必要なのは、厳しいコンプライアンスのルールでサブドメインによる署名が禁止されている場合だけです。
当社のDMARCジェネレーターを使えば、これらのタグでレコードを作成したり、古いレコードを整理したりできます。
p=none、quarantine、rejectが実際にすること
p タグは、レコードの中で最も重要な部分です。DMARCに失敗したメールをどう扱うかを受信サーバーに伝えます。選択肢は三つで、それぞれが完全な保護に向かう段階です。
p=none:監視のみ。受信側は、失敗したメールを特別に扱いません。通常どおり配信され、適用されるのは通常の迷惑メールフィルターだけです。rua のレポートと組み合わせた状態を、RFC 9989は監視モード(Monitoring Mode)と呼んでいます。配信に影響するリスクなしに、自社のドメインとしてメールを送っているすべてのサービスがわかります。
p=quarantine:迷惑メールフォルダに入れる。受信側は、失敗したメールを疑わしいものとして扱います。ほとんどのメールボックスのプロバイダーでは、受信者の迷惑メールフォルダに入ります。これにより、受信者を偽のメールから守れます。設定が不十分なツールから送られた本物のメールも失われません。迷惑メールフォルダで見つけられるからです。
p=reject:ブロックする。受信側は、失敗したメールを拒否します。多くは配信の途中で、5で始まる恒久的なエラーコードを返します。メールがメールボックスに届くことはありません。代わりに、送信サーバーにバウンスメッセージが返ります。
受信側が必ずポリシーに従うとは限らない
ポリシーはお願いであって、命令ではありません。標準では、受信側は p=reject だけを理由にメールを拒否すべきではないとしています。そのメールについて他に何もわからない場合は、代わりにquarantineとして扱うべきだとしています。メールボックスのプロバイダーは、ポリシーとあわせて、独自の送信者レピュテーションのデータや迷惑メールフィルターも使います。
rejectにSPFだけでなくDKIMが必要な理由
転送するとSPFは失敗します。たとえば、ある人が仕事のメールを個人のアカウントに転送するとします。転送するサーバーは、自分のIPアドレスからメールを送ります。そのアドレスは自社のSPFレコードに載っていないため、SPFのチェックは失敗します。
DKIMは転送されても残ります。署名はメールそのものの中に入っているため、有効なままで、自社のドメインとも一致したままです。そのため、p=reject のドメインはDKIMを使う必要があり、SPFだけに頼ってはいけません。
t=yによるテストモード
RFC 9989はテストモードを追加しました。t=y を設定すると、受信側は公開したポリシーより一段階ゆるく適用します。
rejectはquarantineとして扱われます。quarantineはnoneとして扱われます。
テストモードはレポートを変えません。ポリシーが p=none のときは何の効果もありません。より厳しいポリシーを恒久的にする前に、本物のメールでどう動くかを確認できます。
サブドメイン:spとnp
サブドメインとは、marketing.example.com や support.example.com のように、ドメインの前に付く追加の名前です。多くの企業がサブドメインからメールを送っています。sp タグと np タグは、独自のDMARCレコードを持たないサブドメインのルールを定めます。
受信側が正しいレコードを見つける方法
- 受信側はまず、From行にあるドメインそのもののDMARCレコードを探します。
news.example.comから送っていて、_dmarc.news.example.comが存在すれば、そのレコードを使います。 - そこにレコードがなければ、
_dmarc.example.comにあるメインのレコードを探します。ドメイン名の先頭の部分を一つずつ外し、末尾の方向にさかのぼって見つけます。このときPublic Suffix Listは使いません。 - メインのレコードが見つかったら、送信しているサブドメインがDNSに存在するかを確認します。
そのうえで、適用するルールを選びます。
- サブドメインが存在する場合は、
spを適用します。spがなければpを適用します。 - サブドメインが存在しない場合(DNSが「その名前はない」という意味のNXDOMAINを返す場合)は、
npを適用します。npがなければspを使います。spもなければpを使います。
例
_dmarc.example.com に次のレコードが公開されているとします。
v=DMARC1; p=reject; sp=quarantine; np=reject; rua=mailto:dmarc-reports@example.com
このレコードは三つの別々のルールを定めています。
example.comそのものからのメールにはp=rejectが適用されます。DMARCに失敗すると、受信側はブロックするよう求められます。news.example.comからのメールは、DNSに存在するサブドメインなのでsp=quarantineが適用されます。たとえば、ベンダーの設定ミスでニュースレターが失敗した場合、バウンスせずに迷惑メールフォルダに入ります。invoices-2026.example.comのような架空の名前からのメールは、DNSに存在しないのでnp=rejectが適用されます。本物のサブドメインにはquarantineが適用されていても、誰かが勝手に作ったサブドメインには厳しいルールが適用されます。
DMARCレポートとは?
DMARCのレポートには二つの種類があります。
- 集計レポート。
ruaで設定します。毎日の要約です。 - 失敗レポート。
rufで設定します。失敗した個々のメールについて説明します。
集計レポート(rua)
集計レポートは、Gmailなどの一つのメールボックスのプロバイダーからの要約です。そのプロバイダーが受け取った、自社のドメインから送られたと名乗るすべてのメールを一覧にしています。形式はXMLファイルで、ソフトウェアが読むための構造化されたテキストファイルです。プロバイダーはこれをメールの添付ファイルとして送ります。プレーンな .xml ファイルか、.xml.gz のような圧縮ファイルです。
各レポートは通常、UTCの1日分を対象にしています。標準では、受信側は少なくとも24時間ごとに集計レポートを送るべきだとしています。ただし、送る義務はありません。
短くしたレポートの例は次のとおりです。
<feedback>
<report_metadata>
<org_name>mail.receiver.example</org_name>
<report_id>20261003.example.com</report_id>
<date_range>
<begin>1790985600</begin>
<end>1791071999</end>
</date_range>
</report_metadata>
<policy_published>
<domain>example.com</domain>
<p>none</p>
<sp>none</sp>
</policy_published>
<record>
<row>
<source_ip>192.0.2.10</source_ip>
<count>412</count>
<policy_evaluated>
<disposition>none</disposition>
<dkim>pass</dkim>
<spf>fail</spf>
</policy_evaluated>
</row>
<identifiers>
<header_from>example.com</header_from>
<envelope_from>bounces.esp-mail.example</envelope_from>
</identifiers>
<auth_results>
<dkim><domain>example.com</domain><result>pass</result></dkim>
<spf><domain>bounces.esp-mail.example</domain><result>pass</result></spf>
</auth_results>
</record>
</feedback>
ブロックごとの意味は次のとおりです。
<report_metadata>:レポートはmail.receiver.exampleから送られました。UTCの丸1日分を対象にしています。<policy_published>:受信側がexample.comについて確認したポリシーです。ここではp=noneとsp=noneです。<row>:IPアドレス192.0.2.10から412通のメールが届きました。- SPF:
<auth_results>ではSPFは合格していますが、ドメインはbounces.esp-mail.exampleです。このドメインはFromのドメインであるexample.comではありません。そのため、<policy_evaluated>では、一致しなかったSPFはfailと表示されています。 - DKIM:
<auth_results>では、DKIMはexample.comで合格しています。これは<identifiers>に示されたFromのドメインと一致します。つまりDKIMは合格して一致もしたので、この412通のメールはDMARCに合格しました。
要点は単純です。<auth_results> はSPFとDKIMのチェックそのものの結果を示します。<policy_evaluated> は、それぞれのチェックがFromのドメインとも一致したかを示します。DMARCが使うのは後者です。
失敗レポート(ruf)
失敗レポートは、フォレンジックレポートとも呼ばれ、失敗したメールを1通ずつ説明します。メールのヘッダーや受信者の詳細が含まれることがあります。このプライバシー上のリスクがあるため、多くの受信側は詳細の大部分を取り除くか、失敗レポートをまったく送りません。fo タグはこのレポートのオプションを設定します。関係があるのは ruf を使う場合だけです。
レポートの読み方
標準では、集計レポートは手で読むのではなく、ソフトウェアで読むことを推奨しています。多くのメールボックスのプロバイダーに送っている場合、それぞれが毎日独自のレポートを送ってきます。
DMARCのメールが届くのはなぜ?
毎日このメールが届くのは、DMARCレコードの rua タグに自分のアドレスが入っているからです。自社の名前で送られたメールを受け取ったメールボックスのプロバイダーはすべて、このタグにある各アドレスに毎日の要約を送ります。
件名は、RFC 9990で定められた決まった形式です。
Report Domain: example.com Submitter: mail.receiver.example Report-ID: 20261003.example.com
Submitterは、メールを確認したプロバイダーです。たとえばGoogleやMicrosoftです。XMLのレポートが添付されていて、圧縮されていることがよくあります。
これらのレポートを個人の受信トレイに送らないでください。代わりに、rua の送り先を別のメールボックスか、レポートを処理するサービスにしてください。設定した覚えがない場合は、DMARCレコードを確認してください。以前の管理者や、メールプラットフォームの設定ガイドが追加した可能性があります。
別のドメインにレポートを送る場合
自社のドメインが example.com で、reports.example.net のアドレスにレポートを送りたいとします。この場合、受け取る側のドメインが受け入れに同意する必要があります。同意は、そのドメインのDNSにTXTレコードを公開することで示します。そのレコードがなければ、受信側はそのアドレスを無視し、レポートを送りません。
レコードは次のホスト名に置きます。
example.com._report._dmarc.reports.example.net TXT v=DMARC1
レポートのサービスは、代わりにワイルドカードのレコード(*._report._dmarc.reports.example.net)を公開することがよくあります。この一つのレコードですべての顧客のドメインに対応できるため、ドメインごとの設定は必要ありません。
メールを失わずにp=noneからrejectに進める方法
いきなりrejectにしないでください。一段階ずつ進めてください。
- 監視を始める。
_dmarcにp=noneと有効なruaのアドレスでDMARCレコードを公開します。レポートが届き始め、配信には何の変化もありません。 - 送信元を直す。レポートを読みます。自社のドメインでメールを送っていてチェックに失敗している本物のサービスをすべて見つけ、設定を直します。
- quarantineに進む。本物の送信元がすべて安定して合格するようになったら、
p=quarantineに切り替えます。迷惑メールフォルダを確認し、本物のメールが入っていないことを確かめます。 - rejectに進む。
p=rejectに切り替えます。自社の名前を使った偽のメールは、誰かに届く前にブロックされるようになります。
これには時間がかかることがあります。標準では、送信の頻度によっては、すべての送信元を合格させるまでに何か月もかかることがあるとしています。請求のツール、サポートデスク、マーケティングプラットフォームは見落としやすいので、レポートの確認を続けてください。
利用者がメーリングリストに投稿する場合は、さらにゆっくり進めてください。標準では、p=none で少なくとも1か月、その後quarantineで同じ期間を置くことを提案しています。rejectに進む前に結果を比べてください。メーリングリストは、件名を変えたり、フッターを追加したり、メッセージを再送したりすることがよくあります。こうした変更はSPFを失敗させ、DKIMを失敗させることもあります。数週間分のレポートを比べれば、rejectがメールをブロックし始める前にこれらの問題がわかります。
最後の段階にはテストモードを使ってください。t=y を使えば、受信側にquarantineを適用させたまま、p=reject を公開できます。受信側がrejectにどう反応するかを確認できますが、失敗したメールはバウンスせずに迷惑メールフォルダに入ります。
厳格なSPFについての注意。SPFレコードが -all で終わっている場合、一部の受信側は、DMARCが動く前のSPFのチェックの段階で、失敗したメールを拒否します。そうしたメールはDMARCのチェックに届きません。毎日のレポートにも表示されません。
DMARCレコードのよくある間違い
DMARCレコードが二つある
最初のレコードを編集する代わりに、誰かが二つ目のTXTレコードを追加したときによく起こります。受信側は両方を見つけ、RFC 9989のとおり両方を捨てます。すると、ドメインはDMARCレコードがまったくないのと同じ状態になります。
直し方:DNSを確認し、すべてのタグを一つのTXTレコードにまとめます。
レコードが_dmarcではなくメインのドメインにある
ホスト名に example.com と入力すると、レコードは _dmarc.example.com ではなく、メインのドメインに作成されます。メールサーバーは _dmarc の名前でしかDMARCを探さないため、レコードを見つけられません。
直し方:ホスト名を _dmarc にします。
v=DMARC1が最初にない、または大文字と小文字が違う
v=dmarc1 と入力したり、p=none; v=DMARC1 のように始めたりすると、レコードが壊れます。受信側はそれを無視します。
直し方:レコードのいちばん最初に v=DMARC1 を置き、その後にセミコロンを付けます。
レポートの送り先にmailto:がない
rua=mailto:dmarc@example.com ではなく rua=dmarc@example.com と書くと、アドレスの形式が壊れます。受信側はmailto:のないアドレスを使えないため、レポートが届きません。
直し方:rua と ruf のすべてのアドレスを mailto: で始めます。
許可なく別のドメインにレポートを送っている
ベンダーのドメインにレポートを送っていて、そのドメインが許可のレコードを公開していない場合、レポートは届きません。
直し方:前に説明したとおり、外部のレポートの送り先にはすべて、対応する _report._dmarc のレコードがあることを確認します。
SPFだけでrejectにしている
転送すると、メールを送るIPアドレスが変わるため、転送されたメールはSPFに失敗します。DKIMがなければ、本物の転送メールがDMARCに失敗し、rejectのポリシーのもとでバウンスします。
直し方:p=none から先に進む前に、自社のメールを送るすべてのサービスでDKIM署名を設定します。
古いガイドにある廃止されたタグ
古いガイドの多くは、割合のタグを追加していました。値は100や、段階的な導入なら20などです。残っている pct=100 は害がありませんが、割合による段階的な導入はもう標準の一部ではありません。
直し方:古い割合のタグを削除します。変更を進める間にゆるいポリシーが必要なら、t=y を使います。
よくある質問
DMARCレコードは本当に必要ですか?個人のGmailやOutlookのアカウントにメールを送るなら、必要です。GoogleとMicrosoftはどちらも、1日5,000通以上送る送信者に、Fromのドメインが一致したDMARCレコードの公開を求めています。送信量が少ない送信者も、設定しておくべきです。rua を指定した p=none のレコードには費用がかからず、レポートを見れば、自社の名前でメールを送っている送信元がわかります。
DMARCレコードはどうやって確認できますか?ターミナルで dig TXT _dmarc.yourdomain.com +short を実行するか、Windowsでは nslookup -type=TXT _dmarc.yourdomain.com を実行します。v=DMARC1 で始まるレコードが表示されれば正常です。Gmailのアカウントにテストメールを送り、開いて「メッセージのソースを表示」を選ぶ方法もあります。DMARCに合格したかどうかが表示されます。
DMARC failとはどういう意味ですか?メールが両方のチェックに失敗したという意味です。表示されるFromのドメインと一致するドメインで、SPFもDKIMも合格しなかったということです。その場合、受信側は自社のポリシーに従います。550 5.7.1 Email rejected per DMARC policy for example.com のように、はっきりした拒否を返す受信側もあります。原因はバウンスメッセージを読むことで調べられます。Gmailは、DMARCレコードがない場合はエラーコード 4.7.31 を、Fromのドメインが一致しない場合は 4.7.32 を使います。
DMARCレコードを複数設定できますか?いいえ。一つのドメインが公開できるDMARCレコードは一つだけです。RFC 9989では、受信サーバーが複数のレコードを見つけた場合、そのすべてを捨てなければならないとしています。その結果、ドメインにはDMARCのポリシーがない状態になります。二つ目を追加するのではなく、既存のレコードを編集してください。
DMARCで似たドメインを防げますか?いいえ。DMARCが守るのは、DNSにある自社のドメインそのものだけです。2文字を入れ替えたドメインや、.netのように末尾が違うドメインなど、よく似たドメインを誰かが登録することは防げません。偽の表示名も防げません。似たドメインには、自社の名前をまねた新しいドメインの登録を監視するなど、別の対策が必要です。
DMARCレコードは、メールが本当に自社から送られたことを証明します。もう存在しないアドレスに送ることには役立ちません。次の送信の前にリストをGiggal.ai(英語)にかけて無効なアドレスを取り除き、バウンス率を低く保ってください。
