how to set up DMARC, SPF, and DKIM correctly
A step-by-step skill for setting up email authentication: SPF and DKIM first, then DMARC starting at p=none and tightening to reject, using aggregate reports to find legitimate senders. Use when your domain's emails go to spam, you are setting up a new domain for transactional mail, or you want to stop phishing that spoofs your domain. Triggers: 'DMARC setup step by step', 'SPF DKIM DMARC order', 'p=none to reject'. Not for: email templates, deliverability copy, inbound spam filtering.
TL;DR
Set up SPF and DKIM first, then add DMARC starting at p=none so you get aggregate reports without breaking legitimate mail, and only tighten to quarantine and then reject after the reports show every legit sender is authenticated. The order matters: DMARC before SPF/DKIM is aligned just breaks your own email. Expect the full rollout to take a few weeks of report-watching, and it is worth it: reject policy is what actually stops exact-domain phishing.
how to set up DMARC, SPF, and DKIM correctlyUse this when
- Your domain sends email and you have never set up authentication
- Legit emails land in spam and receivers distrust your domain
- Someone is phishing your customers with spoofed emails from your domain
- A security questionnaire asks for your DMARC policy
Not for
- Writing better email subject lines or templates
- Filtering inbound spam (this is about your outbound identity)
- Setting up the mail server itself
Steps
- Publish an SPF record listing your senders. Create a TXT record at your domain root like v=spf1 include:[your provider] -all, covering every service that sends as your domain (transactional provider, marketing tool, helpdesk). Keep it under 10 DNS lookups; flatten includes if you must.
Expected output: a DNS lookup of your domains TXT records shows a valid SPF record with all your senders.
- Enable DKIM signing with your providers. Generate the DKIM keypair in your email provider, publish the public key as the TXT record they give you (usually at [selector]._domainkey), and turn on signing. DKIM survives forwarding better than SPF, so it is the more reliable of the two.
Expected output: headers of a test email show a valid DKIM signature for your domain.
- Add DMARC at p=none with reporting. Publish a TXT record at _dmarc like v=DMARC1; p=none; rua=mailto:[reports mailbox]; pct=100. Nothing gets blocked yet; you just start receiving daily aggregate reports showing who sends as your domain and whether they pass.
Expected output: within 24-48 hours, aggregate XML reports start arriving at your reports mailbox.
- Read the reports and fix legitimate senders. Use a DMARC report analyzer (or a simple parser) to list every sending service; any legit service failing SPF or DKIM needs its records fixed or its include added. Repeat until failures are only actual spoofing.
Expected output: reports show 100% of your legitimate mail passing SPF or DKIM alignment.
- Tighten to quarantine, then reject. Move p=none to p=quarantine (failing mail goes to spam), watch for a week, then go to p=reject. Each step up is a one-line DNS change with outsized phishing protection.
Expected output: a spoofed test email from an outside server is rejected by receivers, while your real mail still flows.
- Keep monitoring. Leave the rua reporting on permanently and review weekly; new SaaS tools that send as your domain will show up as failures before users complain about missing email.
Expected output: a new marketing tool appears in the reports, you add its SPF/DKIM, and it never breaks.
Variant phrasings
- "DMARC quarantine vs reject"
- "how to check if DMARC is working"
- "SPF record too many DNS lookups fix"
- "set up DKIM for custom domain"
Edge cases and pitfalls
- SPF breaks on forwarded email (the forwarder isnt in your record); DKIM usually survives, which is why DMARC needs only one of the two to align.
- The 10-DNS-lookup SPF limit is easy to blow with multiple includes; count them and flatten aggressively.
- Subdomains need their own consideration: set a DMARC policy for subdomains too (sp=reject) or attackers will spoof [anything].yourdomain.
Provenance
Resolved from the public thread: https://vectle.com/posts/pst_Y8KFYtBQ-XgeQwUlh4nyNA
Maintainer review
No maintainer verification is recorded for this version.
This records the version a maintainer checked. It does not assert that the version is the latest upstream release.