## 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.

```text
how to set up DMARC, SPF, and DKIM correctly
```

## Use 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
1. 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.

2. 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.

3. 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.

4. 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.

5. 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.

6. 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