転送
- SPF192.0.2.80はexample.comのSPFにない
- DKIM署名は無傷
レポートの表示spf=fail dkim=pass → pass
すべてをDKIM署名する：DKIMは転送に耐えます。ARC（RFC 8617）は転送側が正当性を保証するのに役立ちます。
DMARCチェッカー
ドメインのDMARCレコードを、受信メールサーバーと同じ読み方で確認します：ポリシーはどこにあるか、認証に失敗したメールはどう扱われるか、レポートは誰かに届いているか、ポリシーを強制する前にSPFとDKIMに何が必要か。
情報源：ドメインとその親ドメインの_dmarc TXTレコード（Google Public DNS経由、背後にCloudflare 1.1.1.1） · RFC 9989のツリーウォーク · RFC 9990によるレポートの承認 · SPFとDKIMは当サイトのチェッカーによる結果 · あなたに関する情報は保存されません
DMARCレコードを確認するには？
上の欄にドメインを入力してください：チェッカーはDNSに、_dmarc.にドメインを付けた名前のTXTレコードを問い合わせ、なければ組織ドメインまでさかのぼり（RFC 9989 §4.10）、認証に失敗したメールを受信サーバーがどう扱うかを表示します。
手作業で確認するなら、同じ名前を問い合わせます：dig +short TXT _dmarc.paypal.com、Windowsならnslookup -type=TXT _dmarc.paypal.com。v=DMARC1で始まる応答が1件ならそれがレコードで、2件あると受信サーバーはどちらも使いません（RFC 9989 §4.10）。
digはそこまでです。サブドメインから親へさかのぼらず、レポートの宛先がレポートを受け付けるかも確認せず、受信サーバーがどのRFCに従うかも分かりません。それを補うのがこのチェッカーです。
dig +short TXT _dmarc.example.comこの名前のすべての応答を表示します。v=DMARC1で始まる1件がレコードです。
digで分かること、分からないこと
$ dig +short TXT _dmarc.paypal.com 1
"v=DMARC12; p=reject; rua=mailto:d@rua.agari.com,mailto:dmarc_agg@vali.email; ruf=mailto:d@ruf.agari.com,mailto:MTc4Mzcw@ruf.vali.email3"
$ dig TXT _dmarc.mail.google.com | grep status 4
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN
- 1名前は_dmarc.にドメインを付けたものドメイン自体ではありません：paypal.comのTXTはSPFの置き場所です。
- 2レコードは1件、v=DMARC1が先頭1つの名前に2件あると、受信サーバーは両方を破棄します（RFC 9989 §4.10）。
- 3;で区切られたタグpがポリシー、ruaとrufがレポートの送信先です。
- 4ここにない？ さかのぼる_dmarc.mail.google.comはNXDOMAINです：google.comのレコードが適用されます。
結果の読み方：受信サーバーの視点
最初に1文で答えが表示されます。その下に根拠が続きます：受信サーバーが解釈したとおりのレコード（各タグを実際の文字位置で色分け）、そして紺色の背景には、このドメインについて受信サーバーがたどる経路と、失敗したメールの最終的な扱いが表示されます。
点数はありません：noneのポリシーは失敗ではなく一つの段階であり、経路の下の段階表が次のステップに必要なことを示します。
判定失敗したメールを受信サーバーがどう扱うかを1文で示し、ポリシー、SPF、DKIMをひと目で確認できます。レコード各タグを文字位置ごとに色分け：カーソルを合わせるかタップすると役割が分かります。その下に既定値を表示します。受信サーバーの視点ドメインについて受信サーバーが行うすべてのDNS問い合わせを、順番に応答とともに表示します。DMARCに失敗したメールドメイン自身、存在するサブドメイン、存在しない名前での受信サーバーの扱いです。強制の段階表ドメインがnoneからrejectまでのどこにいるか、次のステップに何が必要かを示します。DMARCは何のために使うの？
DMARCは、From:行にあなたのドメインを使いながら、あなたから届いたことを証明できないメールを、受信メールサーバーがどう扱うかを指示し、そのメールに関するレポートの送り先も伝えます（RFC 9989 §4.7）。
証明に使うのは、From:のドメインとアラインしたSPFまたはDKIMです：同じ組織内のバウンスドメインに対するSPFの合格、またはd=があなたのドメインのDKIM署名。アラインした合格が1つあれば十分です（RFC 9989 §5.3.5）。それ以外はDMARCに失敗し、レコードのポリシーに従って、配信、迷惑メールフォルダー行き、拒否のいずれかになります。
レポートはもう半分の役割です。ruaに対応する受信サーバーは、あなたのドメインを名乗って送信したすべてのサーバーの集計を毎日送ってきます。ポリシーを強制する前に、忘れていた正規の送信元を見つけられます。
2通のメール、同じFrom:行
From: billing@example.comp=reject · rua=mailto:dmarc@example.com
メールサービス経由で送られた本物の請求書カスタムDKIMを設定したサービス経由なので、d=example.comで署名
- SPFpass · bounces.esp.example（アラインしていない）
- DKIMpass · d=example.com（アラインしている）
- DMARCpass：アラインした結果が1つあれば十分
配信
203.0.113.9から送られた偽の請求書example.comが許可していないサーバー
- SPFfail · 203.0.113.9は登録されていない
- DKIMなし · 署名なし
- DMARCfail → p=reject
拒否
550 5.7.1 Email rejected per DMARC policy for example.com
明日の集計レポートがdmarc@example.com宛てに届きます：203.0.113.9からのメール1通、SPF fail、DKIMなし、処理はreject。
DMARCポリシー：p=none、quarantine、reject
p=noneは、失敗したメールを通常どおり配信してレポートだけ送るよう求め、quarantineは不審なメールとして扱う（通常は迷惑メールフォルダー行き）よう求め、rejectはSMTPのやり取りの中で受け付けを拒否するよう求めます。
noneは失敗ではなく一つの段階です：RFC 9989 §7.4は、レポートを受け取りながらnoneで少なくとも1か月、さらにrejectの前にquarantineでも同じ期間を過ごすことを勧めています。メーリングリストに投稿する人がいるドメインは、quarantineでとどめてください。
大手のメールボックスプロバイダーでも分かれています：gmail.comとoutlook.comはドメイン自身にp=none、サブドメインにsp=quarantineを公開し、google.com、yahoo.com、microsoft.comはrejectを公開しています。
偽装メールの行き先
配信p=none
apache.orggmail.comsamsung.com
192件中23件
迷惑メールフォルダーp=quarantine
github.comapple.comamazon.com
192件中30件
拒否p=reject
google.compaypal.commicrosoft.com
192件中139件
DMARCは本当に必要？
はい。Gmail、Yahoo、Outlook.com宛てに大量送信するなら必要です：3社ともDMARCレコードを求めており、p=noneで要件を満たせます。 強制（quarantineまたはreject）は、他人があなたのドメインを名乗って送るのを防ぎ、BIMIのロゴにも必要です。
Gmailは2024年2月1日から、Gmailアカウント宛てに1日5,000通を超えて送信する送信者に求めています。Yahooは2024年2月から、送信量は示さずに求めています。Outlook.comは2025年5月5日から、1日5,000通を超える送信者に求めています。レコードがないと、Gmailは4.7.31（From:がアラインしていない場合は4.7.32）を返し、Outlook.comは550 5.7.515で拒否します。
メールを送らないドメインでは、DMARCは最も手軽な保護策です：example.comが公開しているように、p=reject、Null MX、v=spf1 -allを設定します（M3AAWG）。
各メールボックスプロバイダーが一括送信者に求めること
Gmail2024/02/01Gmailアカウント宛てに1日5,000通超
4.7.31 · 4.7.32Yahoo2024年2月しきい値は非公表
DMARCに合格することOutlook.com2025/05/051日5,000通超
550 5.7.515配信p=none3社すべてのルールを満たす
迷惑メールフォルダーquarantineなりすましの大半を阻止 · BIMIのロゴが可能
拒否reject入口でなりすましを阻止 · BIMI
✓必須：レコード、p=none以上i保護：quarantineまたはreject
DMARC失敗の直し方：転送、メーリングリスト、ベンダー独自のドメイン
集計レポートから失敗している送信元を見つけ、送信側で直します：自社ドメインでDKIM署名するか、組織内のバウンスドメインに移します。 失敗の大半は3つの原因で説明できます。
転送ではDKIM署名は残りますがSPFが壊れるため、DKIMが合格を支えます。メールを書き換えるメーリングリストは両方を壊します。そして、自社のドメインで署名するメールサービスは、あなたではなくサービス自身のDKIMに合格しているだけです：そのサービスのカスタムDKIM（通常はs1._domainkeyのようなCNAME）と独自のリターンパスを有効にしてください。
3つの失敗、レポートに表示される内容、直し方
メーリングリスト
- SPFリストのサーバーが送信
- DKIM本文が変更されハッシュが不一致
レポートの表示spf=fail dkim=fail → fail
From:を書き換えるリストで解決できます。メーリングリストに投稿する人がいるドメインはquarantineにとどめます（RFC 9989 §7.4）。
ベンダー独自のドメイン
- SPFbounces.esp.exampleでpass：アラインしていない
- DKIMesp.exampleでpass：アラインしていない
レポートの表示dkim=pass(esp.example) → fail
ベンダーのカスタムDKIMを有効にする：paypal.comのs1とs2はSendGridへのCNAMEで、SendGridがpaypal.comとして署名します。
サブドメインのDMARC：spとnp
独自のレコードがないサブドメインには、組織ドメインのポリシーが適用されます：存在するサブドメインにはsp、存在しない名前にはnpで、どちらもなければpになります（RFC 9989 §4.7）。
独自のレコードを公開しているサブドメインは、それを自分用に使います。ただし、ある名前とその組織ドメインの間にあるレコードは、その名前には使われません：berkeley.eduのツリーがその例で、eecs.berkeley.eduのsp=noneはwww.eecs.berkeley.eduには届きません（RFC 9989 §4.10.1）。
npは手軽な対策です：存在しない名前から正規のメールが送られることはないため、pがまだnoneでもnp=rejectでそこからの偽装を防げます。RFC 7489の受信サーバーはnpを知らず、spを使います。
受信サーバーが読むberkeley.eduのツリー
berkeley.edup=reject; np=reject; psd=n; rua=…独自のレコード · psd=n：組織ドメイン拒否
www.berkeley.eduレコードなし存在すればsp、なければp拒否
eecs.berkeley.edup=reject; sp=none; rua=…独自のレコード → p拒否
www.eecs.berkeley.eduレコードなしツリーウォーク：eecs.berkeley.eduのレコードはスキップ（組織ドメインではない）→ berkeley.eduのp拒否
nosuch-x7.berkeley.eduNXDOMAIN存在しない → np拒否
eecs.berkeley.eduのsp=noneは適用されません：ある名前とその組織ドメインの間にあるレコードは、その名前には使われません（RFC 9989 §4.10.1）。チェッカーは、これを使われないレコードとして示します。
DMARCレポート（rua）の読み方
集計レポートは、各受信サーバーから毎日届くXMLファイルで、あなたのドメインを名乗ってメールを送ったすべてのサーバー、その通数、SPF、DKIM、DMARCの合否が載っています（RFC 9990）。
送信元ごとに読みます：自社のサーバーやサービスはアラインした合格になるはずです。既知のサービスが失敗していればカスタムDKIMが必要で、p=rejectで失敗している不明なアドレスは、阻止されたなりすましです。レポートサービス（dmarcian、Valimail、EasyDMARC、Postmarkなど）は、何千ものファイルをこの一覧にまとめてくれます。
別のドメインのアドレス宛てのレポートは、そのドメインが同意している場合にだけ届きます：そのドメインがv=DMARC1を値とするyourdomain._report._dmarc.its-hostを公開します（RFC 9990 §4）。チェッカーが代わりに確認し、ない場合は正確なレコードを示します。
1通のレポートを1行ずつ読む
<org_name>google.com</org_name>1
<date_range>10/23 0:00 UTC～10/24 0:00 UTC</date_range>
<policy_published>example.com · p=reject</policy_published>2
<source_ip>198.51.100.24</source_ip> <count>412</count> dkim=pass spf=fail → none3
<source_ip>203.0.113.9</source_ip> <count>37</count> dkim=fail spf=fail → reject4
- 1レポートした相手受信サーバーごとに1日1ファイル（RFC 9990：少なくとも24時間ごと）。
- 2見つかったポリシー_dmarc.example.comで読み取った内容です。
- 3転送されたメール、DKIMで救われる転送元でSPFは失敗しましたが、アラインした署名でDMARCに合格しました。
- 4なりすまし、阻止不明なサーバー、アラインするものはなく、拒否されました。
paypal.comrua=mailto:d@rua.agari.comrua.agari.com
paypal.com._report._dmarc.rua.agari.com TXT "v=DMARC1;"✓ 承認済み：レポートが届きますチェッカーが認識するレポートサービスdmarcianValimailEasyDMARCPostmarkCloudflareMimecastProofpointAgariRed SiftPowerDMARCほか6件
DMARCチェッカー：よくある質問
DMARCとは？
DMARCは、From:行にあなたのドメインを使いながらSPFとDKIMのアライメントに失敗したメールを、受信メールサーバーが配信するか、隔離するか、拒否するかを指示するDNSレコードです。そのメールに関するレポートの送り先も指定します。_dmarcにドメインを付けた名前のTXTレコードとして公開され、2026年5月にRFC 7489に代わったRFC 9989で定義されています。
DMARCレコードチェッカーでは何が分かりますか？
受信サーバーと同じように、_dmarcにドメインを付けた名前のTXTレコードを読み、なければ親ドメインのレコードを読みます。このチェッカーは、タグごとのレコードと既定値、ドメイン自身、サブドメイン、存在しない名前のポリシー、レポートの宛先がレポートを受け付けるか、ドメインのSPFレコードとDKIM鍵を、点数なしで表示します。
DMARCをテストするには？
上でドメインを確認すると、公開されているポリシーが分かります。DNSで答えられるDMARCテストはそこまでです。実際のメールが合格するかは、自分で管理するメールボックスに送ってAuthentication-Resultsヘッダーを読むか、ヘッダーをメールヘッダー解析に貼り付けてください。DMARCバリデーターが確認するのはレコードの構文で、SPFやDKIMがアラインしたかはメールでしか分かりません。
最初はどのDMARCポリシーにすべき？
p=noneとruaアドレスから始めると、配信を変えずに毎日のレポートが届きます。失敗している正規の送信元は、通常そのカスタムDKIMを有効にして直し、quarantine、最後にrejectへ進みます。RFC 9989は、p=noneで少なくとも1か月、そのあとquarantineでも同じ期間を置くことを勧めています。メールを送らないドメインは、すぐp=rejectにできます。
p=noneでドメインは守られますか？
いいえ。p=noneは失敗したメールを通常どおり扱うよう求めるため、偽装メールは受信サーバー独自の迷惑メールフィルターだけで判断されます。得られるのはレポートで、Gmail、Yahoo、Outlook.comの一括送信者ルールは満たせます。監視の段階と考えてください：保護はquarantineから始まり、rejectは偽装メールが誰かに届く前に止めます。
DMARCレコードのt=yとは？
t=yはRFC 9989のテストモードで、受信サーバーは公開されたポリシーより1段階下を適用します。p=rejectはquarantine、p=quarantineはnoneとして扱われます。p=noneには効果がなく、レポートも変わりません。RFC 7489のままの受信サーバーはこのタグを知らず、ポリシーを書かれたとおりに適用します。レポートで全送信元のアラインを確認できたら、t=yを削除してください。
pctタグはまだ使われていますか？
RFC 9989は、0と100以外の値の適用が一貫していなかったため、rfとriとともにpctを削除しました。現在の受信サーバーはpctを無視して、失敗したメールすべてにポリシーを適用します。RFC 7489のままの受信サーバーは割合で適用し、quarantineでpct=25なら失敗したメールの4分の1だけを迷惑メールにして、残りは配信します。pct=100は無害で、テスト段階にはt=yを使います。
ruaアドレスが「未承認」になるのはなぜ？
レポートが別の組織ドメインのメールボックスに送られる場合、そのドメインがyourdomain._report._dmarc.its-hostという名前で値がv=DMARC1のTXTレコードを公開して同意する必要があります（RFC 9990 §4）。ないと、確認する受信サーバーはそのアドレスをスキップします。このレコードはあなたではなく宛先のDNSに置きます。レポートサービスは全顧客分のワイルドカードを公開しているため、通常は入力ミスか提携先のメールボックスが原因です。
サブドメインごとにDMARCレコードは必要ですか？
通常は不要です。レコードがないサブドメインには組織ドメインのポリシーが適用され、存在するサブドメインにはsp、存在しない名前にはnpが使われ、どちらもなければpになります。サブドメインで別のポリシーが必要な場合にだけ、そこにレコードを公開してください。www.team.example.com用のteam.example.comのように、途中の名前にあるレコードは、より深い名前には使われません。
ドメインがDMARCレコードを2件公開するとどうなりますか？
受信サーバーは両方を破棄するため、片方がrejectでも、DMARCのポリシーは適用されずレポートも送られません（RFC 9989 §4.10）。古いレコードを削除せずに新しいレコードを追加したときや、DNSホストが既定のレコードを追加したときによく起こります。_dmarcのレコードは1件にして、もう一方を削除してください。チェッカーは、意図したレコードらしいほうを示します。
SPFが合格なのにDMARCが失敗するのはなぜ？
DMARCでは、From:のアドレスとアラインしたドメインでSPFが合格する必要があります。多くのメールサービスは自社のバウンスドメインで送信するため、SPFはサービス側で合格し、あなたのドメインでは合格せず、DMARCには数えられません。サービスのドメインで署名されたDKIMも同様です。サービスのカスタムDKIMまたは独自のリターンパスを設定して、合格するドメインを自分のものにしてください。
レコードを追加したのに、チェッカーでは「レコードなし」と出ます。なぜ？
まずホスト欄を確認してください：多くのDNS管理画面では_dmarcだけを入力し、_dmarc.example.comと入力すると_dmarc.example.com.example.comが作られます。次に、古い応答の期限切れを待ってください：その名前が以前に問い合わせられていると、リゾルバーはゾーンのネガティブTTL（多くは5分から1時間）の間、NXDOMAINを保持します。SERVFAILやタイムアウトは「確認できません」と表示され、レコードなしとは表示されません。