DMARC Rollout: p=none to p=reject Without Losing Mail

The fastest way for a small business to lose its own email in a DMARC policy rollout is to jump straight to p=reject. Under reject, messages that fail DMARC are rejected by receiving servers and never delivered. That includes the invoices from a billing tool nobody set up DKIM for.

A staged move from none to quarantine to reject, using the pct= tag and the daily aggregate reports, gets a domain to full enforcement without dropping mail you meant to send.

What a DMARC record does and where it lives

DMARC checks whether a message passed SPF or DKIM for a domain that lines up with the domain in the From address. A message passes DMARC if one or both of the SPF or DKIM checks pass. Alignment is relaxed by default: the organizational domains must match, and subdomains are allowed. So mail signed for billing.example.com can pass for example.com. Relaxed alignment gives enough spoofing protection for most domains, and strict alignment can get mail from your own subdomains rejected or sent to spam. Leave alignment at the default.

The record is a DNS TXT record whose host is _dmarc.example.com. Neither of the big mail platforms manages it for you. Microsoft 365 has no admin portal or PowerShell cmdlet for DMARC records on custom domains, and Google Workspace needs nothing done in the Google Admin console. All of the work happens at your registrar or DNS provider.

Two details at the DNS host trip people up. First, some domain hosts add the domain name automatically. Before you save, check whether the host field wants _dmarc or the full _dmarc.example.com. Second, only one _dmarc TXT record should exist. A second record left over from an earlier attempt is an error, so delete it.

Inside the record, the v and p tags must be listed first, and the other tags can go in any order. Get the timing right too. Allow 48 hours after setting up SPF or DKIM before setting up DMARC.

Stage 1: publish p=none and read the reports

The whole rollout fits in three records:

1v=DMARC1; p=none; rua=mailto:dmarc@example.com
2v=DMARC1; p=quarantine; pct=5; rua=mailto:dmarc@example.com
3v=DMARC1; p=reject; rua=mailto:postmaster@example.com,dmarc@example.com

p=none asks receivers to take no DMARC action, and it is the value for testing and tuning the DMARC policy. Mail is delivered as before. What changes is that receivers start sending aggregate reports to the rua address.

Choose that address carefully. Using your own email address is not recommended, and large organizations can get hundreds or even thousands of reports a day. Send the reports to a specific mailbox or Microsoft 365 Group rather than a user's mailbox, and designate specific people to monitor them.

If the rua address is on a different domain, such as a reporting service, that domain must publish a TXT record authorizing the report delivery. Without it, receivers don't deliver DMARC reports to the external address. For contoso.com sending reports to fabrikam.com, fabrikam.com publishes a TXT record at contoso.com._report._dmarc with the value v=DMARC1;.

Reports arrive about once per day as an XML email attachment that is likely GZIP compressed. Start with rua only, and add ruf later if needed, because forensic reports can generate high volume. Gmail and Microsoft 365 will not send forensic reports either way: Gmail doesn't support the ruf tag, and Microsoft 365 doesn't send DMARC forensic reports.

The reports do not show everything. Not all receivers send reports, and coverage is typically 70-90% of total mail volume. If a sender's mail only goes to receivers that don't report, it will never appear. Check the reports against your own list of every tool that sends as your domain: the CRM, the accounting package, the website contact form, the newsletter platform.

Keep p=none for one week, because one week is usually enough for the daily reports to cover all your mail streams. After that, review aggregate reports weekly during initial deployment, and monthly once stable.

What the reports tell you to fix

Three patterns show up in the reports. The first is a known IP where DKIM passes but DKIM alignment fails. That means the service signs DKIM with its own domain, and the fix is to configure custom DKIM at the service with your domain as d=. For any third-party sender, also make sure the provider's envelope sender domain matches your domain, because SPF alignment depends on it. Google Workspace customers can also route the provider's outgoing mail through Google using the SMTP relay service setting.

For bulk or third-party senders, use a subdomain such as marketing.contoso.com instead of your main email domain, so that issues with mail from those services don't affect the reputation of mail sent by users in your main domain.

The second pattern is an unknown IP sending high volume, with every message failing. That is a potential spoofing or phishing campaign, and no action is needed because your DMARC policy is protecting recipients. Under p=none, a Microsoft 365 recipient takes no DMARC-specific action, though other filtering still applies.

The third pattern is forwarded mail from mailing list IPs, all failing. Forwarding breaks SPF, and body modification breaks DKIM. Use ARC or accept some failures. Some false positives are almost inevitable.

Stages 2 and 3: quarantine, then reject, with pct=

When the only failures left in the reports are spoofing and forwarding, move to p=quarantine with a pct= value. pct sets the share of failing messages the policy applies to. Example increments are 10, 25, 50, 75 and 100. A small organization might start with 10% of its messages and a large one with 1%, and the sample quarantine record above uses pct=5.

One change to the standard matters here. RFC 9989, published in May 2026, replaced RFC 7489 and removed the pct tag. It found that receivers usually applied pct accurately only at 0 or 100, and it adds a t=y test flag that asks receivers not to apply the policy yet. Google's setup guide still documents pct and recommends it for a rollout, so the stages below still work. Treat a partial pct as a rough dial, not an exact share.

If you leave pct out, the default is pct=100, the default in RFC 7489, the earlier DMARC specification. A quarantine record with no pct therefore applies to every failing message from the first day. The allowed range is not the same everywhere. Google requires a whole number from 1 to 100, while RFC 7489 allowed 0 to 100. Any value from 1 to 100 is valid under both.

A low pct does not shrink the reports. Receivers must include all relevant message data in any reports produced, whatever the pct. At pct=10, the reports still show every message that would be affected at 100.

An example sequence for the subdomain marketing.contoso.com runs none, quarantine, then reject. The records below show where each stage ends, with the ruf= tags removed to match a rua-only start. Do not copy them as a sequence. The quarantine record reaches pct=100 only after the pct steps above, and at the reject stage you can use pct= the same way:

1Hostname : _dmarc
2TXT value : v=DMARC1; p=none; pct=100; rua=mailto:rua@marketing.contoso.com
3
4Hostname : _dmarc
5TXT value : v=DMARC1; p=quarantine; pct=100; rua=mailto:rua@marketing.contoso.com
6
7Hostname : _dmarc
8TXT value : v=DMARC1; p=reject; pct=100; rua=mailto:rua@marketing.contoso.com

For a parked domain that sends no mail, the record is:

1Hostname : _dmarc
2TXT value : v=DMARC1; p=reject;

Under RFC 7489, with p=reject and pct below 100, receivers should treat mail outside the sample as though the quarantine policy applies. So p=reject; pct=25 asks receivers to reject a quarter of failing mail and quarantine the rest. What happens to quarantined mail depends on the destination email system. Microsoft 365 marks the rejected share with action=pct.reject in the Authentication-Results header.

When a recipient's Microsoft 365 tenant has Honor DMARC record policy turned On (recommended), your failing mail lands in their Junk Email folder (configurable to quarantine) under p=quarantine. Under p=reject it is rejected during SMTP with 550 5.7.1. That bounce tells you a failing message was rejected, not why it failed. The aggregate reports show the source IP. It could be one of your own senders that is not yet aligned, or forwarded mail, where forwarding breaks SPF. At Gmail, unauthenticated messages can be marked as spam or rejected with a 5.7.26 error.

If you send from Microsoft 365, enforcement also affects your outbound path. Outbound mail that fails DMARC at the destination is routed through the High-risk delivery pool if the domain's policy is p=reject or p=quarantine, and there is no override.

Inbound mail is a separate case. A partner's domain can fail DMARC, and you still need their mail. For that, Microsoft 365 offers a trusted ARC sealer (preferred), a mail flow rule matching sender IP plus sender domain, or a temporary Tenant Allow/Block List allow entry that expires in 30 days.

There is also a branding reason to finish the rollout. BIMI, the standard that shows a logo next to your mail, is not supported at p=none or with pct below 100.

Which order to do it in

Order the work by how many services send as each domain. Start with a domain or subdomain with low mail volume or fewer email sources and take it through none, quarantine and reject. Then repeat for the remaining subdomains in order of increasing volume or complexity, saving the parent domain for last. Take a business with one main domain, a newsletter subdomain and two spare domains that send nothing. The spare domains get v=DMARC1; p=reject; on day one, with no pct. The newsletter subdomain goes next, and the main domain goes last.

The parent goes last because a domain's DMARC record covers all subdomains, including nonexistent ones, that don't have their own record. Without an sp tag, subdomains inherit the parent domain's policy. If you set p=reject on example.com before a subdomain with live senders has its own record, that subdomain moves to reject too.

Gmail's DMARC requirement has applied since February 1, 2024 to senders of more than 5,000 messages per day to Gmail accounts, and for that requirement the enforcement policy can be set to none. One suggested pace, not a Gmail or Microsoft rule: one week at none, then one pct step per weekly review that shows no failures from your own senders.

After every DNS change, confirm what is published and that only one record comes back. Run dig +short TXT _dmarc.example.com., nslookup -type=TXT _dmarc.domain.com, or this PowerShell command:

1Resolve-DnsName -Name "_dmarc.contoso.com" -Type TXT | Select-Object -ExpandProperty Strings

Key Takeaways

• If nobody on the team will parse gzip-compressed XML every week, pick a DMARC reporting service before you publish p=none, because reporting services describe any custom values required in the DMARC TXT record.
• If a sending service cannot sign DKIM with your domain, send its mail from a subdomain, publish a separate DMARC record for that subdomain, and have the service sign with the subdomain as d=.
• If 550 5.7.1 bounces start at a p=reject step and the reports trace them to one of your own tools, fix SPF or DKIM alignment at that tool before anyone creates an override.

References

• Set up DMARC to validate email in Microsoft 365 — pass rule, relaxed default, no portal or cmdlet, single record, report format and frequency, coverage, report mailbox and named monitors, rua/ruf, reporting services and custom record values, report patterns and fixes, subdomain reputation and the subdomain DKIM signing strategy, p=none inbound behaviour, pct default and steps, quarantine handling, 550 5.7.1 rejection, forwarding failures, high-risk pool, allow-list options, fixing alignment before overrides, subdomain and parent-last order, parked-domain record, authorization record, nslookup and Resolve-DnsName checks, and the marketing.contoso.com example sequence the stage end-state records are based on
• Set up DMARC (Google Workspace Help) — host field, 48-hour wait, no Admin console step, tag order, report mailbox advice, report volume, third-party sender checks, SMTP relay, pct range, sp inheritance, alignment, Gmail and ruf, BIMI requirements
• Recommended DMARC rollout (Google Workspace Help) — one week at p=none, starting percentages by organization size, meaning of reject; source of the three example DMARC records
• Email sender guidelines (Gmail Help) — February 1, 2024 start, 5,000-per-day bulk-sender threshold, p=none accepted, 5.7.26 error
• RFC 9989: DMARC — replaces RFC 7489, removes pct (receivers applied it accurately only at 0 or 100), adds the t test flag
• RFC 7489: DMARC (obsoleted) — pct range and default, quarantine treatment of sampled-out mail under reject, reports include all mail