DMARCチェック（無料）

どのドメインでもDMARC設定をチェック。公開TXTレコードのポリシーとタグを検証し、修正点を表示します。DNSをその場で照会、読み取り専用・登録不要。

最新の公開DNS読み取り専用登録不要

DMARCチェックでわかること

DMARCチェックは、_dmarc.yourdomain.co.jpに公開されたTXTレコードを照会し、構文とポリシータグを検証します。p、sp、rua、aspf、adkimなどの値の意味も解説します。わかるのは、その時点でDNSが公開している内容までです。本番のメールがDMARCをパスするかどうかや、正規の送信元をすべて特定することはできません。

結果の見方

結果	意味	対処法
v=DMARC1; p=reject	最も厳格な要求：DMARCに失敗したメールの拒否を、対応する受信側に求めます。	ruaレポートを継続し、新しい送信元は利用開始前に確認します。
p=quarantine	一段緩い要求：失敗したメールを不審なメールとして扱うよう受信側に求めます（多くは迷惑メールフォルダへ）。	p=rejectを検討する前に、業務の送信サイクルを一巡分確認し、正規の送信元をすべて検証します。
p=none	監視のみ：p=noneはDMARCによる隔離や拒否を求めません。ただし受信側が別の仕組みで振り分けや拒否をする場合があります。	レポート上の全送信元でSPF/DKIMアライメントを修正し、quarantineへ引き上げます。
DMARCレコードなし	DMARCの処理方針も集計レポートの送信先も公開されていません。現行の大量送信者向け要件のうち、DMARCポリシーの項目も満たしていません。	_dmarc.yourdomain.co.jpに、ruaを指定したv=DMARC1; p=noneをまず公開し、段階的に引き上げます。
DMARCレコードが重複	RFC 9989では、DMARCレコードが複数あるとポリシー探索時にすべて破棄されます。	_dmarcのTXTレコードは1つ残して削除します。
構文エラー	必須のタグや値が不正だと、ポリシーとして使えないことがあります。v=DMARC1を先頭に置き、pには有効なポリシー値が必須です。	解析エラーの内容を確認して該当タグを書き直し、有効なレコードを1つだけ公開します。
不明なタグ	RFC 9989は、認識できないタグを無視して既知のタグの処理を続けるよう受信側に求めています。不明なタグがあるだけでは、レコードは無効になりません。	意図して設定したタグか確認します。入力ミスや、相互運用上の役割がなくなったタグであれば削除します。
旧来のpctタグ	中間の適用割合の扱いが受信側ごとにばらついたため、RFC 9989でpctは廃止されました。	段階的な移行は、レポートと計画的なポリシー変更で進めます。相互運用性を確認したうえで、旧来のpctを削除します。
rua未設定	集計レポートを要求していないため、送信元の棚卸しやポリシー変更の判断材料が不足します。	rua=mailto:…を追加し、データを根拠に強化を判断します。
spがpより緩い	このレコードが組織ドメインまたはPSDで選択された場合、既存のサブドメインには組織ドメインより緩いポリシーを要求することになります。	正規の送信元があるサブドメインを洗い出したうえで、意図したspポリシーを残すか、該当する親ドメインのポリシーに委ねます。

このツールで確認できること

このツールでわかるのは、DMARCポリシーのホスト名で公開DNSが返す内容と、タグが有効なポリシーとして解析できるかです。解釈は現行の RFC 9989（DMARC標準）に準拠しています。本番メールがSPFやDKIMをパスしたかの証明、正規の送信元すべての特定、受信側の非公開な処理判断の予測はできません。実際のメールの確認にはメールヘッダー解析を、集計レポートの確認には DMARCレポート解析をご利用ください。レコード自体がない、または不正な場合は、こちらで作り直せます： DMARC生成ツール。

1ドメインを超えたベンチマークには、Palisadeの State of DMARC 2026 をご覧ください。上位10万ドメインのポリシー強化状況を分析し、調査手法も公開しています。

チェック結果から、ポリシー強化の運用へ

1回のチェックでわかるのは、今日時点の問題です。本当の作業は、その先のポリシー強化です。集計レポートを読み解き、正規の送信元すべてでSPFとDKIMのアライメントを整え、正常なメールを止めずにポリシーを引き上げていく必要があります。Palisadeはこれらのレポートを、優先順位付きのワークフローに変えます。担当者は送信元の特定、アライメント失敗の調査、提案されたレコード変更のレビューを進め、根拠をもって各ドメインのポリシーを強化できます。

MSP向けにはマルチテナントで設計。全顧客ドメインのチェック、修正、ポリシー強化を1つの管理画面で行えます。顧客ドメイン単位の料金は規模に応じて単価が下がり、顧客のメール送信量による課金はありません。

実務まで担うDMARCソフトウェア

PalisadeはDMARCレポートの内容を、送信元とアライメントの対応タスクに優先度順で整理します。担当者は1つの画面で変更内容を確認しながら、ドメインのポリシーを強化していけます。

今すぐ開始デモを予約

ドメイン診断は無料・カード不要。カード登録で15日間のトライアル開始。

DMARCチェックは何を調べますか？

_dmarc.yourdomain.co.jpに公開されたTXTレコードを照会し、p、sp、rua、aspf、adkimなどのタグを検証します。DNSに現在公開されているポリシーは確認できますが、実際のメールがSPF、DKIM、DMARCをパスしたかどうかは証明できません。

p=rejectにすれば、失敗したメールは必ず拒否されますか？

いいえ。p=rejectは、DMARCに失敗したメールの拒否を受信側に求める、ドメイン所有者の意思表示です。最終的な処理は受信側が決めます。公開前に、正規の送信経路すべてでSPFかDKIMがアライメント一致でパスすることを確認してください。

自社メールがDMARCをパスすると証明できますか？

いいえ。公開レコードが有効でも、実際の送信元のReturn-PathやDKIM署名ドメインが、表示上のFromドメインと一致しなければDMARCに失敗します。本番の送信経路からテストメールを送り、Authentication-Resultsヘッダーを確認してください。

DMARCアライメントとは？

DMARCアライメントでは、表示上のFromドメインと、認証済みのSPFドメインまたはDKIM署名ドメインを照合します。SPFとDKIMのどちらかが認証にパスし、かつアライメントも一致すれば、DMARCはパスです。relaxedでは同じ組織ドメインなら一致とみなし、strictではドメインの完全一致が必要です。

複数のDMARCレコードはなぜ無効ですか？

DMARCポリシーの探索は、1つの名前に有効なTXTレコードが1つだけあることを前提とします。RFC 9989では、同じ場所に複数のポリシーレコードがあると、すべて破棄されます。タグを_dmarcの1レコードにまとめ、重複を削除してください。

p=noneで十分？

p=noneは、DMARCに失敗したメールに隔離や拒否を求めないポリシーです。ただし受信側が別の仕組みで振り分けや拒否をする場合があります。ruaアドレスを指定すれば、集計レポートも要求できます。レポートで正規の送信元を洗い出してアライメントを整え、データ上の問題がなくなってから、quarantine、rejectへ慎重に移行します。

ポリシー強化の前に、集計レポートをどう活用しますか？

集計レポートで送信元を特定し、正規の送信元ごとに担当者を決めて、SPF、DKIM、アライメントの失敗を調べます。重要な送信経路は、実際のメールヘッダーでも確認します。ポリシーの変更は、業務の送信サイクルを一巡し、正規のメールに問題がないと確認できてからにしてください。

RFC 9989の変更点は？

RFC 9989は2026年5月、RFC 7489に代わる標準化過程のDMARC仕様になりました。DNSツリーウォークでポリシーを探索し、np、psd、tタグを定義し、旧来のpctタグを廃止しています。集計・失敗レポートはRFC 9990とRFC 9991で規定されています。

DMARCでフィッシングやBECをすべて防げますか？

いいえ。DMARCは、対応する受信側で、保護対象ドメインを直接かたるなりすましを減らせます。ただし類似ドメイン、表示名の偽装、乗っ取られたアカウントなど、あらゆるフィッシング手法を防げるわけではありません。DMARCはドメイン認証の仕組みの1つで、メールフィルタや万能のフィッシング対策ではありません。

DMARCレコードで使えるすべてのタグと、その役割を解説します。

vバージョン: バージョンタグはDMARCレコードに必須で、値は「DMARC1」に限られます。値が正しくない場合やタグがない場合、DMARCレコードは無効とみなされ、無視されます。
pポリシー: DMARCポリシータグは、DMARCに失敗したメールについて3つの値を取ります。noneは隔離・拒否を求めず、quarantineは不審なメールとしての扱いを、rejectは受信拒否を求めます。最終的な処理は受信側が決め、p=noneでも別の仕組みで振り分けや拒否をする場合があります。集計レポートは、ruaタグで別途要求します。
rua集計レポートの送信先: 集計レポートの送信先は「mailto:」形式のURIで指定します。メールサービスプロバイダー（ESP）は、この宛先に集計レポートを送ります。このタグは必須ではありませんが、省略するとレポートは届きません。
ruf失敗レポートの送信先: 失敗（フォレンジック）レポートの送信先は「mailto:」形式のURIで指定します。メールサービスプロバイダー（ESP）は、この宛先に失敗レポートを送ります。このタグは必須ではありませんが、省略するとレポートは届きません。
spサブドメイン: サブドメインのポリシーは、特に指定がない限り、前述のメインドメインのポリシータグ（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回です。