惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

云风的 BLOG
云风的 BLOG
freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More
博客园 - 叶小钗
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
V
V2EX
酷 壳 – CoolShell
酷 壳 – CoolShell
月光博客
月光博客
人人都是产品经理
人人都是产品经理
宝玉的分享
宝玉的分享
博客园 - 司徒正美
WordPress大学
WordPress大学
Microsoft Azure Blog
Microsoft Azure Blog
罗磊的独立博客
Vercel News
Vercel News
T
The Blog of Author Tim Ferriss
T
Tailwind CSS Blog
A
About on SuperTechFans
Apple Machine Learning Research
Apple Machine Learning Research
L
LangChain Blog
让小产品的独立变现更简单 - ezindie.com
让小产品的独立变现更简单 - ezindie.com
V
Visual Studio Blog
S
SegmentFault 最新的问题
Google DeepMind News
Google DeepMind News
博客园 - 聂微东

Resend RSS Feed

6 Tips for Accessible Emails Welcoming Manoel do Amaral, our new Brand Designer Welcoming Michael Vaz, our new Customer Success Engineer Six Steps to Improve Your Sender Reputation Welcoming Tatira Andrade, our new Executive Assistant Welcoming Pedro Ivo Hudson, our new Design Engineer Welcoming Diel Duarte, our new Open source Engineer Welcoming Areia Spinner, our new Recruiter Resend Forward: A Conference about Craft React Email 6.0 Custom Tracking Domains AI Email Editor Introducing Automations Welcoming Ahmed Tolba, our new SRE Engineer Welcoming Aneil Singh, our new Founding Account Executive Welcoming Lucas Motta, our new Software Engineer Welcoming Trey Knowles, our new Founding Account Executive Welcoming Anxhela Carciu, our new SRE Engineer Introducing DMARC Analyzer Welcoming Evan Thibodeau, our new Customer Success Engineer Welcoming Derich Pacheco, our new Software Engineer Welcoming Alec Ventura, our new Data Engineer Welcoming Felipe Freitag, our new Software Engineer Welcoming Mateusz Wos, our new Software Engineer Incident report for February 15, 2026 Email automation for OpenClaw How to Create a DevTools Agent Skill Introducing Email Skills Why You Should Embrace the Promotions Tab Slater Smith, our new Customer Success Engineer
DMARC Policy Modes
Jp Valery · 2025-07-10 · via Resend RSS Feed

One of the most malicious types of abuse is called email spoofing where bad actors make it look like their email was from a trusted source.

To combat this abuse, email inbox providers developed protocols to help domain owners protect their email domains from spoofing and phishing. These protocols are published as DNS records and include:

  • SPF: a list of allowed IP addresses
  • DKIM: a signature of the email to verify the sender's identity
  • DMARC: a policy for what to do if the email fails SPF or DKIM checks

In this article, we'll focus on DMARC, focusing special attention on the different DMARC policy modes—none, quarantine, and reject.

TLDR; Unless you're confident in how DMARC, SPF, and DKIM work together and you’ve reviewed your domain’s sending sources, we recommend a basic p=none policy. It's the safest way to start getting visibility without risking legitimate mail disruption.

Why you should care about DMARC

Google, Yahoo, and Microsoft have all announced requirements for bulk senders to publish a DMARC policy on their domains.

If you’re sending large volumes of mail—especially to consumers—you may need to enforce DMARC or risk your mail being marked as spam.

A basic introduction to DMARC policy levels

DMARC (Domain-based Message Authentication, Reporting, and Conformance) policies are published as DNS records and tell receiving mail servers what to do with messages that fail authentication. There are three options:

  • p=none: no enforcement, just monitoring. This is your observation mode and is ideal for gathering data.
  • p=quarantine: treat unauthenticated mail as suspicious (i.e., often by filtering it to spam).
  • p=reject: outright block unauthenticated mail from being delivered (i.e., return a bounce message).

The real-world effects of these modes vary across providers and mailflows. Let’s take a closer look.

If you publish p=none

Setting p=none means you're not asking mail receivers to take any action against unauthenticated messages. Instead, you’re just watching.

This mode is the right default for most senders. It's crucial for:

  • Establishing a baseline of who’s sending on your behalf.
  • Catching unauthorized or misconfigured senders without affecting delivery.
  • Reviewing DMARC reports (via rua/ruf) to identify issues before enforcement.

For most senders—especially those just starting out—this is the recommended starting point. It provides visibility without disruption.

If you publish p=quarantine

When your domain has a p=quarantine DMARC policy, you’re telling receivers: “If this message fails DMARC, handle it cautiously, but don’t outright block it.” What that means in practice can vary.

Some possible outcomes:

  • Sent to spam: Most mailbox providers (Gmail, Outlook, etc.) will route failing mail to the recipient’s junk or spam folder.
  • Held temporarily: Some systems may delay or sandbox the message for additional analysis.
  • Subject to stricter filtering: Messages might be scored more harshly by spam filters, increasing the chance they get flagged or dropped.

What’s important to remember: quarantine doesn’t necessarily stop mail from arriving, it just makes it more likely that it gets deprioritized or filtered.

It’s possible then for legitimate sources that fail DMARC to go unnoticed. The mail may still be delivered (albeit to spam), and unless the sender is watching closely, they may not notice the problem until users complain or performance dips.

If you publish p=reject

Publishing p=reject is a much stronger stance. It tells recipients: “Do not accept any mail from my domain unless it passes DMARC.”

There are two main ways a reject policy is enforced:

  1. SMTP rejection: The recipient refuses the message at the time of sending. This is the cleanest approach. Delivery fails immediately, and a bounce message can be generated.
  2. Post-SMTP blocking: The message is accepted initially but discarded before reaching the inbox. This can cause silent drops, where no bounce is returned.

In both cases, the result is the same: mail that fails DMARC isn’t delivered. This is highly effective at blocking unauthorized mail, especially phishing attempts spoofing your domain.

However, if any of your legitimate senders are misconfigured or unaware of DMARC, their mail will get blocked, and you’ll hear about it quickly. A reject policy makes DMARC failures visible, loud, and immediate.

What to expect when stepping up enforcement

If you're considering moving from none to quarantine or reject, it's worth planning carefully.

Here’s how the rollout often plays out:

  • With quarantine, delivery issues are subtle. Legitimate-but-broken senders may keep sending, unaware their mail is landing in spam.
  • With reject, issues are obvious. Mail bounces, people complain, and broken flows surface fast.

While the DMARC protocol includes the pct parameter for controlling the percentage of messages that should be authenticated, it is not widely followed by mailbox providers and this setting may not be respected or followed.

The beauty of DMARC is in the visibility it gives you. When used properly—with reporting enabled (i.e., rua, ruf)—you can identify and fix issues before enforcing stricter policies.

And if you're managing subdomains or want to understand how DMARC applies across them, we’ve covered that in our companion piece on DMARC’s sp tag and subdomain behavior.

Wrap-up

Both quarantine and reject are valuable tools for protecting your domain from abuse, but they come with tradeoffs.

Quarantine is a gentler middle ground, and often useful during the transition phase. Reject is definitive and offers the strongest protection—but only when you’re confident everything that should be sending on your behalf is properly authenticated.

DMARC was designed with gradual rollout in mind. If you take advantage of its reporting capabilities and iterate carefully, you can get to a strong enforcement policy with minimal pain.

For more help with DMARC, view our DMARC docs or reach out to our support team.