Email deliverability only feels random when you cannot prove identity and you cannot observe outcomes. When product emails land in spam or some inbox providers reject them, the root cause is often authentication misconfiguration.
This guide explains SPF, DKIM, and DMARC for engineering teams. You will learn what each record does, how alignment works, and how to roll out DMARC safely without breaking legitimate mail.
It is written for SaaS and dev teams sending transactional messages like password resets, OTPs, and receipts. You will get a step-by-step DNS checklist, the failure modes engineers actually hit in production (SPF lookup limits, DKIM selector mistakes, DMARC policy too strict), and a troubleshooting flow you can use during incidents.
No hype and no guarantees—just the baseline controls that make inbox providers trust your domain more consistently. For implementation and sending setup, keep MailCub Documentation open, and use MailCub Transactional Email for testing real sends and delivery outcomes.
Quick Answer
- SPF authorizes which servers can send for your domain (DNS TXT).
- DKIM cryptographically signs messages (selector-based DNS record).
- DMARC enforces policy and alignment between SPF/DKIM and your visible From domain.
- The goal is DMARC pass with alignment, not just “records exist.”
- Use logs and status signals to confirm real outcomes and shorten debugging time.
Why it matters
For SaaS products, deliverability is not just reputation. It is product reliability for account access and billing flows.
If users do not receive resets or OTPs, they retry. Those retries can create bursts, and bursts can worsen filtering behavior and increase spam placement risk.
SPF, DKIM, and DMARC reduce ambiguity. Monitoring reduces guessing. Together, they make deliverability something you can debug more like any other production system.
What SPF, DKIM, and DMARC actually do
SPF (Sender Policy Framework)
SPF is a DNS TXT record that tells receiving mail servers which IPs or services are allowed to send mail for your domain.
SPF is authorization, not content integrity. It can also break when records become too complex.
DKIM (DomainKeys Identified Mail)
DKIM signs each email with a private key. Receivers verify the signature using a public key stored in DNS under a selector (for example, s1._domainkey).
DKIM proves message integrity and domain association. It is often the most stable signal for DMARC alignment.
DMARC (Policy + alignment)
DMARC tells receivers what to do when SPF or DKIM fails, and it requires alignment with the visible From domain.
DMARC also enables reporting so you can see who is sending on behalf of your domain.
Step-by-step setup
1) Choose a stable From-domain strategy
Pick a consistent From address for product mail, like security@yourdomain.com.
If you want separation, use a subdomain for transactional mail (for example, mail.yourdomain.com). Keep it consistent over time.
2) Publish SPF (keep it minimal)
Create a TXT record such as:
v=spf1 include:provider.example -all
Watch the SPF 10 DNS lookup limit. Chained includes are a common failure mode.
3) Enable DKIM signing and publish selector record
Publish the public key in DNS, for example:
s1._domainkey.yourdomain.com → TXT → v=DKIM1; k=rsa; p=...
Common pitfalls:
- wrong selector name
- record created on the wrong domain or subdomain
- broken formatting or quotes from copy/paste
4) Add DMARC in monitor mode first
Start with:
p=noneto monitor- then move to
quarantine - then
rejectwhen you are confident every legitimate sender aligns
5) Understand alignment (the “why does DMARC fail?” part)
Alignment means the domain that passes SPF or DKIM must match (or align with) the visible From domain.
If SPF passes for a different domain than your From domain, DMARC can still fail. DKIM alignment often avoids this issue.
6) Validate with real test sends (do not rely on DNS alone)
Send tests to multiple mailbox providers and inspect headers for SPF, DKIM, and DMARC results.
If your provider offers delivery logs or message status, use them to correlate outcomes during debugging. You can validate the sending path and logs using MailCub Documentation.
| Control | What it proves | Common failure | Best practice |
|---|---|---|---|
| SPF | Sender authorization | Too many DNS lookups, wrong include | Keep SPF short; avoid chained includes |
| DKIM | Integrity + signed identity | Wrong selector, missing key | Keep selectors consistent; rotate carefully |
| DMARC | Alignment + policy | Misalignment; policy too strict too soon | Start p=none, tighten after validation |
Common mistakes
- SPF breaks due to lookup limits after adding a new include.
- DKIM selector mismatch (record published under the wrong selector or domain).
- DMARC set to reject before every sender is aligned.
- Multiple tools sending from the same From domain with inconsistent authentication.
- Not checking alignment (SPF/DKIM pass but DMARC still fails).
- No monitoring, so support finds issues before engineering does.
Troubleshooting (quick incident flow)
DMARC fails even though SPF/DKIM records exist
Check alignment first: does the passing domain match the visible From domain?
Then check the DKIM d= domain and selector DNS record. Also verify you are not mixing root-domain and subdomain policies accidentally.
SPF fails intermittently
Count DNS lookups from SPF includes. If needed, reduce or flatten includes so you stay within SPF limits.
DKIM fails after changes
Confirm the selector record exists in DNS and has propagated. Check for TXT formatting issues in the value (quotes or whitespace problems are common).
FAQ
What is the difference between SPF, DKIM, and DMARC?
SPF authorizes senders, DKIM signs messages, and DMARC enforces alignment and policy using SPF/DKIM results.
What does DMARC alignment mean?
The domain that passes SPF or DKIM must match (or align with) the visible From domain for DMARC to pass.
Should I start DMARC with p=none?
Yes. Monitor first, then tighten to quarantine or reject after you confirm all legitimate senders align.
Why does SPF fail when the record looks correct?
A common reason is exceeding SPF’s DNS lookup limit because of too many includes or chained records.
How do I know DKIM is signing my emails?
Check message headers for DKIM-Signature and verify it passes at the recipient. Also confirm the selector record exists in DNS.
Do SPF/DKIM/DMARC guarantee inbox placement?
No. They are baseline trust signals. Reputation, content, bounce rates, and sending patterns still affect inbox placement.
Should I use a subdomain for transactional email?
Often yes. It can isolate reputation and make policy management cleaner for transactional flows.
Conclusion
SPF, DKIM, and DMARC are the baseline sender-identity controls for reliable transactional email. Get SPF authorization right, keep DKIM signing stable, and roll out DMARC gradually with alignment in mind.
Once these are in place, deliverability becomes easier to measure and troubleshoot. You can isolate failures, reduce resend spirals, and make changes more safely. Use MailCub Transactional Email with MailCub Documentation to test your authentication baseline and validate real send outcomes.