Skip to content

DMARC Policy Strength: Moving from None to Reject

Understanding what each policy level actually does at the receiving end

Warning / Info
Email Authentication
DMARC

Warning

The domain's DMARC policy is set to p=none or p=quarantine. Neither provides full protection against spoofing — only p=reject instructs receivers to refuse failing mail outright. See the relevant section below for what your current policy level actually does.

The p tag tells receiving mail servers what to do with messages that fail DMARC. It takes one of three values: none, quarantine, or reject. Only reject gives you full protection, and the two weaker values are worth understanding in terms of what they actually do at the receiving end.

A message fails DMARC only when both authentication paths fail. DMARC passes if SPF passes and is aligned, or if DKIM passes and is aligned. So the policy applies to a narrower set of mail than people expect: not everything that fails SPF, only mail where neither method produced an aligned pass. That is why a well signed mail stream can sit at reject without incident, and why an unsigned one cannot.

It is also worth being clear that a DMARC policy is a request, not a guarantee. Receivers decide how to act on it, and large mailbox providers layer their own reputation systems on top. Most honor reject, but the policy is your instruction to them rather than a control you operate directly.

DMARC policy set to none

The domain publishes a DMARC policy of p=none. Receivers report on failing mail but take no action, so spoofed messages are still delivered. This is monitoring only, not protection.

A policy of p=none is monitoring only. Receivers evaluate the message, record the outcome, and deliver it as they normally would. Spoofed mail using your domain in the From header still reaches the inbox. The value of none is the reporting: with a rua address in place, you get daily aggregate reports showing every source sending as your domain, whether each passed SPF and DKIM, and whether those passes were aligned.

That data is the reason to start at none rather than skipping straight to enforcement. Most organizations discover sending sources they had forgotten: invoicing systems, HR platforms, ticketing tools, monitoring alerts, marketing services set up by a team that no longer exists. Enforcing before you have found all of them is how legitimate mail disappears.

None is a starting point, not a destination. A domain that stays at none indefinitely has visibility and no protection.

DMARC policy set to quarantine

The domain enforces DMARC at quarantine. Mail that fails authentication is sent to spam or held instead of being rejected, so a spoofed message can still reach the recipient's junk folder. This is stronger than none but one step short of the full protection that reject provides.

p=quarantine is real enforcement. Failing mail is delivered to the spam or junk folder rather than the inbox, or held for review, depending on the receiver. It is a clear improvement over none, and it is a sensible middle step during rollout because mistakes are recoverable: if you break a legitimate stream, the mail is still retrievable rather than gone.

The reason it stops short of full protection is that the message still arrives. A user who checks their junk folder, or a filter that later reclassifies the message, can put a spoofed email in front of the recipient. Quarantine also gives you a weaker feedback signal than reject, because nothing bounces back to the sender.

Many mature senders sit at quarantine deliberately and stay there. It is not a misconfiguration in the way that none is. But if the goal is to stop spoofing rather than to file it away, reject is the setting that does that.

Moving to reject

Before you change the policy, work through your aggregate reports and confirm that every legitimate source is producing an aligned pass. Two situations account for most of the failures you will see.

The first is third party senders using their own bounce domain. SPF authenticates the envelope sender, not the From header, so a marketing platform sending as your domain with its own return-path will pass SPF but fail alignment. The fix is DKIM: have the provider sign with a selector delegated under your domain, usually via a CNAME they give you, so the d= value aligns.

The second is forwarding and mailing lists. Forwarding breaks SPF because the message arrives from a relay that is not in your record. DKIM survives forwarding as long as the message body and signed headers are unchanged, which is why DKIM coverage on every stream is the real prerequisite for reject. Mailing lists that rewrite the subject line or append a footer break DKIM as well. ARC exists to preserve the original authentication result across those hops, but support is not universal, so check whether the lists your users rely on are affected before you enforce.

Once reports show no unresolved legitimate sources failing, change the policy to p=reject. Receivers then refuse the message during the SMTP transaction, which has a useful side effect: a genuine sender you missed gets a bounce, so the problem surfaces quickly instead of sitting silently in a spam folder.

Parked and non-sending domains. Domains that send no mail at all are a different case and the easiest win available. Parked domains, brand defensive registrations, and internal-only names should carry p=reject from the start, since there is no legitimate stream to break. Pair that with a null MX record to make the intent explicit.

Example records at each stage

Monitoring only, collecting aggregate reports:

_dmarc.example.com.  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

Quarantine enforcement during rollout:

_dmarc.example.com.  IN  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com"

Full reject enforcement:

_dmarc.example.com.  IN  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"

Non-sending domain (parked or brand defensive):

_dmarc.example.com.  IN  TXT  "v=DMARC1; p=reject; sp=reject; adkim=r; aspf=r"

References: RFC 7489 (DMARC) · RFC 7208 (SPF) · RFC 6376 (DKIM) · RFC 8617 (ARC)