You deployed your app. Transactional emails are set up. Users sign up and trigger a welcome email, but it lands in spam or, worse, never arrives.
This isn't a code issue. It's a DNS configuration problem, and it's more common than you think.
This guide covers the three records every developer needs to understand: SPF, DKIM, and DMARC. We'll explain what they are, why they matter, and how to fix them.
THE PROBLEM: ANYONE CAN FAKE YOUR DOMAIN
Email was designed in the 1980s without any authentication. By default, anyone can send an email claiming to be from noreply@yourapp.com. There's no verification or signature.
This is why spam filters exist, and why they are so aggressive. If your domain appears untrustworthy due to missing records or misconfigured DNS, Gmail and Outlook will quietly hide your emails.
SPF, DKIM, and DMARC are the three DNS records that confirm you are actually sending from your domain.
- SPF - "These servers are allowed to send for me"
SPF (Sender Policy Framework) is a TXT record on your domain that lists which mail servers are allowed to send emails on your behalf.
When Gmail receives an email from noreply@yourapp.com, it checks your DNS for an SPF record and asks: "Is this server on the allowed list?"
A typical SPF record looks like this:
v=spf1 include:sendgrid.net include:_spf.google.com ~all
Breaking this down:
v=spf1 is always the version identifier.
include:sendgrid.net means SendGrid's servers are allowed.
include:_spf.google.com means Google Workspace servers are allowed.
~all means anything else is a soft fail — it's suspicious, but not fully rejected.
The choice between ~all and -all is important. Use ~all while you're setting up. Switch to -all once you're sure every sending service is listed. Never use +all — it allows everyone.
A common mistake is hitting the 10-lookup limit. SPF has a hard limit of 10 DNS lookups. Each include: counts as one. If you use SendGrid, Mailchimp, Google Workspace, and Salesforce, you'll reach that limit quickly. If you go over, SPF fails even for legitimate emails. Check your lookup count before you deploy.
- DKIM - "This email was signed by us"
DKIM (DomainKeys Identified Mail) adds a cryptographic signature to every outgoing email. The receiving server checks this signature against a public key you publish in DNS.
Think of it as a wax seal. Anyone can see the letter, but only you have the stamp.
You publish a TXT record at a selector subdomain:
selector1._domainkey.yourapp.com TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSI..."
The actual signing happens in your email provider — SendGrid, Postmark, AWS SES, etc. They generate the key pair and give you the public key to add to DNS. You don't create this manually.
How to set it up:
- Go to your email provider's dashboard (in SendGrid, it's Settings > Sender Authentication).
- They'll give you 2-3 DNS records to add.
- Add them to your DNS provider (Cloudflare, Route53, etc.).
- Click Verify in the provider dashboard.
That's it. DKIM setup mostly involves copy-pasting — the complexity is handled by your provider.
One thing to note: some providers (SendGrid, Mailchimp) use CNAME records for DKIM instead of TXT. Both methods work. Just follow your provider's instructions.
- DMARC - "Here's what to do if SPF/DKIM fails"
DMARC (Domain-based Message Authentication, Reporting & Conformance) connects SPF and DKIM and tells receiving servers what to do when authentication fails. It also sends you daily reports — summaries of who is sending email from your domain and whether it passed or failed.
The record goes at _dmarc.yourapp.com:
_dmarc.yourapp.com TXT "v=DMARC1; p=none; rua=mailto:dmarc@yourapp.com"
The key field is p= (policy):
p=none — do nothing, just report.
p=quarantine — send failures to spam.
p=reject — block failing emails entirely.
The right rollout order:
Week 1-2: p=none. Just collect reports and don't block anything.
Week 3-4: Review reports and fix any legitimate sources you missed.
Month 2: p=quarantine. Failing emails go to spam.
Month 3+: p=reject. Once you're confident, implement hard rejection.
Don't start with p=reject. You risk blocking legitimate emails you didn't know about.
The reports arrive as XML attachments. They aren't user-friendly. Use a tool to parse them (more on that below). Don't skip this step — reports help you discover misconfigured services or someone spoofing your domain.
BONUS: TWO MORE RECORDS WORTH KNOWING
MTA-STS forces other mail servers to use TLS when connecting to yours. Without it, email in transit can be downgraded to unencrypted. It requires a TXT record plus a hosted policy file. It's a bit more setup, but worth it for transport security.
BIMI allows your logo to appear in Gmail's inbox next to your email. It requires p=quarantine or p=reject DMARC plus a verified mark certificate. It's mostly relevant for marketing emails, but it's a nice trust signal once everything else is in order.
THE FIX CHECKLIST
If your emails are going to spam, check the following:
- SPF record exists — dig TXT yourdomain.com | grep spf
- SPF includes all your sending services — SendGrid, Mailchimp, Google, etc.
- SPF lookup count is 10 or under — use an SPF checker
- DKIM is configured in your email provider and DNS records are verified
- DMARC record exists — dig TXT _dmarc.yourdomain.com
- DMARC rua= is set to receive reports
- No duplicate SPF records — you can only have one SPF TXT record per domain
TOOLS I ACTUALLY USE
ZeroHook (zerohook.org) — Full DNS and email security audit in one place. There's a free tier available. It's worth checking if you have compliance requirements in the future.
MXToolbox (mxtoolbox.com) — SPF/DKIM/DMARC lookup, blacklist check. Good for a quick check.
mail-tester.com — Send a test email to get a deliverability score and see specific issues.
Postmark DMARC Digests (dmarc.postmarkapp.com) — Free DMARC report parser with a clean interface.
DMARC Analyzer (dmarcanalyzer.com) — More detailed, paid plans for ongoing monitoring.
Quick CLI checks without leaving the terminal:
dig TXT yourdomain.com (SPF)
dig TXT _dmarc.yourdomain.com (DMARC)
dig TXT selector1._domainkey.yourapp.com (DKIM)
TL;DR
Email authentication involves three DNS records that took the internet 20 years to adopt correctly. They aren't glamorous, but getting them right ensures your emails reach people.
SPF — whitelist your sending servers.
DKIM — cryptographically sign your emails.
DMARC — set a policy and get reports.
Start with p=none, read the reports for a few weeks, then tighten the policy. Don't skip the reports — they provide the actual signal.
If you found this helpful or have questions, leave a comment. I'm happy to discuss specific provider setups (AWS SES, SendGrid, Postmark) if you're interested.
Top comments (0)