Skip to main content
New SPF lookups must resolve in milliseconds — why a DMARC tool's add-on isn't enough Learn Why → →

DMARC ポリシー

DMARC ポリシー——p= タグ——は、DMARC に失敗したメールを受信側がどう扱うかを伝えます:p=none(監視のみ)、p=quarantine(迷惑メールに送る)、または p=reject(完全にブロック)。なりすましに対する完全な保護には p=reject が必要です。

このガイドは、DMARC の完全ガイドの一部です。関連:DMARC レコードDMARC の設定方法

あなたの DMARC ポリシー——DMARC レコードの p= タグ——は、DMARC 認証に失敗したメッセージを受信メールサーバーがどう扱うかを伝えます。選択肢は 3 つあります:p=none(監視のみ、何もしない)、p=quarantine(失敗したメールを迷惑メールに送る)、p=reject(失敗したメールを完全にブロックする)。あなたのドメインのなりすましに対する完全な保護を与えるのは p=reject だけです。

DMARC レコードを持つ誰もがポリシーを持っていますが、ほとんどのドメインは p=none にとどまっており、これはなりすましを止めるのに何の役にも立ちません。目標は、安全に p=reject へと進むことです。このガイドでは、各ポリシーを解説し、なぜアラインメントが静かにメッセージの合否を決めるのか、そして自分の正当なメールをブロックせずに強制に到達する方法を説明します。

3 つのポリシー:none、quarantine、reject

p= タグは、DMARC レコードで唯一最も重要な部分です。メッセージがあなたのドメインからのものだと主張しながら DMARC に失敗したときに、受信側がどのようなアクションを取るべきかを指示します。

ポリシー受信側がすること使うタイミング
p=none何もしない——通常どおり配信するが、集約レポートを送ってくる出発点。データを集め、すべての正当な送信者が合格することを確認する間だけ使う。
p=quarantine失敗したメールを迷惑メール/ジャンクフォルダーに振り分ける中間段階。レポートがクリーンになったら使い、完全なブロックに踏み切る前にソフトに強制する。
p=reject失敗したメールをサーバーで拒否する——受信トレイには決して届かない最終目標。すべての正当なメールが認証・整合すると確信できたら使う。完全ななりすまし保護。

p=none は監視モードであり、保護ではありません。p=none にとどまったドメインは、依然として自由になりすまされる可能性があります——攻撃者はあなたを名乗ってメールを送信でき、それが受信トレイに届きます。本当のなりすまし対策の保護は p=quarantine で始まり、p=reject で完成します。

アラインメントが合否を決める

DMARC の「合格」は、SPF や DKIM の合格単独よりも厳格です。DMARC に合格するには、メッセージは SPF または DKIM のうち少なくとも一方が、受信者が実際に目にする見える From: ドメインに対して 認証整合 の両方を満たす必要があります。

  • SPF アラインメント — SMTP エンベロープ(Return-Path)のドメインが見える From: ドメインと一致し、かつ SPF が合格しなければならない。
  • DKIM アラインメント — DKIM 署名(d=)のドメインが見える From: ドメインと一致し、かつ署名が検証されなければならない。

ここで SPF が静かに DMARC を壊します。SPF レコードは 10 の DNS ルックアップ に制限されています。ネストされた include: ステートメントで複数のプロバイダーを追加すると簡単に起こることですが、レコードがその制限を超えると、SPF は PermError を返して評価を止めます。これが静かに SPF アラインメントを無効化します。DKIM アラインメントも整っていなければ、本来正当なメールが DMARC に失敗し、強制に移った途端に隔離または拒否されます。

これが、ポリシーを締める前に なぜ SPF アラインメントが重要なのか が非常に大きな意味を持つ理由です。レコードがルックアップ制限内にあり、PermError を返さないことを確認してください。AutoSPF は、レコードを自動的にフラット化することで SPF を有効に保ち、送信者を追加しても 10 ルックアップ未満にとどめます——reject に向かう過程で DMARC アラインメントを保護します。

aspf(SPF)と adkim(DKIM)タグで、アラインメントの厳格さを制御することもできます。r(relaxed、デフォルト)はサブドメインの整合を許容し、s(strict)は完全一致を要求します。ほとんどのドメインはこれらを relaxed のままにすべきです。完全なタグリファレンスについては DMARC レコード をご覧ください。

none から reject へ安全に移行する方法

いきなり p=reject に飛び移ると、本物のメールをブロックする危険があります。代わりに段階的な展開を使いましょう。

  1. p=none から始める。 p=none とレポートアドレス(rua=)を設定した DMARC レコードを公開する。これは配信について何も変えませんが、集約レポートの収集を始めます。
  2. レポートを読む。 2〜4 週間かけて、あなたのドメインを名乗って送信するすべての送信元——自社のマーケティングプラットフォーム、CRM、ヘルプデスク、請求ツール、そして見えない送信者——を確認するためにレポートを見直す。
  3. 失敗している正当な送信者を修正する。 失敗する本物の送信者ごとに、それを SPF に追加するか DKIM 署名を設定して、認証・整合するようにする。その間、SPF は 10 ルックアップ制限内に保つ。
  4. pct を付けて p=quarantine に移行する。 p=quarantine; pct=25 を設定して、まず失敗したメールの 4 分の 1 に強制し、レポートがクリーンなままなら pct を 100 に向けて引き上げる。これにより、送信者を見落としていた場合の影響範囲を抑えられます。
  5. p=reject に移行する。 quarantine が pct=100 になり、レポートが想定された失敗(すなわち実際のなりすまし)のみを示すようになったら、完全な保護のために p=reject に切り替える。

レコードの構文と段階的な公開については、DMARC の設定方法 をご覧ください。

sp タグ(サブドメインポリシー)

sp= タグは、あなたのドメインのサブドメインに対して別のポリシーを設定します。省略すると、サブドメインはメインの p= の値を継承します。これが重要なのは、攻撃者があなたが積極的に使っていないかもしれないサブドメイン(mail.yourdomain.com など)をよくなりすますからです。よくある安全なパターンは、トップレベルのポリシーがまだ立ち上げ中でも sp=reject を公開しておき、使っていないサブドメインを早めにロックダウンすることです。正当な送信のためにサブドメインを使う場合は、それらも同じように扱ってください——監視し、整合させ、それから強制する。

よくある質問

DMARC ポリシーとは何ですか?

DMARC ポリシーは、あなたのドメインの DMARC DNS レコードの p= タグです。あなたのドメインからのものだと主張しながら DMARC 認証に失敗したメッセージを、受信メールサーバーがどう扱うかを伝えます。3 つの値は p=none(監視のみ)、p=quarantine(迷惑メールに送る)、p=reject(ブロック)です。これは、DMARC を本当の保護へと変える中核的な指示です。

p=none、p=quarantine、p=reject の違いは何ですか?

p=none は失敗したメールに対して何もしません——レポートを送ってくるだけなので、あなたのドメインは依然としてなりすまされる可能性があります。p=quarantine は失敗したメッセージを迷惑メールフォルダーに振り分ける、ソフトな強制段階です。p=reject は失敗したメールをサーバーで拒否するため、受信トレイには決して届きません。なりすましを実際に止めるのは p=quarantinep=reject だけで、p=reject が完全保護の目標です。

p=reject は安全に使えますか?

はい、そのための準備ができていれば。p=reject は、すべての正当な送信者が認証・整合し、集約レポートが想定された失敗のみを示すようになる段階的な展開の後であれば安全です。リスクは、reject に早く飛び移りすぎて本物のメールをブロックすることから生じます。p=none で失敗している送信者を修正し、pct を使って p=quarantine を経て引き上げ、それから reject に踏み切りましょう。

なぜ私の DMARC ポリシーは有効になっていないのですか?

たいていは p=none に設定されているためで、これは監視のみで何も強制しません——したがってあなたのドメインはなりすまし可能なままです。また、SPF が 10 ルックアップ制限を超えて PermError を返し、静かにアラインメントを壊して正当なメールが DMARC に失敗している場合にも、無効に見えることがあります。SPF チェッカー でレコードを確認し、アラインメントを修正してから、none から reject へと進みましょう。

Rated 5/5 on G2 · Trusted since 2018

Trusted by 50,000+ domains

"AutoSPF Flattens SPF Records Seamlessly & Keeps Changes Logged - I am quite pleased with the product"

It does what it promises to do, and does it very well. I appreciate that it keeps a log of changes made, which prevents many mistakes. A client's SPF record would have way too many lookups, but AutoSPF makes that problem go away. The length of the SPF record is typically not the issue; it's the amount of lookups in the record that are. AutoSPF "flattens" the record, automatically expanding the defined lookups to IP addresses or ranges. And it auto-updates the record when the un-flattened lookups change.
PJ

Peter J.

President · Small-Business (50 or fewer emp.)

"Helped us go beyond capacity"

AutoSPF did exactly as described, it helped us get past our 10 lookup limit. Afterwards, we hit another limit regarding overall capacity and when contacted, they quickly provided us with a new solution to eliminate capacity issues entirely going forward, so now we can add as many SPF records as needed. They also provided us with a personalized support video explaining their new method in its entirety using our instance as the example.
VU

Verified User

Financial Services · Mid-Market (51-1000 emp.)

"Great service and great support"

AutoSPF was easy to initially set up on our own and a great cost effective entry into spf flattening. Needed our first support assistance today and got great response including a video demonstrating the issue I was trying to solve, a quick fix, and more detailed followup.
GF

Greg F.

Mid-Market (51-1000 emp.)