DMARC Policy: How to Move from p=none to p=reject Safely

Your DMARC Record Says p=none. Now What?

At some point you probably added a DMARC record to your domain, because Gmail started rejecting your invoices and reminders or a checker tool showed a red warning. You published v=DMARC1; p=none, the warning went away, and nobody has touched it since.

That record keeps you compliant, but it does nothing to stop someone sending fake invoices from your domain. The real protection lives at p=reject. Everyone has heard the horror story: a company flips to reject and suddenly invoices from its accounting software and password resets from its website disappear. This guide shows you how to get to reject without that happening.

Before you read on, run your domain through our free DMARC checker to see your current policy, pct and report address, so you know which step of this plan you are on.

What DMARC Adds on Top of SPF and DKIM

SPF and DKIM each answer a narrow technical question. SPF asks: is this server allowed to send for the domain in the envelope sender (the Return-Path)? DKIM asks: was this message signed by the domain in the d= tag, and is the signature intact? Neither of them looks at the address your recipient actually sees, the one in the From header.

That gap is exactly what spoofers use. A scammer can pass SPF for their own throwaway domain while putting billing@yourcompany.com in the From line. DMARC closes the gap with one rule called alignment: a message passes DMARC only if SPF or DKIM passes and the domain that passed matches the From domain.

• SPF alignment: the Return-Path domain matches the From domain.
• DKIM alignment: the d= domain in the DKIM signature matches the From domain.

One aligned pass is enough. In practice DKIM alignment is the one to rely on, because it survives forwarding, while SPF often breaks when a message is relayed. If your SPF or DKIM itself is shaky, fix that first. Our guides to fixing SPF record errors and common DKIM setup mistakes cover the usual culprits.

Anatomy of a DMARC Record

DMARC is a single TXT record published at _dmarc.yourdomain.com. A typical starting record looks like this:

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com

• v=DMARC1: the version. It must come first, exactly like this.
• p=: the policy for messages that fail. none means monitor only, quarantine sends failures to spam, reject blocks them.
• rua=mailto:...: where receivers send daily aggregate reports. Without it you are flying blind.
• pct=: the share of failing mail the policy applies to (default 100), handy for a gradual ramp-up.
• sp=: the policy for subdomains. If you leave it out, subdomains inherit p.
• adkim= and aspf=: alignment mode. r (relaxed, the default) accepts any subdomain of your organisational domain, so mail.yourdomain.com aligns with yourdomain.com. s (strict) requires an exact match and breaks many legitimate setups, so stick with relaxed.

The enforced end state:

v=DMARC1; p=reject; sp=reject; adkim=r; aspf=r; rua=mailto:dmarc-reports@yourdomain.com

The Phased Rollout: From none to reject

Moving to reject is a short project, not a single DNS change. Follow these five steps in order.

1. Inventory every service that sends as your domain

Write down everything that puts your domain in the From line. Most small businesses find more than they expected:

• Your mailbox provider (Google Workspace, Microsoft 365 or your hosting company)
• Invoicing and accounting software that emails invoices and reminders
• CRM, helpdesk and booking tools
• Your email platform for reminders, statements and client notices
• Website contact forms, online shop notifications, payroll or HR systems

2. Publish p=none with reporting

Start with p=none and a working rua address. Leave it for at least two to four weeks so you capture the monthly cycle: invoice runs, payroll, statements. This step changes nothing for delivery; it just turns the lights on.

3. Fix alignment for every legitimate sender

For each legitimate service that fails alignment, set up DKIM signing with your own domain (usually a CNAME or TXT record the service gives you) and, where offered, a custom Return-Path on your domain. A service that can only send from its own domain should send from its own domain, not yours.

4. Move to quarantine, gradually

When your reports show legitimate sources passing consistently, switch to:

v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc-reports@yourdomain.com

Watch the reports for a week or two, then raise pct to 50 and then 100. If something legitimate shows up failing, only a slice of its mail lands in spam.

5. Move to reject

After a clean stretch at p=quarantine; pct=100, switch to p=reject. Keep the rua address and keep reading the reports. Every new tool your team adopts is a new sender to align.

How to Read Aggregate Reports Without Losing Your Mind

Aggregate (rua) reports arrive as zipped XML files, usually one per receiver per day. Feed them into a DMARC report parser and every row boils down to a few fields: the sending IP address, how many messages it sent, whether SPF and DKIM passed, whether they aligned, and what the receiver did with the mail.

Sort the sources into four buckets:

• Legitimate and aligned: your mailbox provider and correctly configured tools. Nothing to do.
• Legitimate but not aligned: the invoicing tool or CRM you forgot. Fix these before enforcing.
• Forwarded mail: messages relayed by mailing lists or forwarding rules, often failing SPF but passing DKIM. Aligned DKIM covers them.
• Unknown sources: IPs you do not recognise sending as your domain. That is usually spoofing, and exactly what reject will stop.

Common Mistakes That Lose Real Email

• No rua address. A policy without reports gives you no data to decide when it is safe to enforce.
• Jumping straight to reject. Skipping the monitoring phase is how invoices and password resets vanish overnight.
• Forgetting third-party senders. The invoicing tool, CRM or booking system that sends as your domain but signs DKIM with its own is the classic casualty.
• Ignoring subdomains. Without sp=, subdomains inherit your main policy. Check that nothing legitimate sends from a subdomain before you enforce.
• Publishing two DMARC records. If _dmarc.yourdomain.com has more than one v=DMARC1 TXT record, receivers treat it as invalid and ignore DMARC entirely. Edit the existing record instead of adding a second one.

Why p=none Is No Longer Optional

Since February 2024, Gmail and Yahoo require bulk senders to publish a DMARC record with at least p=none and to have the From domain aligned with SPF or DKIM. Microsoft followed with similar rules for Outlook.com. Our overview of Gmail, Yahoo and Microsoft bulk-sender requirements covers the full list.

How MailerBit Fits Into Your DMARC Plan

If you send payment reminders, statements or fee notices with MailerBit, that sender is easy to cross off your inventory. Before you can send a campaign, MailerBit asks you to verify your own domain and generates the exact DNS records to add: a DKIM key that signs your mail with your domain, and a custom Return-Path so bounces run through your domain instead of ours. Both line up with your From address, which is what DMARC alignment checks.

Because you send from your own verified domain, you build your own domain reputation, and accounts with bounce rates above 5% or complaint rates above 0.1% are paused automatically. The DMARC record itself stays in your hands: you publish it in your DNS and can check it any time with our free tools.

Get to reject and Stay There

DMARC enforcement is the difference between “we have authentication” and “nobody can send invoices pretending to be us.” Take an inventory, collect reports, fix alignment, then step up through quarantine to reject. It takes a few weeks, not a weekend.

Want your reminders and statements to be one of the senders that passes on day one? Create your MailerBit account, verify your domain and send your first campaign from an address your clients can trust.