How to move your DMARC policy to p=reject safely

p=reject means "if this message isn't authenticated, throw it away". It's the only policy that actually stops someone sending email in your name — and it's also the only one that can make your own email disappear if one of your legitimate tools isn't set up properly. The safe method fits in one sentence: three steps, none → quarantine → reject, and you never move to the next one until you've read your reports. Budget 6 to 10 weeks end to end, of which 90% is reading and 10% is typing.

One thing worth knowing before you start: nobody is forcing you to reach p=reject. Gmail, Yahoo and Outlook.com all require a published DMARC record, and all three explicitly accept p=none. You go to p=reject to protect your name, not to tick a box.

What we don't do: we never touch your DNS zone. This guide tells you what to publish, when, and what a report that says "you're clear to go" actually looks like. You're the one who saves it, in your own account, with your own credentials.

The three values to copy, in order

You only ever have one record, named _dmarc, and you change its value at each step. You never add a second one — a domain with two DMARC records has no DMARC at all.

Step 1 — watch (2 to 4 weeks)

What you must replace: YOU@YOUR-DOMAIN.com with an address you actually read. Without rua=, you'll receive no reports, and the rest of this guide becomes impossible to follow.

p=none means "watch and tell me". Nobody is blocked, nothing changes for your recipients, and you start receiving a list of everything sending in your name — including the things you'd forgotten about.

Step 2 — set aside (2 to 4 weeks)

p=quarantine means "if it isn't authenticated, put it in junk". A legitimate email you overlooked isn't lost: it lands in the spam folder, your recipient can retrieve it, and they'll call you about it. This is the step that makes a mistake visible without making it irreversible — it's the real safety net of the whole operation.

Step 3 — reject

p=reject means "throw it away". Google puts it bluntly: "the reject policy means that messages that don't pass DMARC are rejected by receiving servers and never delivered."

Three options you can add — and one you should stop using

Why we tell you to forget pct=. This setting was for years the standard way to tighten gradually — p=quarantine; pct=5, then 25, then 100. It was removed from the DMARC standard by RFC 9989, published in May 2026, which replaces RFC 7489. In practice: servers that follow the new standard ignore your pct= and apply your policy to 100% of messages. You think you're enforcing at 5%, you're enforcing at 100% for a share of your recipients — the exact opposite of what you were trying to do.

Worth flagging, because you will run into it: Google's own documentation still recommends pct=5 in its DMARC rollout tutorial. That isn't carelessness on their part, it's a tutorial written before the new standard. But if you follow that method today, you're building your gradual rollout on a tag the standard has retired. The three-step method here gets you to the same place — more slowly, more safely, and without depending on a dead tag.

So what about t=y? It's the replacement the new standard provides. t=y asks the receiving server "not to apply the policy, but instead apply any special handling rules it might have in place". In practice p=reject; t=y behaves like p=quarantine, and p=quarantine; t=y like p=none. Elegant on paper. In reality the standard dates from May 2026 and we don't yet know what share of receiving servers implement it — a server that doesn't know t= ignores the tag and enforces your p=reject in full. Our position: don't publish p=reject; t=y believing you're shielded from the risk. Go through p=quarantine, which every receiver has understood for a decade.

⚠️ What about strict alignment (adkim=s / aspf=s)? Don't — unless you know exactly why. So far every argument on this page has pointed towards tightening. Here's the documented reason to stop short: strict alignment breaks legitimate email at real services. Shopify says it in its own documentation: make sure your DMARC record "doesn't include adkim=s or aspf=s" — strict alignment fails its transactional emails, which are sent from a subdomain. HubSpot says the same for its own reasons: adkim and aspf "should both be set to r". Relaxed alignment (r, the default — you don't have to write anything) accepts subdomains of the same domain, and it's the right setting for almost everyone. p=reject with relaxed alignment already protects your name very well.

The path: what to do at each step

Before you start — two non-negotiable prerequisites

1. SPF and DKIM must be in place and working for at least 48 hours. Google is explicit: "set up DKIM and SPF at least 48 hours before setting up DMARC." If you're not there yet, start with your host's guide (links at the bottom) and come back.
2. You need a rua= address you actually read. DMARC reports are compressed XML files, unreadable by eye once you're getting forty a day. That's exactly the work we do for you — but you can start by hand.

Step 1 → 2: the questions your reports have to answer

You only move to quarantine when you can answer yes to all four:

1. Do I recognise every sender showing up in my reports? Write the list down. It's almost always longer than you expected: your host's mailboxes, your office suite, your campaign tool, your invoicing software, your website's contact form, your CRM, your ticketing system, your recruitment provider, the ERP that emails purchase orders, and sometimes the copier down the hall.
2. Does each of them pass SPF or DKIM — and more importantly, is it aligned? See mistake 2 below: that is not the same question.
3. Is the remaining unauthenticated volume small and identified? A small tail of failures is normal (forwarding, mailing lists). A tail you can't explain is not.
4. Have I watched for at least two full weeks? Monthly sends — invoicing, payroll, the newsletter — don't show up in one week of reports. That's exactly the kind of sender people discover by breaking it.

Step 2 → 3: the same list, plus one

Two to four weeks on quarantine, then:

5. Has anyone complained? That's what step 2 is for. If nobody has reported a missing email or found one in junk, and your reports are clean, you can move to reject.

Where the value gets changed

You edit the _dmarc record in your DNS zone, wherever it's hosted. The exact path depends on your provider — we've written one guide per provider:

• GoDaddy
• Namecheap
• Cloudflare
• Squarespace
• AWS Route 53
• Hostinger
• Bluehost

A habit worth picking up before you tighten: drop the TTL on your _dmarc record to 300 seconds (5 minutes) 24 hours before moving to the next step. If you have to roll back, the rollback takes 5 minutes instead of a day. Put the TTL back up once things are stable.

And the corollary almost nobody writes down — AWS is the only one that documents it: "Changing the TTL now won't make your change take effect faster. DNS resolvers already have the value cached, and they won't get the new setting until the amount of time that was specified by the old setting passes." In other words: lowering the TTL after you've tightened does nothing. The game is played before — hence the 24-hour head start.

The 3 mistakes we see most often

1. Jumping straight from p=none to p=reject

This is the one that costs the most, and it always comes from the same good intention: "quarantine is a half-measure, let's do this properly." Except quarantine isn't a half-measure — it's the only step where a mistake is recoverable. Under reject, the email isn't in junk: it doesn't exist. Your recipient will never find it, and you'll only hear about it when someone calls, if you're lucky.

How you spot it: your accountant stops receiving invoices, a client says they "never got" your quote, your contact form stops doing anything. The common thread: it started the day you changed your DMARC record.

The fix: go back to p=none immediately — one edit and a TTL — let things settle, then restart the method at step 1. Rolling back is instant and has no side effects. That's the great thing about DMARC.

2. Confusing "SPF passes" with "SPF is aligned"

The most technical trap on this page, and the only one where the precise term is worth learning.

An email sent by your campaign tool can happily pass SPF — because the tool uses its own envelope address, on its own domain, with its own valid SPF — while failing DMARC. DMARC doesn't ask "does SPF pass?", it asks "is the domain that passes SPF the same as the one shown in the From: header?" That's alignment. Google says it in one line: "to pass DMARC authentication, outgoing messages must pass either SPF or DKIM" — meaning, in an aligned way.

Concrete case: Brevo and Mailchimp don't even need an SPF record to authenticate your domain; they align through DKIM only. A tool that doesn't offer DKIM signing under your domain will never be aligned, whatever you do to your SPF.

How you spot it: in your reports, a source shows spf: pass and dmarc: fail on the same row. That's the exact signature.

The fix: turn on DKIM signing under your domain at that provider. If the provider doesn't offer it, you have two honest options: have it send from a dedicated subdomain (notifications.yourdomain.com) with its own sp=, or change provider. There is no third option — and definitely not "switch -all to ~all". As far as DMARC is concerned, ~all and -all are the same SPF failure.

3. Forgetting forwarding and mailing lists

When a recipient auto-forwards your email to another address, or when your message goes through a mailing list that adds [Association] to the subject and a footer at the bottom, two things happen: SPF fails (the technical sender is no longer you) and the DKIM signature breaks if the message was modified. Google confirms it: a signature fails when "the message was modified during transit or after the DKIM signature was added to the message".

How you spot it: a stubborn residue of failures in your reports, coming from servers you don't recognise, at low volume and regularly. Often universities, associations, work addresses forwarded to a personal one.

The fix: there isn't a complete one, and it matters that you know this before you tighten, not after. A well-configured mailing list rewrites the sender to avoid the problem. For the rest, it's collateral damage you accept knowingly when you move to p=reject. If your business depends on messages being forwarded at scale, p=quarantine may be your sensible destination — and that's a defensible choice.

How long before it takes effect

• Changing the record: saved immediately at your provider, visible on the internet in anything from minutes to 48 hours depending on who that is (usually 5-15 minutes at Cloudflare, up to 48 hours at GoDaddy).
• The old value stays cached for as long as the TTL you had set before the change. Hence the advice to lower it in advance — doing it afterwards achieves nothing.
• Reports: the first ones arrive 24 to 72 hours after you publish, then roughly once a day, per receiving domain. So you need two weeks minimum per step to have anything to read.
• Total, in practice: 6 to 10 weeks for an ordinary business domain. Shorter if you have a single sender; longer if you discover tools that need reconfiguring, which is the normal case.

The one number to remember: rolling back is instant. That's what makes the whole thing reasonable.

Next steps

• My emails go to spam even though SPF, DKIM and DMARC pass
• How to set up SPF, DKIM and DMARC on GoDaddy
• How to set up SPF, DKIM and DMARC on Namecheap
• How to set up SPF, DKIM and DMARC on Cloudflare
• Set up Google Workspace email authentication on GoDaddy
• Set up Microsoft 365 email authentication on GoDaddy