People • Technology • Possibilities+91 74199 74199[email protected]
Home / Insights / Email Authentication
Email Security & Deliverability

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.

Email authentication with SPF, DKIM and DMARC
Email Authentication

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

StandardWhat it checksCommon failure
SPF (RFC 7208)Whether the sending IP is authorised for the envelope sender (MAIL FROM) domainMore 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 bodyMailing 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 addressSenders 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.

StageDMARC policyExample durationExit criteria
1. Monitorp=none with rua reporting2–4 weeksEvery legitimate source in the aggregate reports is identified and has an owner
2. Fixp=none2–6 weeksEach legitimate source passes SPF or DKIM with alignment; DKIM is preferred because it survives forwarding
3. Quarantinep=quarantine, optionally ramped with pct2–4 weeksNo legitimate source appears in the failing traffic; help-desk reports of missing mail are resolved
4. Rejectp=rejectOngoingReports 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

SymptomLikely causeFix
SPF permerror in reportsToo many include mechanisms; more than 10 DNS lookupsRemove unused includes, move senders to subdomains, or rely on aligned DKIM for third parties
Forwarded mail fails SPFThe forwarder’s IP is not in your SPF recordExpected behaviour; make sure DKIM signs everything so DMARC can still pass
Mailing-list posts fail DKIMThe list adds a footer or tags the subjectReceivers may use ARC from the list; agree with list owners to avoid modifying messages where possible
A SaaS platform fails DMARCIt signs with its own domain and uses its own bounce domainConfigure custom DKIM (and a custom return-path if offered) for your domain in that platform
Subdomain mail is rejected unexpectedlySubdomains inherit p when sp is not setInventory 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):

Frequently Asked Questions

About the Author

Lalit Bhardwaj — Founder & Technology Strategist, XOOPIE. Lalit leads XOOPIE with a hands-on technology strategy and infrastructure engineering approach. With over 15 years of industry experience, his focus is on understanding how an organization actually operates and translating that reality into an appropriate, resilient technical design.

Read Lalit Bhardwaj's full profile →