What reject actually does
DMARC is your instruction to inboxes about mail that fails. It is one line of text in your DNS, and the part that matters here is the policy, the p= tag:
v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourcompany.co.uk
The policy has three settings. Each one tells the receiving server what to do with a message that claims to come from your domain and fails the check.
| Policy | A forged email in your name | Your own email that fails |
|---|---|---|
p=none | Delivered as normal | Delivered as normal |
p=quarantine | Sent to junk | Sent to junk, where someone may find it |
p=reject | Refused before it arrives | Refused, and it bounces |
Read the two columns side by side. The receiving server cannot tell a fake from your accounts software having a bad day. It sees a message that passed or a message that failed, and it applies your policy to both. So the whole job is making sure your own mail passes. Once it does, reject only ever lands on the fakes.
Why so many domains stop at p=none
When we scanned 200 of the largest housing associations in England for our UK Housing Email Security Report 2026, 31% had published DMARC and left it at p=none. Another 9% had no DMARC record at all.
Source: OuterMark, UK Housing Email Security Report 2026.
The reason usually given is fear of breaking real email, and it is a fair one. Nothing forces the move either. Google, Yahoo and Microsoft require a DMARC record from anyone sending email in bulk, and p=none meets that requirement.
Sources: Google, email sender guidelines; Yahoo, sender best practices; Microsoft, error 550 5.7.515.
The catch is that p=none protects nothing. Anyone can still send email in your name, and every inbox will deliver it as normal. You get the reports, which are useful, but the fakes keep arriving.
Where the real risk is
The risk sits with the senders you forgot about. Any service that sends email as your domain has to pass DMARC on its own, and some of them were set up years ago by someone who has since left. Think about where your domain sends from:
- The accounts software that emails invoices and statements
- A newsletter or marketing platform
- Your CRM, booking system or helpdesk
- The contact form on your website, sending from your web host
- A scanner or printer that emails PDFs
- A supplier or agency sending on your behalf
Each one passes DMARC only if it signs its mail with DKIM (a signature that proves the message came from you) on your own domain, or passes SPF with a bounce address on your own domain. Many sending services pass SPF on their own domain instead, and DMARC does not count that. At p=none nobody notices. At p=reject that service's mail bounces.
Forwarding adds one more trap. When a mailbox forwards your message on, SPF breaks, because the forwarding server is not on your list. DKIM survives, because the signature travels with the message. Mail that passes on SPF alone can fail after a forward, so DKIM is the one to rely on.
Your DMARC reports are where these senders show up, each with a count of its messages and how many passed. Who is sending email as my domain? explains how to read them. This is the shape of it in the portal's DMARC Reports view:
Top sending sources
229 messages✓ Legitimate
17 messages✓ Legitimate
13 messagesNeeds a fix
p=reject most of its invoices would bounce. That is the sender to fix first.How to tell you are ready
You are ready for reject when all of these are true:
- Your reports cover at least 60 days of normal business, including the month end, the payroll run and the newsletter
- Every sender you recognise passes, ideally with DKIM on your own domain
- What still fails is mail you do not recognise, from servers you do not use
- You have run at quarantine for a while, and nobody has asked where their email went
- Someone will keep reading the reports after you switch
Go through quarantine first
Quarantine is the rehearsal. If you have missed a sender, its mail lands in junk folders instead of bouncing, where people can still find it and tell you. You fix the sender and nothing is lost. Reject is the same check with that safety net taken away, which is why it comes last.
This is the route Managed DMARC takes a domain along, with a person reading the reports and approving each step:
- Day 0Observep=none. Reports start arriving.
- About day 30Quarantine 25%A quarter of failing mail is junked.
- About day 45Quarantine 50%Half of failing mail is junked.
- About day 60Quarantine 100%All failing mail is junked.
- About day 90RejectFakes are refused.
If you are doing it yourself, the same order works. Our step-by-step guide for Microsoft 365 walks through it, from checking SPF and DKIM to the final record.
What if something breaks after you switch?
Reject is a line of text in your DNS, and you can change it back. If a real sender starts bouncing, set the policy back to p=quarantine while you fix it. Receiving servers pick up the change when their saved copy of your record expires, which the record's TTL (time to live) decides.
Keep the rua address in your record after you switch, so the reports keep coming. They name the sender that is failing and count its messages, which tells you what broke and how much of it.
The short version
Switching to reject is safe once your reports show every real sender passing and you have spent time at quarantine without complaints. Reject refuses only mail that fails DMARC. Your part is making sure your own mail never does, and reading the reports after you switch, because new senders get added all the time.
To see what your domain publishes today, run the free check. It reads your SPF, DKIM and DMARC records in about 30 seconds. If you would rather not walk the route alone, Managed DMARC walks it with you, one approved step at a time.