You deployed your SaaS. Wired up SendGrid. Sent your first welcome email.
It landed in spam.
Not because your content was bad. Not because your list was dirty. Because your DNS isn't configured correctly, and inbox providers don't yet trust your domain.
Here's what SPF, DKIM, and DMARC actually do, why they fail, and how to fix them.
The problem: inbox providers don't know who you are
When your server sends an email, the receiving server (Gmail, Outlook, Yahoo, etc.) has no reliable way to verify that you actually own the domain you're sending from—unless you've published authentication records in your DNS.
Those records are:
- SPF
- DKIM
- DMARC
Miss any one of them and your emails become harder to trust. At best, they'll have lower deliverability. At worst, they'll be treated as spoofed mail.
SPF — Sender Policy Framework
SPF answers one question:
"Which servers are allowed to send email for this domain?"
You publish a TXT record on your root domain listing the services authorized to send mail on your behalf.
v=spf1 include:sendgrid.net include:amazonses.com ~all
When Gmail receives an email from hello@yourdomain.com, it looks up your SPF record and checks whether the sending IP is authorized.
~all vs -all
-
~all→ SoftFail — unauthorized senders are accepted but marked as suspicious. -
-all→ HardFail — unauthorized senders fail SPF completely.
Start with ~all. Move to -all only after you've verified every legitimate sender is included.
Common SPF mistake
Too many include: statements.
SPF has a hard limit of 10 DNS lookups. Each include: directive counts toward that limit.
If you exceed it, SPF returns a PermError, even if the sending IP is otherwise valid.
Check your SPF record:
dig TXT yourdomain.com | grep spf
DKIM — DomainKeys Identified Mail
SPF verifies the sending server.
DKIM verifies that the signed portions of the email haven't been modified after they were sent.
Your email provider signs every outgoing message with a private key. The receiving server retrieves the corresponding public key from your DNS and validates the signature.
Example:
mail._domainkey.yourdomain.com IN TXT
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ..."
The record lives at:
{selector}._domainkey.{yourdomain}
The selector (mail in this example) is chosen by your email provider.
What can break DKIM?
- Some email forwarding services that modify headers
- Email gateways that alter message content
- Incorrectly formatted DNS records
- Public keys split incorrectly across multiple DNS strings
Rotate your DKIM keys
Rotate DKIM keys every 6–12 months.
A typical rotation process looks like this:
- Generate a new key pair.
- Publish the new selector.
- Update your email provider.
- Remove the old selector after propagation (usually 48 hours).
DMARC — The policy layer
SPF and DKIM work independently.
DMARC ties them together and tells receiving servers what to do when authentication fails.
Example:
_dmarc.yourdomain.com IN TXT
"v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com; pct=100"
DMARC policies
| Policy | Behavior |
|---|---|
none |
Monitor only. No enforcement. |
quarantine |
Failed messages are sent to spam. |
reject |
Failed messages are rejected outright. |
Start with p=none.
Review your aggregate reports (rua=), verify every sending source passes authentication, then gradually move to quarantine and eventually reject.
DMARC alignment—the part most developers miss
Imagine you're sending from:
hello@yourdomain.com
But your email provider uses:
bounce@sendgrid.net
SPF passes for sendgrid.net, but it doesn't align with your visible From domain.
As a result, DMARC can still fail.
The fix is to configure a custom return-path (bounce) domain such as:
bounce.yourdomain.com
This keeps SPF aligned with your own domain.
The warm-up problem
Even with perfect SPF, DKIM, and DMARC, a brand-new sending domain has no reputation.
Inbox providers evaluate much more than authentication:
- Historical engagement
- Spam complaints
- Bounce rates
- Sending consistency
- Domain reputation
Sending hundreds of emails from a brand-new domain looks suspicious, regardless of how well your DNS is configured.
The solution is gradual warm-up.
| Week | Daily Volume |
|---|---|
| Week 1 | 20–50 |
| Week 2 | 50–200 |
| Week 3 | 200–500 |
| Week 4+ | Scale gradually |
For low-volume transactional email, warm-up is generally less critical. For newsletters and cold outreach, it's essential.
MailPilot automates this with AI-driven warm-up across real peer inboxes, DNS health monitoring, and inbox placement tracking.
Quick checklist before your next send
- ✅ SPF record exists
- ✅ SPF uses fewer than 10 DNS lookups
- ✅ DKIM selector is published
- ✅ DMARC record exists at
_dmarc.yourdomain.com - ✅ DMARC policy is at least
p=none - ✅ Aggregate reporting (
rua=) is configured - ✅ Custom bounce domain is configured for SPF alignment
- ✅ Domain has aged for at least 2–4 weeks before high-volume sending
- ✅ Warm-up is running before scaling outbound email
Validate your setup
SPF
dig TXT yourdomain.com | grep spf
DKIM
dig TXT mail._domainkey.yourdomain.com
Replace mail with your DKIM selector.
DMARC
dig TXT _dmarc.yourdomain.com
Or use the free tools at mailpilots.in/free-tools to generate and validate your SPF, DKIM, and DMARC records in one place.
TL;DR
- SPF defines which servers can send email for your domain.
- DKIM proves your email hasn't been modified after it was sent.
- DMARC tells receiving servers how to handle authentication failures.
- For DMARC to pass, either SPF or DKIM must align with your visible From domain.
- Authentication improves trust, but reputation still has to be earned through consistent, gradual sending.
Fix your DNS. Build your sender reputation. Keep your emails out of spam.
Top comments (0)