Most “emails aren’t arriving” bugs aren’t bugs in your code. They’re missing DNS records or a new sending domain that mailbox providers don’t trust yet. Fix the DNS first — it’s the highest-leverage 20 minutes you’ll spend on email.

The three DNS records

SPF lists which servers are allowed to send mail as your domain. Without it, receiving servers can’t verify your mail actually came from where it claims to.

example.com. TXT "v=spf1 include:_spf.mx.cloudflare.net include:sendgrid.net ~all"

One include: per sending service you use. ~all soft-fails anything not listed (flag as suspicious); -all hard-fails it (reject outright) — use -all once you’re confident every legitimate sender is covered, since a missed include with -all silently drops real mail.

DKIM signs each email with a private key so the receiving server can verify it wasn’t altered in transit and genuinely came from a server you authorized. Your email provider (SES, Postmark, whoever) gives you a public key to publish as a DNS record — you don’t generate this yourself:

selector._domainkey.example.com. TXT "v=DKIM1; k=rsa; p=MIGfMA0GCS..."

DMARC tells receiving servers what to do when SPF or DKIM fail, and gives you a place to receive reports about spoofing attempts against your domain.

_dmarc.example.com. TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com"

Start with p=none (monitor only, don’t affect delivery) while you confirm SPF and DKIM are both passing for all your real mail, then move to p=quarantine and eventually p=reject once you’re confident nothing legitimate is failing.

Warming a new domain

A brand-new sending domain has no reputation with Gmail, Outlook, or any other mailbox provider — and no reputation looks the same as bad reputation to a spam filter. Send a large volume on day one and a meaningful chunk lands in spam, not because anything is misconfigured, but because the domain hasn’t earned trust yet.

Ramp gradually instead: start with a few dozen to a few hundred emails a day to your most-engaged users (people who open and reply), and increase volume over 2-4 weeks as your sending reputation builds. Most transactional providers have specific warm-up guidance for their own IP pools — follow it rather than guessing at a schedule.

What actually breaks, and what you’d see

Symptom	Likely cause
Email never arrives, no bounce	Silently filtered as spam — check SPF/DKIM/DMARC alignment
Bounce: 550 5.7.1	SPF or DKIM failure, or blocklisted sending IP
Arrives, but in spam	New domain reputation, or spammy content patterns (excessive links, ALL CAPS subject)
Arrives fine to Gmail, not Outlook	Provider-specific reputation — check each provider’s postmaster tools separately

Monitor, don’t just configure and forget

Google Postmaster Tools and Microsoft SNDS give you direct visibility into how Gmail and Outlook see your domain’s reputation, spam rate, and delivery errors — set both up even if things look fine today, because reputation can degrade after a list import or a spike in bounces, and you want to catch that before support tickets do.

Track your bounce rate and spam complaint rate per campaign or per transactional type. A bounce rate climbing past 2-3%, or a complaint rate above 0.1%, is a real signal that something’s wrong with either your list hygiene or your content — and mailbox providers act on those numbers faster than you’ll notice the symptom yourself.

The fix for “our emails aren’t arriving” is almost never more code. It’s checking these three DNS records, then checking postmaster tools for the provider your users are actually on.

---