No DMARC record found：ドメインに足りない1行

要点

• このメッセージは、_dmarc.yourdomain.comにTXTレコードがないという意味です。メールサーバーが壊れているわけではありません。
• ホスト名を_dmarc、値をv=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comとしたTXTレコードを1つ追加します。p=noneなら、配信はこれまでとまったく変わりません。
• Gmail、Yahoo、Outlook.comがこのレコードを必須としているのは大量送信者だけです。それでも追加しておきましょう。Googleはドメイン全体で数え、大量送信者の扱いを解除することはありません。また、レポートはレコードができてから届き始めます。
• チェックツールがまだ何も見つけない場合は、DNSを編集した場所の間違い、ホスト名の重複、DMARCレコードが2つあることを疑ってください。レコードが2つあると、互いに打ち消し合います。
• 標準規格は2026年5月のRFC 9989で変わりました。pctはなくなり、tとnpが新たに加わりました。Googleのヘルプは、2026年10月時点でもpctを説明しています。

「No DMARC record found」（DMARCレコードが見つかりません）は、チェックツールがDNSに_dmarc.yourdomain.comのTXTレコードを問い合わせ、何も返ってこなかったという意味です。メールサーバーが壊れているわけではありません。対処は、ホスト名を_dmarc、値をv=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comとしたTXTレコードを1つ追加することです。p=noneなら、メールはこれまでとまったく同じように配信されます。DMARCに対応していることを受信側に伝え、レポートが届き始めるだけです。

DMARCは、SPF、DKIMと並ぶ、メール用の3つのレコードの3つ目です。SPFは、あなたのドメインから送信してよいサーバーの一覧です。DKIMは、メッセージ1通ごとに署名を付けます。DMARCは、そのどちらもFromアドレス（差出人アドレス）のドメインを保証しないときにどうすべきか、そして1日分のまとめをどこに送るかを、受信側に伝えます。2026年5月からはRFC 9989で定義されており、これが旧版のRFC 7489に置き換わりました。多くの解説はまだ旧版をもとにしており、2026年10月時点ではGoogleのヘルプページも同様です。

追加するレコード

ドメインのDNSを管理しているサービスにログインします。ネームサーバーが向いている先の会社のことで、ドメインを購入した会社と同じとは限りません。次の値で新しいレコードを追加します。

ゾーンファイルの1行として書くと、完成したレコードは次のようになります。

_dmarc.example.com.  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

example.comは自分のドメインに置き換えてください。3つの部分の役割は次のとおりです。

• v=DMARC1は、この行がDMARCレコードであることを示します。先頭に置き、DMARC1は大文字で書く必要があります。そうなっていないと、受信側はレコード全体を無視します。
• p=noneはポリシーです。「私のメールは、これまでどおりに扱ってください」という意味です。このレコードが原因で、メールがブロックされたり迷惑メールに振り分けられたりすることはありません。
• rua=mailto:…は、日次レポートの送り先アドレスです。レコードを公開する前に、このアドレスか、自分に転送されるエイリアスを作成しておいてください。

GoogleもDMARCを設定するのページで、同じ3つの項目を挙げています。また、DMARCを追加する前に、SPFとDKIMが48時間動作していることを求めています。チェックツールがこの2つも指摘している場合は、先にそちらを直してください。

反映されたか確認する方法

自分でDNSに問い合わせます。macOSやLinuxでは、ターミナルを開いてdigを使います。Windowsではnslookupを使います。

dig +short TXT _dmarc.example.com
nslookup -type=TXT _dmarc.example.com

レコードが公開されていれば、その行が引用符付きで返ってきます。次は、2026年10月5日にGoogle自身のドメインが返した応答です。

$ dig +short TXT _dmarc.google.com
"v=DMARC1; p=reject; rua=mailto:mailauth-reports@google.com"

応答が空なら、レコードがまだないか、受信側が探す場所にありません。自分の問い合わせでその行が表示されたら、メッセージを出したチェックツールをもう一度実行してください。たとえばMXToolboxは、この問題を「No DMARC Record found」と表示し、「あなたのドメインには、公開されたDMARCレコードがありません」と説明しています。

DMARCレコードの各部分の意味

レコードは、セミコロンで区切ったtag=valueの組を並べたものです。標準規格で必須なのはvだけで、先頭に置かなければなりません。pは2番目に置いてください。Googleのヘルプは「vタグとpタグは最初に記載する必要があります」と述べており、旧版の標準規格も同じ順序を前提としていました。RFC 9989のセクション4.7にあるタグは次のとおりです。

古いレコードは、pct=100で終わっていることがよくあります。このタグは、failしたメールの一部にだけポリシーを適用するためのものでした。RFC 9989は、これをrf、riとともに削除し、その理由を示しています。

運用の経験から、「pct」タグは、指定された値が0または100（既定値）の場合を除いて、たいてい正確には適用されていないことが分かりました。それ以外の値での不正確さは、実装によって大きく異なっていました。

受信側は知らないタグを無視しなければならないので、古いpct=100が残っていても害はありません。yahoo.comとmicrosoft.comのレコードには2026年10月5日時点でもこのタグがあり、Googleのヘルプページは今も、段階的な導入にpctを勧めています。新しいレコードでは省いてください。

1日に数通しか送らなくてもDMARCは必要か

大手メール事業者が公開しているルールでは、DMARCレコードが必須になるのは大量送信をする場合です。それ未満では推奨にとどまります。

出典は、Googleのメール送信者のガイドライン、YahooのSender Best Practices（送信者向けのベストプラクティス）、Microsoftの大量送信者向けの発表で、いずれも2026年10月時点のものです。1つのメールボックスから1日30通を送る程度なら、どこもこのレコードを要求していません。それでも、今のうちに追加しておく理由が3つあります。

• しきい値はドメイン単位で数えられ、リセットされません。Googleは、同じプライマリドメインから個人のGmailアカウントに届くメッセージを、サブドメインの分も含めてすべて合算します。Googleの送信者向けFAQにはこうあります。「上記の条件を一度でも満たした送信者は、恒久的に大量送信者とみなされます。」
• GoogleもYahooも、すべての送信者に推奨しています。Googleは「ドメインには常にSPF、DKIM、DMARCを設定することをおすすめします」と書いています。Yahooは「メールを送信するドメインごとにDMARCポリシーを公開することを、すべての送信者に強く求めます」と述べています。
• レコードがなければレポートは届きません。レポートがあって初めて、どのサーバーがあなたのドメインをFrom欄に入れてメールを送っているかが分かります。自分のツールも、見知らぬ第三者も含めてです。

大量送信者の場合、レコードがないと実害があります。Googleの送信者向けFAQは、これに対する一時的なエラー4.7.31を挙げています。「送信ドメインにDMARCレコードがないか、DMARCレコードでDMARCポリシーが指定されていません」。同じページによると、2025年11月以降、要件を満たさないメールは「一時的および恒久的な拒否」の対象になります。

レコードを追加したのに、チェックツールがまだ何も見つけない場合

たいてい、次のどれかが原因です。上のdigの問い合わせを使って、順に確認してください。

• DNSを編集した場所が違います。ネームサーバーが、ドメインを取得した会社（レジストラ）とは別の会社にある場合、レジストラ側で入力したレコードは問い合わせの対象になりません。dig +short NS example.comで、あなたのドメインについて応答しているのがどこかが分かります。
• ホスト名が間違っています。レコードがexample.comそのものに置かれているか、上で説明したように名前が重複しています。受信側が問い合わせるのは_dmarc.example.comだけです。
• DMARCレコードが2つあります。この点で標準規格は厳格です。「1つの対象について複数のDMARCポリシーレコードが返された場合、それらはすべて破棄されます。」1つにまとめてください。レポート用のアドレスが2つある場合は、カンマで区切って1つのruaに入れます。
• 最初のタグが正確にv=DMARC1になっていません。小文字で書かれている、DMARC 1のような入力ミスがある、その前にp=がある、といった場合はレコードが無効になります。
• レコードの種類がTXTではありません。または、値を文書から貼り付けたために、曲がった引用符（“ ”）が入っています。値はプレーンテキストで入力し、DNSを管理しているサービスのヘルプで求められていない限り、引用符は付けないでください。
• 古い応答がまだキャッシュに残っています。リゾルバは、「そのレコードは存在しない」という応答をしばらく覚えています。問い合わせにネームサーバーの名前を付けて、自分のネームサーバーの1つに直接尋ねてください。たとえばdig +short TXT _dmarc.example.com @ns1.example.netです。そこでレコードが表示されれば、チェックツールもいずれ追いつきます。

レポートの届き先と、その使い方

あなたのドメインをFrom欄に持つメールを受け取った受信側は、それぞれruaのアドレスにレポートを送ります。GoogleのDMARCレポートについてのページによると、レポートは「通常、1日1回メールで送信されます」。レポートはXMLファイルで、たいてい圧縮されてメールに添付されています。形式はRFC 9990に記載されています。

Googleは、大きな組織では「毎日、数百から数千件ものレポートが届くことがあります」と注意し、グループや専用のメールボックスを勧めています。件数は、送信数と送信先ドメインの数で決まるので、メールボックスが1つか2つなら、はるかに少なくなります。dmarc@のようなエイリアスを作り、フィルタで専用のフォルダに振り分ければ十分です。

アドレスは、レコードと同じドメインのものにしましょう。レポートを別の場所で受け取りたい場合は、その別のドメインが専用のレコードを公開して、同意を示す必要があります。それがなければ、受信側はそのアドレスを無視しなければなりません（RFC 9990のセクション4）。

example.com._report._dmarc.otherdomain.net.  IN  TXT  "v=DMARC1;"

無料のGmailアドレスがレポート用アドレスとして使えないのは、このためです。2026年10月5日に私たちが確認した時点で、gmail.comはこのようなレコードを公開していませんでした。

ファイルの中では、recordブロック1つが送信サーバー1台を表します。IPアドレス、メッセージ数、そしてpolicy_evaluatedの下に、あなたのドメインについてDKIMとSPFがpass（合格）したかどうかが入っています。探すものは2つです。心当たりのあるサーバーにfailが出ていれば、修正が必要です。その方法はSPFとDKIMがpassなのにDMARCがfailになるときで説明しています。心当たりのないサーバーは、忘れていたツールか、あなたの名前を使っている誰かです。

p=noneの次：ポリシーを厳しくするタイミング

p=noneは監視用のモードです。メール事業者が求める最低限は満たしますが、あなたのアドレスの偽装を止めることはできません。それができるのは、failしたメールを疑わしいものとして扱うよう受信側に求めるp=quarantineと、拒否するよう求めるp=rejectだけです。

厳しくする前に、正規の送信元すべてがpassしている必要があります。RFC 9989は、こうした不備について、ポリシーを適用しようと「試みる前に必ず対処しなければならない」とし、送信の頻度によっては、確信が持てるまでのレポートに「何か月もかかることがある」としています。Googleの導入手順のページは、1週間分のレポートで「通常は十分」としています。メールボックスが1つでツールが1つか2つなら、Googleの数字のほうに近くなります。それでも、月次の請求書送信や問い合わせフォームの分もレポートに現れるように、数週間は様子を見てください。

具体的な進め方については、2つの情報源の説明が食い違っています。Googleは今も、p=quarantine; pct=5から始めて数値を上げていく方法を勧めています。標準規格はpctを廃止し、代わりに次の書き方を用意しています。

v=DMARC1; p=quarantine; t=y; rua=mailto:dmarc@example.com

t=yは、当面はfailを1段階ゆるく、つまりnoneとして扱うよう受信側に求めます。レポートに問題がない状態が続いたら、t=yを外します。注意点があります。このタグを知らない受信側は、タグを無視してquarantineをそのまま適用します。また、2026年10月時点で、Googleのページはtに触れていません。厳しいポリシーにすると、まだ直せないメールに影響が出る場合は、p=noneのままにしてください。

WarmupBayの役割

メールボックスを接続すると、WarmupBayはそのドメインのSPF・DKIM・DMARCを確認します。DMARCレコードがない場合は、コピーして使える完成したレコードを表示します。そのままウォームアップを始めてもかまいません。72時間たってもレコードがない場合、ウォームアップは停止します。

WarmupBayが、あなたの代わりにレコードを追加することはできません。DNSはあなたのものだからです。DMARCレポートを収集したり読んだりすることもありません。WarmupBayが担うのは、レコードを整えた次の段階です。あなたのメールボックスが、共有プール内の他のメールボックスと1日に数通のメールを交換します。3通から始まり、1日に1通ずつ増えるので、送信活動が徐々に積み上がります。毎日10通までは無料です。チェックとウォームアップの内容をご覧いただくか、レコードを設定したらメールボックスを接続してください。

よくある質問

example.comのDMARCレコードは、news.example.comのようなサブドメインにも適用されますか？

はい。受信側はまず_dmarc.news.example.comのレコードを問い合わせます。なければ、組織ドメインであるexample.comのレコードを使います。サブドメインに適用されるポリシーは、spを設定していればその値、設定していなければpの値です。

ruaのアドレスなしでv=DMARC1; p=noneを公開できますか？

はい。有効なレコードで、ポリシーを公開したものとして扱われます。ただしレポートは届かないので、自分のメールがpass（合格）しているか、ほかに誰があなたのドメインを使っているかは分かりません。Yahooは有効なruaアドレスを強く推奨するとしており、Googleも常に含めることを勧めています。

アウトリーチ（営業メール）にだけ使っている2つ目のドメインにも、DMARCレコードは必要ですか？

はい。受信側はメッセージごとにFromアドレス（差出人アドレス）のドメインを調べるので、メインのドメインにあるレコードは別のドメインには適用されません。2つ目のドメインにも同じ1行を使ってください。そのレポートをメインのドメインのアドレスで受け取りたい場合は、「レポートの届き先」で説明している承認用のレコードを、メインのドメイン側で公開する必要があります。

メールをまったく送信しないドメインでは、何を公開すべきですか？

厳格な組み合わせです。M3AAWGは、メールをまったく送信しないドメインについて、SPFレコードv=spf1 -allと、p=rejectのDMARCレコードを推奨しています。誰もFromアドレスに使えないようにするためです。DMARCでは、_dmarcにv=DMARC1; p=rejectという1行を置きます。

p=noneは、p=quarantineやp=rejectよりメールにとって不利ですか？

Gmail、Yahoo、Outlook.comが公開している送信者向けルールが求めているのは、最低でもp=noneであり、それより厳しいものは求めていません。ポリシーが決めるのは、DMARCにfail（不合格）したメールの扱いです。あなたの名前をかたった偽装メールもここに含まれます。それ以上が必要になる機能が1つあります。メッセージの横にロゴを表示するBIMIです。Googleのヘルプによると、BIMIにはquarantineまたはrejectが必要です。

出典

1. RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance (DMARC), May 2026
2. RFC 9990: DMARC Aggregate Reporting, May 2026
3. Email sender guidelines – Gmail Help
4. Email sender guidelines FAQ – Gmail Help
5. Set up DMARC – Google Workspace Help
6. Recommended DMARC rollout – Google Workspace Help
7. About DMARC reports – Google Workspace Help
8. Troubleshoot DMARC issues – Google Workspace Help
9. Sender Best Practices – Yahoo Sender Hub
10. Strengthening Email Ecosystem: Outlook's New Requirements for High-Volume Senders – Microsoft Community Hub
11. DMARC Record Published – MXToolbox
12. M3AAWG Email Authentication Recommended Best Practices, September 2020 (PDF)
13. M3AAWG Protecting Parked Domains Best Common Practices, December 2015 (PDF)