Email Deliverability Guide for Indie SaaS Founders
Three DNS records control whether your product emails land in the inbox or get silently dropped: SPF, DKIM, and DMARC. Add all three correctly and your transactional mail is authenticated. Skip any one of them and you're relying on your ESP's reputation instead of your own domain, which means no protection from spoofing and no visibility into what receivers are doing with your mail.
This is the reference for getting them right.
The three pillars
SPF (Sender Policy Framework)
- What it does: Lists which IPs are allowed to send for your domain
- Where it lives: DNS TXT record at your root domain
- When it fails: Receiving server can't confirm the sending IP is authorized
- Alignment: SPF aligns when the
Return-Pathdomain matches yourFrom:domain
DKIM (DomainKeys Identified Mail)
- What it does: Cryptographically signs outgoing mail
- Where it lives: DNS TXT record at a selector subdomain (e.g.,
key1._domainkey.yourdomain.com) - When it fails: The signature doesn't verify; mail was modified or the key is wrong
- Alignment: DKIM aligns when the signing domain (
d=) matches yourFrom:domain
- What it does: Defines what happens when SPF or DKIM fails, and where to send reports
- Where it lives: DNS TXT record at
_dmarc.yourdomain.com - When it fails: Depends on your policy:
p=nonedelivers anyway;p=rejectbounces the message - Passes when: Either SPF or DKIM aligns
DMARC is the enforcement layer. SPF and DKIM provide authentication signals. DMARC uses those signals to decide what to do and tells you what's happening via aggregate reports.
Setting up SPF
An SPF record tells receivers: "these are the mail servers allowed to send email for my domain."
Minimal record:
v=spf1 include:your-esp.com ~all
Each ESP has an include: mechanism to add. Google Workspace uses include:_spf.google.com. Resend uses include:_spf.resend.com. Check your ESP's documentation for the exact value.
The 10-lookup limit: SPF allows at most 10 DNS lookups when evaluating your record. Every include: potentially chains into more lookups. If you have multiple ESPs, check your lookup count with the SPF checker; exceeding 10 causes a PermError that breaks alignment. See the SPF flattening guide if you're over the limit.
The ~all vs -all question: ~all (softfail) means unauthorized senders get a soft fail; receivers decide what to do with it. -all (hardfail) explicitly rejects unauthorized senders. For domains with DMARC at p=reject, the all mechanism is less important because DMARC handles enforcement. Start with ~all.
Setting up DKIM
DKIM signs outgoing mail with a private key held by your sending service. Receivers verify the signature using a public key published in your DNS.
Your ESP handles the signing; they hold the private key. You need to add the public key to your DNS as a TXT record. Every ESP has a DNS setup guide that tells you exactly what record to add and where.
The record lives at a selector subdomain:
key1._domainkey.yourdomain.com TXT "v=DKIM1; k=rsa; p=YOUR_PUBLIC_KEY"
The selector (key1 in this example) is chosen by your ESP. You may need to add multiple DKIM records if you use multiple ESPs, each with its own selector.
What to watch for: Some ESPs rotate their signing keys. When they do, the old key stops working and your DKIM alignment fails until you update your DNS. If you see DKIM failures on a sender that was previously passing, check whether the ESP changed their key and has new DNS instructions.
Setting up DMARC
Add a TXT record at _dmarc.yourdomain.com:
v=DMARC1; p=none; rua=mailto:reports@yourdomain.com
This starts you in monitoring mode. The rua= address is where aggregate reports are sent; without it, you're flying blind. Use an address you'll actually read, or point it at a service that processes the reports for you.
Verification: Use the DMARC checker to confirm your record is published and parseable. It shows every tag decoded into plain language.
The alignment concept
DMARC's enforcement depends on alignment, not just whether SPF or DKIM pass, but whether they pass for the right domain.
SPF alignment: the domain in the Return-Path header must match your From: domain (or be a subdomain of it, in relaxed mode).
DKIM alignment: the signing domain in the DKIM d= tag must match your From: domain.
This matters because without alignment, a spammer could use your domain in the From: header while having their own SPF and DKIM set up for a different domain. Alignment closes that gap.
Forwarded mail and SPF: When someone forwards your email, the Return-Path changes to the forwarder's domain, which breaks SPF alignment. DKIM alignment survives forwarding (assuming the signature wasn't broken in transit). This is why DKIM alignment is more reliable for deliverability; it's the path that survives forwarding.
The path from p=none to p=reject
Getting to enforcement is the goal. The path:
p=none (monitoring): Deploy your DMARC record with p=none and collect reports. Find every sender that's failing alignment and fix it. Watch for unknown senders. Wait until your alignment percentage is consistently above 95%.
p=quarantine (partial enforcement): Failing mail routes to spam. Legitimate senders you haven't fully configured will land in junk, which is how you find out about them before full rejection. Stay here for at least a month with your alignment above 99%.
p=reject (full enforcement): Failing mail is bounced. Your domain is protected from spoofing. This is where you want to end up.
The reporting from each step is what drives this process. Without DMARC reports, or without something processing them for you, you're making the policy decision blind. Use the DMARC analyzer to read individual reports, or let DMARCdrift aggregate them automatically.
Checking your setup
Once you've added all three records, verify with these tools:
- DMARC checker: confirms your policy,
rua=address, and parsed tags - SPF checker: confirms your authorized senders and lookup count
- DMARC analyzer: paste an aggregate report XML to see alignment results per sender
For DKIM, the best verification is checking an actual sent email's headers for DKIM-Signature and Authentication-Results: dkim=pass. Most ESPs also have a test-email flow in their setup guide.
Monitoring after setup
SPF and DKIM aren't set-and-forget. ESPs rotate keys. You add new services. Someone sets up an internal notification tool that sends from your domain. Any of these can break alignment without you knowing.
DMARC aggregate reports are the monitoring layer. They arrive daily from major receivers and show you exactly what's passing and what's failing across all your senders. The question is whether you read them.
Most developers don't; the XML format isn't readable, and weekly manual review doesn't scale. DMARCdrift processes your reports automatically, alerts you when alignment drops or an unknown sender appears, and shows you your alignment trend over time. The goal is the same checklist above, done continuously without the manual work. If you want a condensed, actionable version to run through, the email deliverability checklist is the quick reference to this guide.
FAQ
SPF lists which servers are allowed to send for your domain. DKIM adds a cryptographic signature to outgoing mail so receivers can verify it hasn't been tampered with. DMARC uses the SPF and DKIM results to decide what to do with mail that fails authentication and tells you about it via aggregate reports. You need all three for complete email authentication.
Having a DMARC record (even p=none) is a positive signal for major receivers and is now required by Google and Yahoo for senders above certain volume thresholds. Moving to p=reject protects your domain's reputation by preventing spoofing, which indirectly protects deliverability since your domain isn't associated with phishing campaigns. The main deliverability risk is moving policy too fast before all legitimate senders are aligned.
Check the Authentication-Results header in a test email; send yourself a message and view the full headers. It will show dmarc=pass, dkim=pass, and spf=pass (or the failure equivalent) for that specific message. For ongoing monitoring, DMARC aggregate reports show alignment results across all mail receivers, not just what you see in your own inbox.
First, identify which alignment is failing: SPF, DKIM, or both. If SPF is failing: the sender's IP isn't in your SPF record, so add their include: mechanism. If DKIM is failing: either the sender isn't signing with a key under your domain (check their DNS setup guide), or the DKIM record in your DNS is wrong. If both are failing: that sender has no alignment configured at all; start with their DNS setup documentation. Use the DMARC analyzer to pull the alignment details from your aggregate reports.