DMARC at p=reject: the last step most SMBs skip

SPF and DKIM are in place, DMARC is set to p=none — and that's where it stays. Here's how to safely move to quarantine and reject without your invoices ending up in spam.

Many SMBs have taken the first steps in email security: SPF is configured, DKIM signs outgoing mail, and DMARC is enabled. But almost without exception, it's sitting on p=none. That means: data is being collected, but nothing is actually enforced. Someone can still send an email in your name — and it will be delivered without a hitch.

The final step — moving DMARC to p=quarantine and eventually p=reject — is often postponed out of fear that legitimate mail will stop getting through. Understandable, but unnecessary. In this post, we walk you through how to make that move safely.

Quick recap: what does DMARC actually do?

DMARC tells receiving mail servers what to do with messages that claim to come from your domain but aren't covered by SPF or DKIM. Three options:

• p=none: take no action, just report. Fine as a starting point — not fine to stay stuck on forever.
• p=quarantine: suspicious mail ends up in spam.
• p=reject: suspicious mail is rejected outright and never delivered.

As long as you're on none, fraudsters can still abuse your domain for phishing attacks targeting your customers — and those customers will see your name in the sender field.

Why does everyone get stuck on p=none?

Three reasons we see in practice:

1. Unknown senders. Your marketing tool, accounting software, HR system, and CRM all send email on behalf of your domain. Some of them aren't included in SPF or don't sign with DKIM.
2. No idea what the DMARC reports say. The XML reports delivered to your rua address are far from easy reading.
3. Fear of disruption. Nobody wants to be the one explaining why a quote never arrived.

Step 1: let p=none run for a while and read the reports

Before changing anything, you need to know which systems are sending email on behalf of your domain. Set a DMARC record with p=none and a rua address where reports will be delivered. Let it run for at least 2 to 4 weeks.

Reports arrive as XML files — one per receiving mail provider per day. Reading them manually isn't realistic. There are free and paid DMARC dashboards that make the XML digestible. What you're looking for: senders that are legitimate but whose SPF or DKIM isn't properly set up yet. Fix those first.

Step 2: fix the legitimate offenders

Common culprits:

• Mailchimp, Brevo, ActiveCampaign and other marketing platforms: typically require their own DKIM records.
• Accounting software that sends invoices from your domain name.
• Microsoft 365 Direct Send from printers, scanners, and line-of-business apps.
• Third parties (PR agencies, recruiters) sending mail "on your behalf" — worth reconsidering in any case.

For each legitimate sender: add them to your SPF record or configure DKIM. Then review the reports again. Once they're clean — only unknown, clearly malicious senders remaining — you're ready to move on.

Step 3: move to reject in stages

Don't jump straight from none to reject. Do it in phases:

1. p=quarantine with pct=25: 25% of suspicious mail goes to spam. Monitor for one week.
2. p=quarantine with pct=100: all suspicious mail goes to spam. Monitor for two weeks.
3. p=reject with pct=100: the end goal.

At each stage, keep an eye on the reports and stay in touch with your organisation. Getting complaints that mail isn't arriving? Usually it's a forgotten sender you can then add and fix.

Don't forget your subdomains

A common mistake: yourbusiness.com is on p=reject, but mail.yourbusiness.com or newsletter.yourbusiness.com has no record of its own. Use the sp= tag to control the policy for subdomains. By default they inherit the policy from the root domain, but it's best to be explicit about that.

And what about domains that never send email — like an old domain name you're holding on to? Set those straight to p=reject with a null SPF record (v=spf1 -all). These are the ones that get abused most often.

What you get out of it

With DMARC on reject:

• No one can send phishing emails using your exact domain name.
• The deliverability of your legitimate mail improves (Gmail and Yahoo have required DMARC for bulk senders since 2024).
• You meet a requirement that's increasingly showing up in supplier contracts and NIS2-related contexts.

What it doesn't stop: lookalike domains (yourbusinss.com with a typo). You need other measures for those. But locking down your exact domain is a solid 80/20 win.

Get started

Want to know where your domain stands right now and which steps make sense for you? We carry out a complete SPF, DKIM, and DMARC check and guide you through the step-by-step move to p=reject — without any invoices getting lost along the way.