Email Authentication: SPF/DKIM/DMARC Deployment and Incremental p=reject Transition
SPF, DKIM, and DMARC deployment from scratch; incremental p=none → quarantine → reject transition; third-party sender authorization and periodic maintenance process.
p=none, analyze RUA reports, then move to p=quarantine and finally p=reject. For DMARC alignment, verify that SPF and DKIM are consistent with the From header; SPF/DKIM that passes alone without alignment does not protect the domain. Failing to define a separate policy for subdomains (the sp= tag) can leave a gap for spoofed email submission.Prepare
6 steps- Extract sender inventory
List all email sending sources: primary MTA (M365, Google Workspace, Exchange on-premise), CRM (Salesforce, HubSpot), marketing (Mailchimp, Marketo), support (Zendesk, ServiceNow), monitoring/notification, backup, and development environments; document the source IP/CIDR, SPF `include:` name, and DKIM selector for each sender
- DNS access and TTL planning
Obtain access to the DNS zones where SPF/DKIM/DMARC records will be published; note the current TTL before making changes and lower it to 300–600 seconds; prepare a rollback plan for each step
- Set up reporting infrastructure
Create `dmarc-rua@example.com` and `dmarc-ruf@example.com` mailboxes; configure parsedmarc, dmarcian, or an equivalent DMARC report processing tool and test SIEM integration
- Define authorization
Pre-define and test required permissions for DNS changes, SMTP gateway blocklist management, and email quarantine/purge (Exchange Compliance Search, M365 Search & Purge, Google Vault)
- Third-party sender onboarding procedure
Prepare a written procedure for obtaining an SPF mechanism and DKIM selector when a new SaaS platform is added; document the rule for keeping the SPF lookup count below 8 (RFC 7208 §4.6.4: limit is 10; keep at 8 for a safe margin)