Why Your Emails Land in Spam - A Developer's Guide to SPF, DKIM, and DMARC

Podcastwala — Thu, 02 Jul 2026 17:37:32 +0000

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.

DEV Community: Podcastwala