How long does a DMARC rollout to p=reject take?

For a small business with a handful of sending systems, about four to six weeks: two weeks of monitoring at p=none, one to two weeks fixing alignment for each sender you find, one week at quarantine, then reject. Domains with many marketing and billing platforms take longer, because each platform needs its own domain authentication finished before the policy moves.

Do I still need the pct tag in my DMARC record?

No. RFC 9989, published in May 2026, removed pct along with rf and ri, so a new record should not include it. Stage the rollout with sp instead, which lets the root domain enforce while subdomains stay in monitoring, and treat the new t test-mode flag as a bonus rather than a safety net, since receiver support for it is recent.

Will p=reject stop people spoofing my company name?

It stops mail that puts your exact domain in the From header and cannot authenticate as you. It does nothing about lookalike domains or a display name that reads like your CEO sent from a free mailbox, because those messages never claim your domain. Those need user training and inbound filtering rules, not a DMARC policy.

DMARC: from p=none to p=reject without breaking mail

A DMARC record at p=none protects nothing. It asks mailbox providers to check whether mail claiming to come from your domain passes SPF or DKIM in a way that aligns with the address the reader sees, and then to send you a daily report of what they saw. Delivery does not change. Nobody stops impersonating you. What you get is evidence, and that is the entire job of the monitoring phase.

Enforcement is the part that protects you. p=quarantine asks receivers to treat failing mail as suspicious, and p=reject asks them to refuse it at the door. It is also the part that breaks things, because most companies send mail from places they have forgotten about: the invoicing platform, the CRM, the contact form on the website, the multifunction printer in the hallway that emails scanned PDFs from an address on your domain.

Both of the big consumer providers have already made the monitoring record table stakes. Google requires a DMARC record for domains sending more than 5,000 messages a day to Gmail accounts, and says the policy may be set to none. Microsoft uses the same 5,000-message threshold for consumer Outlook and Hotmail mailboxes, and non-compliant high-volume mail is refused with 550 5.7.515 Access denied. Neither of them requires enforcement. Your own exposure to being impersonated is what requires enforcement.

This is the order we run it in, and roughly the month it takes.

Step 1: publish the monitoring record, then wait two weeks

Get SPF and DKIM working first and give them at least 48 hours before DMARC goes up, which is what Google's setup guide asks for. Then publish a single TXT record at the _dmarc label:

_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com; fo=1"

Google's rollout guidance says a week of daily reports is usually enough to see all of your mail streams. For a small business two weeks is the better number, because it catches the monthly invoice run and the newsletter that only goes out on the first Tuesday. Do not shorten this window. Every day you skip here is a day of guessing later, and the guessing gets paid for on the day you turn enforcement on.

Reports arrive as gzipped XML, one per receiving provider per day, and that format now has a specification of its own in RFC 9990. Reading them by hand is possible and tedious. Paste one here instead and see the sources broken out:

Step 2: sort every source into three buckets

Write down every sending source the reports show you. Each one belongs in exactly one bucket:

Yours, and passing. A system you recognise that already passes SPF or DKIM in alignment. Nothing to do.
Yours, and failing. You recognise it, and it either fails outright or it passes SPF for the vendor's domain rather than yours. This is your work list, and it is where the outage risk lives.
Not yours. Sources you cannot account for, usually failing everything, often from residential address space. These are the reason you started. They are also the easiest, because enforcement handles them and nothing legitimate breaks.

Forwarding muddies the second bucket. A mailing list or a user-configured forward breaks SPF, because the forwarding server is not in your record, while the DKIM signature usually survives as long as the message is not modified. A source that fails SPF, passes DKIM and belongs to a university or a list host is almost always a forward, not an attacker.

Step 3: fix alignment, one sender at a time

Alignment is the rule people miss. DMARC does not care that SPF passed. It cares that the domain which passed matches the domain in the From header. A campaign that passes SPF for mailer.vendor.com while the reader sees you@example.com fails DMARC with a perfectly green SPF result. That combination is what surprises companies on the day they flip to reject.

Google Workspace and Microsoft 365

Both sign with DKIM using a selector published in your DNS, and on both the signing has to be switched on deliberately. Workspace generates the key in the Admin console and you publish it at google._domainkey. Microsoft 365 uses two CNAME records plus a toggle in Defender, and we wrote the full Microsoft 365 checklist separately. Once mail is signed with a key on your own domain, alignment holds even when the message is forwarded.

Marketing and transactional platforms

Mailchimp, HubSpot, Klaviyo, SendGrid, Mailgun and Amazon SES all sign with their own domain by default, which is exactly the misalignment described above. Every one of them has a domain authentication flow that hands you a set of CNAME records to publish so the signature carries your domain. Do this for each platform in bucket two before you touch the policy tag.

Invoicing, ERP and billing providers

Anything that mails documents on your behalf counts, electronic invoicing providers included. Ask each one for their SPF include and their DKIM record, and watch the 10-lookup budget in your SPF record as you add them. If a provider cannot sign as your domain at all, the honest fix is to have them send from a subdomain you control, something like facturacion.example.com, and manage that subdomain's policy separately instead of weakening the root domain for everyone.

Printers, scanners and line-of-business apps

The hallway scanner and the ten-year-old ERP that speaks SMTP are the classic casualties, because nobody remembers they exist until the PDFs stop arriving. Point them at your provider's authenticated relay using a real account on your domain, rather than letting them talk to the internet on their own.

Step 4: the percentage ramp is gone, so stage it differently

If you learned DMARC before 2026, you learned to ramp with pct=: publish p=quarantine; pct=10, then 25, then 50, then 100. That tag no longer exists. DMARC became a Standards Track protocol in May 2026 with RFC 9989, which obsoletes the informational RFC 7489 from 2015 and removes pct along with rf and ri. Plenty of vendor documentation still describes the percentage ladder. Do not build a new rollout on it.

Two tags cover what pct was actually used for.

t= is a test-mode flag. RFC 9989 defines it as a signal to the receiver about whether you want the policy declared in p, sp or np to actually be applied. It does not change report generation, and it has no effect at all when the policy is none. Support for it is new, so treat it as a courtesy from receivers who have implemented it rather than as a safety net you can lean on.

sp= carries most of the weight in a real rollout, because it lets the root domain and the subdomains move at different speeds:

_dmarc.example.com.  TXT  "v=DMARC1; p=quarantine; sp=none; rua=mailto:dmarc@example.com"

That record enforces on mail from example.com while every subdomain, the invoicing one included, stays in monitoring until you are ready for it. Reverse the two values when the subdomains are clean and the root still has a straggler you are chasing.

Step 5: the quarantine week

Move to quarantine once bucket two has been empty for seven consecutive days of reports. Then watch three things for a week: the aggregate reports for sources you have not seen before, your helpdesk for anyone asking whether you received their message, and a test mailbox outside the company that you send to from every internal system you can reach.

Quarantine is a soft failure by design. If something you missed starts landing in junk, you will hear about it quickly, and rolling back is one DNS edit away. Keep the TTL on the _dmarc record at 300 seconds for the whole rollout so a rollback takes minutes rather than a day, and raise it once you are settled.

Step 6: flip to reject and close the gaps

_dmarc.example.com.  TXT  "v=DMARC1; p=reject; sp=reject; np=reject; rua=mailto:dmarc@example.com"

np= is the tag most rollouts forget. It sets the policy for subdomains that do not exist in DNS at all, which is where a good share of impersonation goes: nobody ever published billing.example.com, so an attacker uses it and the mail gets judged by whatever sp says, or by p when there is no sp, which is usually looser than you would choose for a name that should never send anything. Setting it to reject costs nothing, because by definition no real system sends from a name you never published.

Two pieces of housekeeping belong here as well. Domains you own but never send from should carry a rejecting DMARC record of their own, since parked names get impersonated more often than the one you use daily. And if you want your logo shown next to your mail, BIMI requires the organizational domain to be at quarantine or reject with no sp=none quietly undoing it, so enforcement is the prerequisite rather than the reward.

Reject is not a finish line

Keep the rua address alive and keep reading. New vendors get onboarded, a marketing team signs up for a platform without telling anyone, a provider changes its signing domain. The reports are the only place you will see any of that before a customer does. Once a month is enough after the first quarter.

How Guanacos Tech helps

Most of the domains we take to p=reject arrive with a record someone published years ago at p=none and a reporting address nobody ever read. We inventory the senders from real report data, fix alignment sender by sender, stage the policy the way this article describes, and stay on the domain through the quarantine week so a rollback is a decision rather than a scramble. If you have been sitting at p=none because the next step looks risky, book a call and we will read your reports with you.

Moving DMARC from p=none to p=reject without breaking invoices, CRM mail or your printer