「DMARC ポリシーが有効になっていない」：チェッカーが意味すること、正直な最初の 5 分ステップ（2026）

公開日 2026-07-08

データ基準日：2026-06-29 · 方法論 v7。 261 百万件のグレード済みドメインに対する集計センサスデータ。グレード方法についてはこちら。

「DMARC ポリシーが有効になっていない」とは 2 つの異なることを意味します：ドメインに DMARC レコードが全くないか、p=none に設定されたレコードがあるかです。Defaults.Exposed センサスによると、ドメインの 10.59% のみ — 261,086,232 件中 27,640,987 件 — が DMARC ポリシーを強制しています。モニタリングレコードの公開には 5 分かかります；強制はプロジェクトです。

このガイドでは警告を解読し、公開すべき正確な TXT レコードとその場所、最初の試みを失敗させる構文ミスを解説し、最初の 1 週間の DMARC レポートがどのように見えるかについて正直な期待を設定します。これは意図的に「5 分で DMARC を修正する」ガイドではありません — 5 分で可視性を得られますが、保護ではありません。

「DMARC ポリシーが有効になっていない」とは実際に何を意味するか？

MXToolbox などのチェッカーは 2 つの異なる状況を 1 つのオレンジの警告にまとめており、修正パスはどちらにいるかによって異なります：

チェッカーが表示するもの	実際の意味	影響を受けるドメイン（261,086,232 グレード済みのうち）
「DMARC レコードが見つかりません」	`_dmarc.yourdomain` には何も公開されていない。受信者はポリシーを適用せず、レポートを送りません。自分のメール問題に対して見えません。	196,105,162（75.11%）
「DMARC ポリシーが有効になっていない」/「ポリシーが none」	レコードが存在するが `p=none` と言っている：レポートが有効で、保護がオフ。受信者は以前と同様ににスプーフィングされたメールを配信します。	37,312,637（14.29%）
「ポリシー：quarantine」または「reject」	強制されたポリシー。受信者が失敗に対して行動します。	27,640,987（10.59%）

データ基準日：2026-06-29。

最初の行がインターネットのほとんどが存在する場所です：グレード済みドメインの 75.11% が DMARC レコードを全く公開せず、さらに 14.29% が p=none にいます。最後の行の逆が重要な数字です：89.41% のドメインに強制された DMARC ポリシーがありません — 261,086,232 件のグレード済みドメインのうち。チェッカーが警告を示す場合は、圧倒的多数にいます。それは安心ではありません；スプーフィングが安価なままである理由です。

後で混乱を避けるための 1 つの明確化：DMARC は SPF と DKIM の上のポリシーレイヤーで、受信者が実際に見る From ヘッダーに対して確認されます。「有効になっていない」とはまだ受信者に何もするよう指示していないことを意味します。3 つのポリシー値が初めての場合は、平易な英語の解説 DMARC: none、quarantine、reject とはをご覧ください。

5 分で正直に修正できるものは何か？

レコードを公開することです。それが正直な主張の全てです。

v=DMARC1; p=none; rua=mailto:[email protected]

この TXT レコードが有効になってから 5 分後、DMARC をチェックする受信者があなたのドメインとしてメールを送信しているすべての人 — 正当なサーバーとなりすまし者 — についての日次レポートを作成し始めます。その可視性は本当に価値があり、本当に即座です。

しないこと：p=none は何も保護しません。スプーフィングされたメールは昨日と同じように配信され、チェッカーが明日再スキャンしても「ポリシーが有効になっていない」とまだ言うかもしれません — 正しくです。なぜなら緑のチェックは quarantine または reject のために予約されているからです。p=none は保護ではないに理由を書いています；実際にスプーフィングをブロックするポリシーへの段階的なパスは p=none から p=reject へです。以下の 5 分ステップは始め方です；そのガイドは終わらせ方です。

最初の DMARC レコードを公開する方法

DNS に触れる前に無料スキャンを実行する。 実際にどちらの状況にあるか — レコードなし vs. p=none — と、その下に SPF と DKIM があるかを教えてくれます。後で強制に移動できる速さを決定します。
レポートを受け取るアドレスを選ぶ。 dmarc-reports@yourdomain のような専用メールボックスで始めるのが良いです。代わりにレポート分析サービスを使う場合は、以下の FAQ を参照してください — サードパーティのアドレスには気づきにくい落とし穴があります。
ホスト _dmarc に TXT レコードを追加する。 ほとんどの DNS コントロールパネルで（IONOS の DMARC セットアップガイドに実例があります）、ホスト/名前フィールドに _dmarc を入力します — パネルがあなたのドメインを自動的に追加し、_dmarc.yourdomain.com が生成されます。値：v=DMARC1; p=none; rua=mailto:[email protected]
解決されたことを確認する。 dig TXT _dmarc.yourdomain.com（または任意のオンラインチェッカー）が v=DMARC1 で始まるレコードを 1 つ正確に返すはずです。ほとんどの DNS 変更は数分以内に見えます；低い TTL が助けになります。
再スキャンする。 レポートはモニタリングモードの DMARC を示します — 現在どこにいるかの正直な反映：レポートが有効、強制が保留中。

1 つのレコードがサブドメインもカバーします：mail.yourdomain.com にレコードを見つけられない受信者は組織ドメインのポリシーにフォールバックするため、モニタリングを始めるためにサブドメインごとにレコードは必要ありません。

レコードを追加するときの最もよくあるミスは？

ほぼすべての最初の失敗はこれらのうちの 1 つです — そして重要です。なぜなら解析できないレコードはレコードなしとして扱われるからです。センサスは解析に失敗する 48,648 件の公開された DMARC レコードをカウントしています；実際に公開されるスペルミスは DMARC タイポセンサスにカタログされています。

間違ったホスト。 レコードは _dmarc.yourdomain.com に存在しなければなりません。頂点には置けません。裸のドメインでは何もしません。
ドメインの二重追加。 自動追加するパネルに _dmarc.yourdomain.com を入力すると _dmarc.yourdomain.com.yourdomain.com になります。_dmarc だけを入力してください。
セミコロンの代わりにコンマ。 タグは ; で区切られます。解析できないレコードはレコードなしとして扱われます。
v=DMARC1 の欠落または位置ミス。 最初のタグでなければならず、正確にスペルされている必要があります；p= で始まるレコードは解析に失敗します。
rua から mailto: が欠落。 rua=dmarc@yourdomain は無効；rua=mailto:[email protected] でなければなりません。
2 つの DMARC レコード。 複数の v=DMARC1 レコードを見つけた受信者はすべてを無視します — マルチレコード SPF と同じ失敗ファミリー。
コピー＆ペーストからのスマートクォート。 ドキュメントから混入したカーリークォートまたは非改行スペースが解析を壊します。チェッカーが正しく見えるが不正形式と言う場合はレコードを打ち直してください。

最初の 1 週間、rua レポートはどのように見えるか？

今期待値を設定して、壊れていると結論付けないようにしてください：

受信者ごとに毎日約 1 回届きます。 Google は通常 24 時間ごとに 1 つの集計レポートを送信します；Microsoft、Yahoo などは独自のサイクルで。小さなドメインの場合、最初の 1 週間は通常 [email protected] からの数件のメールになります。
圧縮された XML 添付ファイルです。 ダッシュボードではありません。生のまま読むのはほぼ不可能です；無料のパーサーが送信者のテーブルに変換します。
量はメール量を追跡します。 メールをほとんど送らない場合、またはレポートしないプロバイダーへの送信が多い場合、データが少ないことを予期してください。低ボリュームのドメインには静かな 2 週間が普通です — 失敗したと仮定するのではなく dig でレコードを確認してください。
驚きを予期してください。 ほとんどのドメインは忘れていた送信者を発見します — CRM、請求ツール、お問い合わせフォーム。強制する前にそれぞれが SPF または DKIM でアライメントされる必要があります。SPF と DKIM が個別にパスするのに DMARC が失敗している場合は、アライメントの問題があります — DMARC が失敗するが SPF と DKIM はパスするを参照してください。

そしてレポートを求めてください：DMARC レコードを持つドメインの 64.3% が rua= アドレスを公開していないため、レポートが届きません — そのセンサスカットは DMARC の盲目的公開にあります。ここで学ぶことはすべて強制ロールアウトにフィードされます — モニタリングはそのプロジェクトの第 1 週であり、目的地ではありません。無期限に p=none に駐車することが、ドメインが 89.41% に含まれる最も一般的な方法です。

よくある質問

p=none を公開することでメールの配信可能性が損なわれるか？ いいえ。p=none は受信者がメールをどのように扱うかを何も変えません — レポートを要求するだけです。助けになることがあります：Google と Yahoo のバルク送信者要件は大量送信者に少なくとも p=none の DMARC レコードを要求するため、公開することはリスクではなくコンプライアンスの基準です。

レコードを公開したのに、なぜチェッカーはまだ「ポリシーが有効になっていない」と言うのか？ なぜなら本当のことを言っているからです：ポリシーは none であり、チェッカーは quarantine または reject のためにパスを予約しています。モニタリングするが強制しないドメインに加わりました — 2026-06-29 時点で、261,086,232 グレード済みドメインのわずか 10.59% が強制しています。警告は強制へのロールアウトを完了すると消えます。

DMARC を追加する前に SPF と DKIM をセットアップする必要があるか？ メールが DMARC をパスするためには少なくとも 1 つがアライメントされている必要がありますが、p=none を公開する前に完璧にする必要はありません。モニタリングはまさに何が壊れているかを見つける方法です：261,086,232 グレード済みドメインのうち 70,368,600 件（2026-06-29 時点）が軟らかい SPF と DMARC 強制なしを持ち、レポートが何が止まっているかを学ぶ方法です。

自分のメールボックスの代わりにサードパーティの分析ツールにレポートを送れるか？ はい — ただし別のドメインの rua アドレスはベンダーが承認レコード（yourdomain._report._dmarc.vendor.com）を公開する必要があり、そうでなければ受信者は静かにレポートを差し控えます。評判の良いサービスはこれを自動的に行います；レポートが届かない場合はまずこれを確認してください。

オーナーにレポートを送る

クライアントまたは雇用主のためにこれを修正している場合は、作業を見えないままにしないでください。レコードが解決したら無料スキャンを再実行し、採点済みレポートを転送してください：DMARC が欠落からモニタリング済みへの移行を、タイムスタンプ付き、平易な言葉で示す — そして強制へのパスで次に何をするかを示します。オーナーはサイバー保険の更新やサプライヤーのセキュリティアンケートのためにまさにこの証拠をますます必要としており、1 ページの採点済みレポートがそれらの質問に DNS パネルのスクリーンショットよりもはるかに良く答えます。

ドメインを無料で確認する

2 つの状況のどちらにいるか — レコードなし vs p=none — とその下に何があるかを、プライベートにオーナーのみで確認できます。

ドメインを確認 → · DMARC を修正 → · p=none から p=reject へ → · グレード方法について → · 集計データのみ。データは EU で保存・処理されます。