DMARCを設定していないリスクと、最初に置く設定

診断で「DMARCレコードが設定されていません」と表示された場合、まず知っておきたいことが2つあります。

1つは、DMARCが未設定であることだけを理由に、あなたが送っている正規のメールが直ちに届かなくなるわけではないということです。SPFやDKIMが正しく設定されていれば、受信側はそれらを見て判断します。

もう1つは、それでも未設定の状態では、できないことが確実に2つあるということです。認証に失敗したメールを受信側にどう扱ってほしいかを伝えられないことと、自分のドメインを名乗るメールがどこから送られているかの報告を受け取れないことです。

この記事では、その2つを具体的に説明したうえで、最初に何を置けばよいかまで進みます。

このドメインからメールを送っているかで、置くレコードが変わります

先に分岐があります。ここを取り違えると、設定そのものが変わります。

メールを送っているドメインでは、いきなり強いポリシーを置いてはいけません。認証から漏れている正規の送信元があると、そのメールが届かなくなります。まず p=none を置いて、何が起きているかを見るところから始めます。

一方、メールをまったく送らないドメインでは、その心配がありません。誤ってブロックされる正規のメールが存在しないためです。この場合は最初から p=reject にできます。ただしDMARCだけでは足りず、MXレコードとSPFもあわせて設定します。3点セットの具体的な値はNull MXとは？メールを使わないドメインの正しい閉じ方で説明しています。

以降は、メールを送っているドメインを前提に進めます。

DMARCを設定していないと、できないことが2つあります

認証に失敗したメールをどう扱うか指示できません

DMARCレコードは、SPFとDKIMの認証結果が失敗だったときに、受信側にどうしてほしいかを伝えるものです。この指示を書く場所が p タグで、指定できる値は none(何もしない)、quarantine(隔離する)、reject(拒否する)の3つです(RFC 9989 §4.7)。

レコードが無い場合、この指示自体が存在しません。受信側は、あなたのドメインを名乗る認証失敗メールを受け取ったときに、自分の基準だけで判断することになります。

認証結果の報告を受け取る先を指定できません

DMARCにはもう1つの機能があります。受信側から送信ドメインの持ち主へ、認証結果をまとめて報告してもらう仕組みです。報告の宛先は rua タグで指定します(RFC 9989 §4.7)。

レコードが無ければ rua も書けないため、報告を依頼する手段がありません。自分のドメインが第三者に名乗られているかどうかを知る手がかりが、DNS側には無い状態になります。

誤解しやすいこと

未設定の影響を過大に見積もらないために、起きないことも書いておきます。

受信側が判定をやめるわけではありません。SPFとDKIMはDMARCとは独立して動きます。どちらかが設定されていれば、受信側はそれを見て判断できます。

DMARCを設定しても、第三者があなたのドメインを名乗ってメールを送ること自体は止められません。DMARCが働くのは受信側での判定であって、送信を防ぐ仕組みではありません。

そして、DMARCのポリシーを強めることが受信箱への到達を保証するわけでもありません。RFC 9989 §5.4は「Mail Receivers MAY choose to reject or quarantine a message even if it passes the DMARC validation check」(メール受信者は、メッセージがDMARCの検証を通過した場合でも、そのメッセージを拒否または隔離することを選択してよい)と明記しています。

Gmailの送信者要件に該当するかを確認します

受信側の要件は、送信量によって変わります。ここは競合する解説で最も混乱しているところなので、一次情報のまま書きます。

Googleのメール送信者のガイドラインは、要件を2つに分けています。

1日5,000件を超えるメールをGmailのアカウントへ送る場合は、「ドメインに SPF および DKIM メール認証を設定します」と「送信元ドメインに DMARC メール認証を設定します」の両方が求められます。DMARCのポリシーについては「DMARC 適用ポリシーは none に設定できます」と明記されているので、p=none で要件を満たせます。

1日5,000件未満の場合の要件は「送信元ドメインに SPF または DKIM メール認証を設定します」です。SPFとDKIMのどちらか一方で足り、DMARCは要件に含まれていません。

Yahoo!メール(@yahoo.co.jp)は、通数の基準を公開していません。迷惑メール対策の説明は「SPFかDKIM、もしくはDMARCの認証を導入・判定クリアしていないメールは迷惑メールと判定したり、受信を拒否したりする場合があります」としており、3つのうちいずれか1つを求める書き方です。DMARC単独を必須にしているわけではありません。なお senders.yahooinc.com が公開している送信者要件はYahoo Inc.(@yahoo.com宛)のもので、LINEヤフーが運営するYahoo!メールとは別のものです。

つまり、送信量が5,000件に届かないのであれば、DMARCは受信側の最低要件としては求められていません。それでも、前の節に書いた2つのことができない状態は変わりません。要件を満たすためではなく、自分のドメインで何が起きているかを見るために設定します。

本当に未設定かを確認します

「設定したはずなのに未設定と出る」場合があるため、現在の状態を確認します。

診断で確認する

ドメインを診断すると、DMARCレコードの有無と内容、SPFやDKIMとの関係をまとめて確認できます。未設定であれば、そのドメインに合わせた設定値も表示されます。

自分でコマンドから確認する場合は、_dmarc を付けた名前のTXTレコードを引きます。DMARCレコードは _dmarc で始まる名前のDNS TXTレコードとして公開する決まりです(RFC 9989 §4.5)。

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

「未設定」と「まだ反映されていない」は違います

レコードを追加した直後は、公開DNSにまだ現れていないことがあります。再帰リゾルバは「存在しない」という答えもキャッシュするため、追加前に問い合わせが起きていると、しばらく古い答えが返り続けます。

追加したのに見つからない場合は、DNSが反映されないときの確認方法で、権威サーバーの値と比べて切り分けてください。

サブドメインの場合は上位も見ます

mail.example.jp のようなサブドメインでは、そのサブドメイン自身にレコードが無くても、上位のドメインのポリシーが適用されることがあります(RFC 9989 §4.10.1)。診断はこの探索を行うので、上位から継承している場合はその旨を表示します。サブドメインに固有のポリシーを当てたい場合だけ、個別にレコードを置きます。

SPFとDKIMの状態で、次にすることが変わります

DMARCは、SPFまたはDKIMの認証結果を使って判定します。したがって、その2つがどうなっているかで次の作業が変わります。

RFC 9989の展開手順も同じ順序です。SPFの公開(§5.1.1)とDKIM署名の設定(§5.1.2)、報告を受け取るメールボックスの用意(§5.1.3)を済ませてから、DMARCレコードを公開する(§5.1.4)という並びになっています。

SPFやDKIMの状態がわからない場合は、独自ドメインのメールが届かない原因とDKIMセレクタの確認方法で確認できます。

p=none でレコードを追加します

メールを送っているドメインでの最初のレコードは次の形です。

種類: TXT
ホスト名: _dmarc
値: v=DMARC1; p=none; rua=mailto:{報告の宛先}

{報告の宛先} は、あなたが決めるメールアドレスです。ここは推測で埋められない値なので、そのままコピーせず、実際に受け取れるアドレスに置き換えてください。診断結果の画面では、入力欄に自分のアドレスを入れると、貼り付けられる形の値を生成します。

p=none は「認証に失敗しても、扱いは変えなくてよい」という指示です。何も書いていない状態と違うのは、rua を一緒に置くことで、認証結果の報告を送ってもらえるようになる点です。RFC 9989 §5.1.4は、この p=none と rua の組み合わせから始めるやり方をMonitoring Modeと呼んでいます。

報告の宛先は、普段使っている受信箱とは分けることをおすすめします。届くのはXML形式のファイルで、人が読む前提の文面ではありません。また、自分のドメイン以外のアドレスを指定する場合は、受け取る側にも許可のレコードが必要です。この点はDMARCレポートが届かない原因で詳しく説明しています。

レコードを追加する画面は、ドメインを取得した会社ではなく、いまDNSを管理している会社の管理画面です。診断結果には、ネームサーバーから判定した事業者名と、その事業者向けの手順が表示されます。事業者別のガイドからも探せます。

追加した後に確認します

DNSに設定しただけでは、意図どおり動いているかまでは分かりません。3段階で確認します。

まず、公開DNSからレコードが引けることを確認します。ドメインを診断するか、上に書いた dig で確認できます。ここで見つからない場合は反映待ちの可能性があるため、時間をおいて再度確認してください。

次に、自分宛にテストメールを送り、届いたメールの Authentication-Results ヘッダーを見ます。ここに dmarc=pass や dmarc=fail として、受信側が実際に評価した結果が記録されます。ヘッダーの読み方は独自ドメインのメールが迷惑メールに入る原因にあります。DNSにレコードがあることと、実際のメールがDMARCの判定を通ることは別なので、ここまで確認します。

最後に、報告が届くのを待ちます。報告は受信側が送るものなので、あなたのドメイン宛のメールを扱った事業者からしか届きません。数日待っても何も届かない場合の原因はDMARCレポートが届かない原因にまとめています。

p=none は「未設定」ではありません

診断では、p=none のドメインに「ポリシーが p=none (監視のみ) です」という所見が出ます。これは要修正ではなく、確認をうながす表示です。

設定して間もない時期に p=none であることは、正しい段階です。報告を見ながら、自分が送っているメールがすべて認証を通っているかを確かめている最中だからです。この段階でいきなり quarantine や reject にすると、認証から漏れている正規のメールが止まります。

いつ次の段階へ進むかは、日数では決まりません。報告を見て、正規の送信元がすべて認証を通っている状態が続いていることを確認してから引き上げます。RFC 9989も、報告を集めて分析する段階(§5.1.5)と、強制へ進むかを判断する段階(§5.1.7)を分けて書いています。

実測: .jpドメイン19,065件のうち8,831件で未設定でした

DMARCレコードがどれくらい設定されているかを実際に測りました。

Majestic Millionに掲載されている .jp ドメイン19,065件について、2026年7月27日にDNSを引いた結果、DMARCレコードが見つかったのは10,103件、見つからなかったのは8,831件でした(残り131件は問い合わせに失敗)。割合にすると46.3%が未設定です。

この母集団は被リンクの多い順に並んだ一覧から抽出したもので、.jp ドメイン全体からの無作為抽出ではありません。規模の大きい組織に偏ります。集計値と再現用のスクリプトは実測データのページで公開しています。

多くのドメインが未設定であることは、設定しなくてよい理由にはなりません。この数字が意味するのは、あなたのドメインが珍しい状態ではないということだけです。前の節までに書いた「できないことが2つある」状態は、周りが同じでも変わりません。

まとめ

• DMARCが未設定でも、SPFやDKIMがあれば正規のメールが直ちに止まるわけではありません
• 一方で、認証に失敗したメールの扱いを指示できず、認証結果の報告も受け取れません
• メールを送るドメインは p=none から、送らないドメインは p=reject を含む3点セットで閉じます
• Gmailの要件は1日5,000件を境に変わります。5,000件を超える場合はDMARCが必要で、ポリシーは none で満たせます
• p=none は未設定ではありません。報告を見て、正規の送信元がすべて認証を通ってから次の段階へ進みます

現在の状態はドメインの診断で確認できます。DMARCだけでなく、SPF・DKIM・MXの状態と、それらの関係もあわせて表示します。