SPF, DKIM and DMARC: A Staged Rollout to p=reject
A practical plan for moving a domain from no policy to DMARC enforcement without blocking legitimate mail, covering Gmail and Outlook.com sender requirements, Microsoft 365 and Google Workspace DKIM, and rollback.
As of 11 October 2026. Mailbox provider requirements change. Check the Google and Microsoft pages in the sources before you change DNS.
Why email authentication became a deliverability requirement
For years SPF, DKIM and DMARC were treated as optional hygiene. That changed when the largest consumer mailbox providers started rejecting mail that is not authenticated.
- Gmail. Since February 2024, all senders to personal Gmail accounts need SPF or DKIM, valid forward and reverse DNS, and TLS. Senders of more than 5,000 messages a day also need both SPF and DKIM, a DMARC record (the policy can be
p=none), a From: domain aligned with the SPF or DKIM domain, one-click unsubscribe for marketing and subscribed mail, and a user-reported spam rate below 0.3%. Google states that from November 2025 it is ramping up enforcement, with temporary and permanent rejections for non-compliant traffic. - Outlook.com. Since 5 May 2025, Microsoft requires domains that send more than 5,000 messages a day to outlook.com, hotmail.com and live.com addresses to pass SPF and DKIM and publish DMARC of at least
p=none, aligned with SPF or DKIM. Non-compliant messages are rejected with a 550 error stating that the sending domain does not meet the required authentication level.
p=none satisfies these minimums, but it does not stop anyone from spoofing your domain. The goal of a rollout is to reach p=reject without blocking your own legitimate mail.
How SPF, DKIM and DMARC fit together
| Standard | What it checks | Common failure |
|---|---|---|
| SPF (RFC 7208) | Whether the sending IP is authorised for the envelope sender (MAIL FROM) domain | More than 10 DNS-querying mechanisms returns a permerror (RFC 7208, section 4.6.4). Forwarding breaks SPF because the forwarder’s IP is not in your record. |
| DKIM (RFC 6376) | A cryptographic signature from the signing domain (d=) over selected headers and the body | Mailing lists and gateways that rewrite the subject or body invalidate the signature. Third-party senders that sign with their own domain will not align. |
| DMARC (RFC 7489) | That SPF or DKIM passed and the passing domain aligns with the visible From: domain; publishes a policy and a reporting address | Senders that pass SPF or DKIM for a different domain still fail DMARC. |
Step 0: inventory every system that sends as your domain
Most failed DMARC projects fail here. Before changing policy, list every sender: Microsoft 365 or Google Workspace, marketing and newsletter platforms, CRM and ticketing systems, invoicing and HR platforms, website contact forms, monitoring alerts, scanners and on-premises applications. Publish a monitoring-only DMARC record first and use the aggregate reports to find the senders nobody listed.
The staged rollout
Durations below are example targets. Move to the next stage when the exit criteria are met, not when the calendar says so.
| Stage | DMARC policy | Example duration | Exit criteria |
|---|---|---|---|
| 1. Monitor | p=none with rua reporting | 2–4 weeks | Every legitimate source in the aggregate reports is identified and has an owner |
| 2. Fix | p=none | 2–6 weeks | Each legitimate source passes SPF or DKIM with alignment; DKIM is preferred because it survives forwarding |
| 3. Quarantine | p=quarantine, optionally ramped with pct | 2–4 weeks | No legitimate source appears in the failing traffic; help-desk reports of missing mail are resolved |
| 4. Reject | p=reject | Ongoing | Reports reviewed monthly; new senders are onboarded with DKIM before they go live |
Illustrative DNS records
Illustrative example for the reserved domain example.com. Replace the include and the documentation IP range (192.0.2.0/24) with your real senders. Keep DNS TTLs short (for example 300–3600 seconds) during the rollout so changes and rollbacks take effect quickly.
; SPF: authorise Microsoft 365 plus one on-premises relay; soft-fail the rest during rollout
example.com. TXT "v=spf1 include:spf.protection.outlook.com ip4:192.0.2.10 ~all"
; Stage 1 DMARC: monitor only, send aggregate reports
_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:[email protected]"
; Stage 3 DMARC: quarantine, applying the policy to 25% of failing mail at first
_dmarc.example.com. TXT "v=DMARC1; p=quarantine; pct=25; rua=mailto:[email protected]"
; Stage 4 DMARC: reject, and apply the same policy to subdomains
_dmarc.example.com. TXT "v=DMARC1; p=reject; sp=reject; rua=mailto:[email protected]"
; Parked domain that never sends mail
parked-example.com. TXT "v=spf1 -all"
_dmarc.parked-example.com. TXT "v=DMARC1; p=reject"
If aggregate reports go to a mailbox on a different domain (for example a reporting service), that domain must publish an authorisation record for your domain, as described in RFC 7489 section 7.1.
DKIM in Microsoft 365
For each custom domain, Microsoft 365 uses two selectors, selector1 and selector2, published as CNAME records that point to Microsoft-hosted keys. Microsoft documents two formats: the older format points to <initial-domain>.onmicrosoft.com, and custom domains added from May 2025 use a newer dkim.mail.microsoft format. The two formats cannot coexist for the same selector, so read the exact values from your tenant rather than copying them from an article:
# Exchange Online PowerShell (illustrative; replace example.com)
Get-DkimSigningConfig -Identity example.com | Format-List Name,Enabled,Status,Selector1CNAME,Selector2CNAME
# After both CNAME records are published and resolvable:
Set-DkimSigningConfig -Identity example.com -Enabled $true
# Move to 2048-bit keys. The new key starts signing after about four days (96 hours);
# the change applies to the next active selector first.
Rotate-DkimSigningConfig -Identity example.com -KeySize 2048
If the CNAME records cannot be found, Set-DkimSigningConfig returns an error with the values to publish. Fix the records and try again after DNS propagates.
DKIM in Google Workspace
In the Google Admin console, open the Gmail Authenticate email setting, generate a DKIM key for the domain (2048-bit where your DNS host supports long TXT records; Gmail’s sender guidelines require at least 1024 bits), publish the TXT record at the selector shown (the default prefix is google, so the record name is google._domainkey), then select Start authentication. Some DNS hosts require long keys to be split into several quoted strings in one TXT record.
One-click unsubscribe for bulk mail
Marketing and subscribed messages sent to Gmail at volume need one-click unsubscribe. RFC 8058 defines it with two headers, and both must be covered by a valid DKIM signature:
List-Unsubscribe: <https://example.com/unsubscribe/opaque-token>
List-Unsubscribe-Post: List-Unsubscribe=One-Click
Most email service providers add these headers automatically. Verify it with a test message rather than assuming it.
What breaks, and how to fix it
| Symptom | Likely cause | Fix |
|---|---|---|
SPF permerror in reports | Too many include mechanisms; more than 10 DNS lookups | Remove unused includes, move senders to subdomains, or rely on aligned DKIM for third parties |
| Forwarded mail fails SPF | The forwarder’s IP is not in your SPF record | Expected behaviour; make sure DKIM signs everything so DMARC can still pass |
| Mailing-list posts fail DKIM | The list adds a footer or tags the subject | Receivers may use ARC from the list; agree with list owners to avoid modifying messages where possible |
| A SaaS platform fails DMARC | It signs with its own domain and uses its own bounce domain | Configure custom DKIM (and a custom return-path if offered) for your domain in that platform |
| Subdomain mail is rejected unexpectedly | Subdomains inherit p when sp is not set | Inventory subdomain senders before stage 4, or set sp explicitly |
Rollback
If legitimate mail starts failing after a policy change, move the DMARC policy back one stage (reject to quarantine, or quarantine to none) and wait for the TTL to expire. Do not delete the DMARC record: you lose the reports you need to find the cause. Fix the failing source, confirm alignment in the next reports, and then move forward again.
Check your current status
The XOOPIE Email Health Inspector checks a domain’s published SPF, DKIM and DMARC records. For a managed rollout across Microsoft 365, Google Workspace and third-party senders, see Email & Collaboration services.
Sources
Primary sources used for this article (checked 11 October 2026):
- RFC 7208: Sender Policy Framework (SPF)
- RFC 6376: DomainKeys Identified Mail (DKIM) Signatures
- RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC)
- RFC 8058: Signaling One-Click Functionality for List Email Headers
- Google: Email sender guidelines
- Google: Email sender guidelines FAQ (enforcement timeline)
- Google Workspace Admin Help: Set up DKIM
- Microsoft: Outlook’s new requirements for high-volume senders
- Microsoft Learn: Set up DKIM to sign mail from your Microsoft 365 domain