DMARC p=reject: moving up from p=none safely

Most domains that publish DMARC at all stop at p=none. That is enough for the bulk-sender rules: Google’s Email sender guidelines say “Your DMARC enforcement policy can be set to none”, and Yahoo’s Sender Best Practices ask for “at least p=none”. So p=reject is not about getting your newsletter delivered. It is about the other direction: telling every mailbox provider that mail claiming to be from your domain, and failing authentication, is not yours.

That protection is worth having, and it is easy to switch on. It is also easy to switch on too early and quietly lose your own invoices, password resets or replies from a shared mailbox. This post covers what each policy does, the checks to run before each step, and what to watch afterwards.

DMARC’s specification changed this year. In May 2026 the IETF published RFC 9989, with aggregate reporting in RFC 9990. Together they replace RFC 7489, which most guides you will find still quote. Where the new text changes the advice, it is called out below.

What none, quarantine and reject do

A DMARC record is a TXT record at _dmarc. followed by your domain. A typical starting record looks like this:

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

The p tag is the policy, the instruction for mail that claims to be from your domain and fails DMARC:

p=none: you express no preference. Mail is delivered or filtered as it would have been anyway, and you get reports.
p=quarantine: failing mail is suspicious. It may be genuine, but the failure is a significant concern, and the receiver may filter it, for example to spam.
p=reject: every failure is a clear sign the use of your domain is not valid, and the receiver may refuse the message outright.

Mail “fails DMARC” when neither SPF nor DKIM passes for a domain that matches the one in the visible From address. That matching is called alignment, and it is the source of nearly every problem in this post. A message can pass SPF and pass DKIM and still fail DMARC, because both passed for some other company’s domain.

Receivers are not obliged to follow your policy to the letter. RFC 9989 is explicit that receivers make the final decision, and that they must not reject mail solely because your record says p=reject. Treat the policy as a strong request, not a switch.

Step 1: list everything that sends as your domain

Before tightening anything, find every system that puts your domain in a From address. For a small business the list is usually longer than people expect:

your email marketing platform (newsletters, automations)
your website: contact form notifications, shop order confirmations, password resets
your office mailboxes, including shared ones like accounts@ or hello@
invoicing, booking, helpdesk and CRM tools that send “on behalf of” you
anything a developer set up years ago and nobody remembers

For each one, the question is the same: does it pass SPF or DKIM for your domain? The service’s own setup page usually tells you which DNS records it needs. If it asks for DKIM records (often CNAMEs under ._domainkey.) and you added them, that service can pass with alignment. If it never asked you to change DNS, assume it does not, and check its documentation for a “custom domain” or “domain authentication” setting.

Be wary of services that only pass on SPF. RFC 9989 points out that forwarded mail “will most likely fail SPF checks”, while “DKIM signatures will generally remain valid” through a forward, and it says domains that publish p=reject “MUST NOT rely solely on SPF to secure a DMARC pass and MUST apply valid DKIM signatures to their messages”. If an office mailbox provider does not sign with DKIM for your domain, your staff’s mail to anyone who forwards it on (an alumni address, a role address at another firm) can fail once you reach reject.

Step 2: read your reports before you tighten

The rua address in your record is where receivers send aggregate reports. Per RFC 9990, these are daily (or more frequent) XML summaries listing, for each sending IP address, how many messages used your domain and whether SPF and DKIM passed and aligned. Without an rua tag, receivers do not send them, so if your record has none, add one first.

Raw XML is hard to read by hand. Several services will collect and chart the reports for you, some at no cost, and some DNS hosts offer it as a built-in. Whatever you use, you are looking for two things:

Your own senders, failing. A source you recognise from step 1 that shows up as failing alignment needs fixing before you go further. This is the mail you would lose.
Sources you do not recognise. If they fail, that is often exactly the spoofing p=reject is meant to stop. If they pass, find out what they are, because something is sending as you with valid credentials.

If your rua address is on another company’s domain, as it is with a reporting service, receivers first check that the other domain has agreed to take your reports: RFC 9990 has them look for a TXT record at example.com._report._dmarc. on the reporting domain. Reporting services publish that record for you. It is worth knowing about only so you are not puzzled if reports stop after you point rua somewhere new by hand.

Step 3: move in stages, and give each one time

The move is none, then quarantine, then reject, with time between each step. RFC 9989 is specific about how much time for domains whose users might post to mailing lists (more on those below): it says such domains should first publish p=none “for at least a month, followed by publishing “p=quarantine” for an equally long period of time”, comparing the results at each stage.

Two things in the new standard change how older guides describe the ramp:

pct is gone. Older guides suggest raising the policy gradually with pct=10, then pct=50 and so on. RFC 9989 removes the pct tag, because operational experience showed values other than 0 and 100 were usually not applied accurately.
t=y is the new testing flag. It asks receivers to apply one level less than you publish: p=reject; t=y is treated as quarantine, and p=quarantine; t=y as none. Reports are unaffected. It lets you publish the record you are aiming for while you watch.

A quarantine stage costs you little and teaches you a lot: if one of your own senders was missed, its mail lands in spam rather than disappearing, and someone usually notices within days.

Relaxed or strict alignment

The adkim and aspf tags set how exact the domain match must be. Both default to relaxed (r), where news.example.com and example.com count as matching. Strict (s) needs the domains to be identical.

Relaxed is the right choice for nearly everyone. Email platforms commonly sign from your domain but use a subdomain for the return path, and a shop or helpdesk may send from a subdomain. Strict alignment fails all of those without any security gain worth the breakage. If you have no reason to choose, leave both tags out and you get relaxed.

Domains that never send email

Every domain you own but do not send from (old brand names, typo domains, a .co.uk that only redirects to your .com) can be used to spoof you, and nothing legitimate will break if you lock it down. Here you can skip the staged approach. The UK government’s guidance on protecting domains that don’t send email recommends two records, along these lines:

example.co.uk         TXT  "v=spf1 -all"
_dmarc.example.co.uk  TXT  "v=DMARC1; p=reject; sp=reject; adkim=s; aspf=s; rua=mailto:dmarc-reports@example.com"

The SPF record says no server may send for the domain. The DMARC record rejects anything claiming to, including from subdomains (sp). That guidance is written for public sector domains and includes a government reporting address; swap in your own.

One caution: people and mailing lists

RFC 9989 makes one recommendation that runs against much of the advice online. When someone on a p=reject domain posts to a mailing list, the list resends their message, and many receivers then reject it, which can get other subscribers unsubscribed automatically. For that reason it says domains whose users might post to mailing lists “SHOULD NOT” publish p=reject, and those that do should first run the none and quarantine stages and tell their users that list participation “may be hindered”.

The same document notes that most mailing list software has since adapted, by rewriting the From address so the resent message aligns. So the risk is smaller than it was. But if your domain is your staff’s everyday email address and they take part in industry lists or forums by email, quarantine may be the better resting point for that domain, with reject reserved for domains used only for sending to customers.

What to watch after switching

The first week after any step up is when missed senders show themselves:

Password resets and account emails. A website or app that sends through its host’s default mail server rather than your configured provider is the most common casualty. Trigger a reset yourself and check it arrives.
Replies that stop coming. If customers say they did not get an answer, check whether it came from a shared mailbox or helpdesk tool.
New tools. Anyone who connects a new service later needs to know the domain is at reject, so its domain authentication gets set up on day one.

Keep reading the reports. A new failing source after the switch is either a sender you missed or someone trying to impersonate you, and you want to know which.

Where SendBeam fits

When you add a sending domain to SendBeam, it gives you DKIM signing records and a return-path record for that domain (see Sending domain). Once those are verified, campaigns and automations sent from that domain pass both DKIM and SPF with alignment to your From address, so they are not one of the senders you need to worry about at reject.

The DMARC record itself stays yours to publish, as it does with any platform. The free sender check shows the DMARC policy on your domain and whether a real message you paste in aligns, which is a quick way to confirm a sender before you tighten the policy. For the wider list of what Gmail, Yahoo and Microsoft check on bulk mail, see One-click unsubscribe and the bulk-sender rules.