Email and DNS

How to set up DMARC: from p=none to p=reject

By Matt Chapman/Published 1 November 2026/Updated 2 November 2026/8 min read

Anyone can send an email that claims to be from your domain. SPF and DKIM let receiving servers check whether a message is genuine, but on their own they don’t tell the receiver what to do when the check fails. That’s DMARC’s job (Domain-based Message Authentication, Reporting and Conformance).

A DMARC record does three things:

• It says a message must pass SPF or DKIM for the same domain that’s in the From address. This is called alignment, and it’s what stops a spammer passing SPF with their own domain while showing yours.
• It tells receivers what to do with mail that fails: deliver it anyway, put it in junk, or reject it.
• It asks receivers to send you reports, so you can see every server sending mail as your domain, legitimate or not.

It’s no longer optional for many senders. Gmail and Yahoo have required DMARC from anyone sending more than 5,000 emails a day to their users since 2024, and Outlook.com, Hotmail and Live.com followed in May 2025. Even if you send far less than that, a domain without DMARC is easier to spoof and more likely to land in junk.

The risk with DMARC is doing it too fast. Jump straight to p=reject and you can block your own invoices, newsletters and website contact forms. This guide takes the safe route: monitor first, fix what the reports show, then enforce.

Before you start

DMARC builds on SPF and DKIM, so get those working for your main email provider first:

• SPF: one TXT record starting v=spf1 that lists every service that sends for you.
• DKIM: signing switched on with your own domain. On Microsoft 365 this isn’t on by default; follow my guide to enabling DKIM in Microsoft 365. In Google Workspace it’s in the Admin console under Apps > Google Workspace > Gmail > Authenticate email.

Then see where you stand. Put your domain into the free email DNS checker. It checks MX, SPF, DKIM and DMARC in one go, counts your SPF lookups, and explains anything that’s wrong. If you already have a DMARC record, it shows the current policy and reporting addresses.

Step 1: List everything that sends email as you

This is the step that decides whether DMARC goes smoothly. Your main mailbox provider is the obvious one, but most organisations have others they’ve forgotten about. Check for:

• Newsletter and marketing tools (Mailchimp, Brevo and the like)
• Accounting and invoicing software that emails invoices “from” you
• CRM, helpdesk and booking systems
• Your website: contact forms, WooCommerce order emails, WordPress notifications
• Printers and scanners that scan to email, and line-of-business apps that send alerts

Don’t worry about catching everything. The reports in step 3 will find the rest. But the more you know about up front, the fewer surprises later.

Step 2: Publish a monitoring record (p=none)

Add a TXT record at your DNS host:

The DMARC record generator builds this value for you as you pick the options, and leaves out tags that are at their default.

p=none means “don’t change how my mail is handled, just send me reports”. Nothing gets blocked at this stage, so it’s safe to publish straight away.

A few rules:

• Exactly one DMARC record. Two records at _dmarc and receivers ignore both.
• Don’t type the domain twice. Most control panels add it for you, so enter _dmarc, not _dmarc.example.co.uk.
• Use a separate mailbox for reports. Large senders get dozens of report emails a day. A shared mailbox or alias such as dmarc-reports@ keeps them out of anyone’s inbox.
• Reports to another domain need permission. If the rua address is on a different domain (a DMARC reporting service, say), that domain has to publish a record authorising it. Reputable services do this for you; if you’re pointing reports at your own second domain, you’ll need to add it yourself.

The tags you’ll actually use

Step 3: Read the reports

Within a day or two, reports start arriving from Google, Microsoft, Yahoo and others. Each one is a zipped XML file listing the servers that sent mail as your domain, how many messages each sent, and whether they passed SPF and DKIM with alignment.

Raw XML is hard work. Drop the files (zipped or not) into the DMARC report analyser and it lists each sending source, what passed and what failed, and why. It runs in your browser, so the reports aren’t uploaded anywhere. Paid reporting services do the same job continuously if you have a lot of mail. Whichever you use, sort every sending source into one of three groups:

1. Yours, and passing. Nothing to do.
2. Yours, but failing. A real service that isn’t set up properly yet. These must be fixed before you enforce, or that mail will be blocked.
3. Not yours. Spammers and phishers using your domain. This is exactly the mail DMARC enforcement will stop.

Leave p=none in place for at least two to four weeks so that monthly mail (invoices, statements, payroll) shows up in the reports too.

Step 4: Fix the services that fail

For each legitimate service in group 2, you need it to pass SPF or DKIM with your domain. DKIM is the better fix, because it survives email forwarding and SPF doesn’t.

• Set up DKIM with your own domain in the service. Most newsletter, CRM and invoicing tools have a “domain authentication” or “custom sending domain” page that gives you CNAME or TXT records to add. Until you do, they sign with their own domain, which passes DKIM but doesn’t align with yours.
• Add it to SPF if it needs to be there. Merge the service’s include: into your one SPF record. Watch the limit of 10 DNS lookups: go over and SPF fails for everything. The email DNS checker counts them for you.
• Website mail. Mail sent straight from a web server rarely passes anything. Send it through your email provider or a transactional email service using SMTP, and authenticate that service properly.
• Services you no longer use. Remove them from SPF and delete their DKIM records rather than fixing them.

Some failures you can’t fix and shouldn’t worry about: mail forwarded by a recipient’s own rules, and some mailing lists that rewrite messages. Receivers know about these and handle them sensibly. What matters is that mail sent directly from your services passes.

Step 5: Move to quarantine, then reject

When your reports show all your own mail passing for a couple of weeks, change the record to:

v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.co.uk

Failing mail now goes to the recipient’s junk folder rather than being lost, so if you missed something, it’s recoverable and someone will usually tell you. Keep reading the reports. After another two to four weeks with no problems, move to the final stage:

v=DMARC1; p=reject; np=reject; rua=mailto:dmarc-reports@example.co.uk

With p=reject, receivers refuse spoofed mail outright. Keep the reports coming in: whenever someone signs up for a new service that sends as your domain, this is where you’ll see it fail.

What about pct=?

Older guides tell you to ramp up with pct=25, pct=50 and so on, applying the policy to a percentage of failing mail. The DMARC standard was updated in May 2026 (RFC 9989) and pct was removed, partly because receivers never applied it consistently. If your record has a pct tag, remove it.

Its replacement, t=y, asks receivers to apply one level below your stated policy while you test. Be careful with it for now: receivers that haven’t caught up with the new standard ignore t= and apply your policy in full. Moving through none, quarantine and reject as separate steps, as above, works the same way everywhere.

Lock down domains that don’t send email

Spare domains, old brand names and domains you only use for a website are favourite targets for spoofing, because nobody is watching them. They can go straight to the strictest settings with no monitoring stage. Publish:

Some DNS control panels won’t accept a null MX. If yours doesn’t, leave MX empty; the SPF and DMARC records do the important work.

Troubleshooting

No reports are arriving

Check the record is at _dmarc.yourdomain and not _dmarc.yourdomain.yourdomain; the DNS lookup tool shows exactly what’s published. Then check the rua address is written as mailto: followed by the address, and that the mailbox exists and isn’t filtering the reports to junk. If it’s on another domain, make sure that domain has authorised it.

Mail from Microsoft 365 or Google Workspace fails alignment

Usually DKIM is signing with the provider’s default domain instead of yours. In Microsoft 365 that’s the .onmicrosoft.com domain until you turn DKIM on for your own; the DKIM for Microsoft 365 guide walks through it.

A service passes SPF and DKIM but still fails DMARC

That’s an alignment problem: it’s passing with its own domain, not yours. In the report, compare the DKIM domain (d=) and the SPF domain (the envelope sender or Return-Path) with your From domain. Setting up a custom sending domain in the service fixes it.

Customers say your email went to junk after enforcing

Ask them for the full headers of one of the messages and look at the Authentication-Results line. It names the check that failed and the domain it checked against, which points you to the service that needs fixing. If it’s urgent, drop back to p=none while you fix it, then work forwards again.

Quick checklist

• SPF and DKIM working for your main email provider
• List every service that sends as your domain
• Publish one DMARC record at _dmarc with p=none and a reporting address
• Read the reports for at least two to four weeks
• Set up DKIM with your own domain in every legitimate service
• Keep SPF to one record and under 10 lookups
• Move to p=quarantine, watch for problems, then p=reject
• Remove any old pct tag and add np=reject
• Lock down domains that never send email