SPF, DKIM, DMARC: The Minimum Deliverability Setup for Transactional Email

Most “deliverability problems” aren't mysterious. They're boring DNS, confused sender identity, or a provider/domain mismatch.

This is a minimum viable checklist to get transactional email (password resets, magic links, invoices) landing in the inbox — without turning deliverability into a full-time job.

If you can only do 3 things today: SPF, DKIM, and a basic DMARC policy.

What you're trying to prove

Inbox providers (Gmail, Outlook, Yahoo) want to know two things:

Authentication: is this email really allowed to send “as” this domain?
Reputation: does this sender behave like a real business over time?

Authentication is table-stakes. Reputation is earned — but you can avoid lighting it on fire during setup.

Baseline: pick one “From” domain and stick to it

Decide what domain you're sending from and keep it consistent across your product.

Use a domain you control (not Gmail, not a random alias)
Keep From stable (name + address)
Prefer a dedicated subdomain for mail, e.g. notifications.yourdomain.com

Don't send transactional email from your marketing domain if you can avoid it. If marketing gets noisy and your reputation dips, your password resets pay the price.

The checklist

SPF: authorize your sending provider
DKIM: sign outgoing mail with your domain
DMARC: tell inboxes what to do when auth fails
Alignment + From: make sure what you see matches what gets authenticated
Operational sanity: bounces, complaint handling, and “don't look like a spammer” basics

1) SPF: authorize your sending provider

SPF is a DNS TXT record that says which servers are allowed to send mail for your domain.

Rules you should tattoo on your forehead

You only get one SPF record per domain (multiple TXT records will break things)
Keep it short (SPF has DNS lookup limits)
Start with ~all (soft fail) while you migrate, then tighten later

DNS (example SPF)

# Example only — use your provider's SPF include
notifications.yourdomain.com  TXT  "v=spf1 include:spf.resend.com ~all"

If you already send from multiple systems (support tool, billing tool, product), consolidate through one provider when possible. Every extra “include” makes SPF more fragile.

2) DKIM: sign email so it can't be spoofed

DKIM adds a cryptographic signature to each message. Inbox providers can verify the signature using a public key you publish in DNS.

Your provider (Resend, SES, Postmark, etc.) will give you a record that looks like this:

DNS (example DKIM)

# Example — your selector and value will differ
s1._domainkey.notifications.yourdomain.com  TXT  "v=DKIM1; k=rsa; p=MIIBI..."

DKIM is usually the biggest “flip” from spam to inbox
Use the provider's recommended selector strategy (often multiple selectors for rotation)

3) DMARC: your policy + reporting

DMARC tells inbox providers what to do when SPF/DKIM checks fail, and where to send reports.

Start with monitoring mode:

DNS (starter DMARC)

_dmarc.notifications.yourdomain.com  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; ruf=mailto:dmarc@yourdomain.com; fo=1"

DMARC reports can get noisy. Use a dedicated mailbox or a DMARC analysis tool later — but don't skip DMARC entirely.

When to tighten DMARC

Once you've confirmed all legitimate sources are authenticating properly, move to:

p=quarantine (send failures to spam)
Then eventually p=reject (block failures)

4) Alignment: why “From” matters

DMARC cares about alignment: the domain in the visibleFrom header should align with the domain used for SPF and/or DKIM.

If you send from hello@yourdomain.com but DKIM signs as provider-mail.com, DMARC may fail
If you use a subdomain for mail, keep it consistent end-to-end

The #1 rookie mistake: verifying a domain in your email provider but still sending from a different “From” domain in your app.

5) Operational sanity checks (the stuff that saves you)

Avoid “spammy” patterns in transactional email

Don't include unnecessary tracking links in password resets
Don't blast lots of content + images in security emails
Keep subject lines literal: “Reset your password” beats “Important account update!!!”

Handle bounces and complaints

Transactional doesn't mean “ignore list hygiene.” If an address hard bounces, stop sending to it.

Store a delivery_status per recipient
On hard bounce / spam complaint: suppress future sends

Send a small volume first

If your domain is new, don't go from 0 to 50k emails/day overnight. Ramp up. Reputation is a thermostat, not a light switch.

Quick test: verify auth on a real message

Send yourself an email (Gmail + Outlook if possible), then check “original message” headers. You want to see:

SPF: pass
DKIM: pass
DMARC: pass

If SPF passes but DKIM fails, you're usually missing DKIM DNS records. If DKIM passes but DMARC fails, you're usually misaligned (wrong From domain).

Copy/paste “good enough” deliverability checklist

Dedicated sending domain or subdomain
SPF record published (single record; not duplicated)
DKIM enabled and passing
DMARC enabled (start at p=none)
From domain aligns with SPF/DKIM
Hard bounces suppressed
Security emails are plain and boring (that's a compliment)

Do those, and you're ahead of most teams shipping transactional email.