DMARC from p=none to p=reject, safely

A DMARC record with p=none only watches. Spoofed email that claims to be from your domain is still delivered. Most domains stop there because people are afraid of blocking their own invoices and newsletters. With the steps below, the move to p=reject is routine.

Why it matters now

• Since 2024, Google and Yahoo require bulk senders (around 5,000+ messages a day to their users) to have SPF, DKIM and DMARC. Microsoft introduced similar requirements for Outlook.com consumer mailboxes in 2025.
• Business email compromise often starts with a message that looks like it came from your own domain or a supplier's. Only an enforced DMARC policy stops receivers from delivering those.

Step 1: List everything that sends as your domain

Usually more than you think: Microsoft 365 or Google Workspace, the website's contact form, the CRM, invoicing and payroll systems, the helpdesk (HaloPSA, Zendesk), marketing (Mailchimp, HubSpot), scanners and printers, and monitoring tools. Ask each team, and let the DMARC reports in step 3 find the rest.

Step 2: Make SPF and DKIM pass and align

DMARC passes when either SPF or DKIM passes and the domain it checked matches the visible From domain (alignment).

• DKIM is the one to rely on. Turn on DKIM signing with your own domain in every service that supports it (Microsoft 365, Google, Mailchimp, HubSpot, SendGrid all do). DKIM survives forwarding; SPF does not.
• SPF: one record, every legitimate sender included, under 10 DNS lookups, ending in ~all for now. Many SaaS senders use their own bounce domain, so SPF won't align for them; that is fine when DKIM aligns.

Step 3: Publish p=none with reporting

_dmarc.example.com  TXT  "v=DMARC1; p=none; rua=mailto:[email protected]; fo=1"

Receivers will send daily aggregate reports (XML) to the rua address listing every IP that sent mail as your domain and whether it passed. Use a dedicated mailbox or a DMARC reporting service; raw XML is not meant to be read by hand.

Step 4: Read two to four weeks of reports

For each sending source in the reports, decide:

Step 5: Quarantine, gradually

v=DMARC1; p=quarantine; pct=25; rua=mailto:[email protected]; fo=1

Failing mail now goes to spam for 25% of messages. Raise pct to 50 and then 100 over a few weeks while watching the reports and asking teams whether anything went missing.

Step 6: Reject

v=DMARC1; p=reject; rua=mailto:[email protected]; fo=1

Receivers now refuse spoofed mail outright. Then tighten the rest:

• Change SPF from ~all to -all once every sender is listed.
• Make sure sp= (subdomain policy) is not none, or attackers simply spoof billing.example.com.
• Lock down domains that never send mail: v=spf1 -all and v=DMARC1; p=reject. Parked domains are favourite spoofing targets.
• Rotate DKIM keys to 2048-bit if any are still 1024-bit.

Common mistakes

• Two DMARC records on the same name: receivers ignore DMARC entirely.
• Jumping straight to p=reject without reading reports.
• A rua mailbox on another domain without the authorisation record that domain needs.
• Staying at p=none for years. Monitoring is a phase, not a destination.