Your message was perfectly worded, the link was legitimate, and the recipient opted in — and yet it landed in spam. Most "delivery" problems aren't about content. They're about authentication and reputation, and they're surprisingly fixable once you know what receivers are checking for.
The three authentication standards every domain needs
Modern receivers run three checks on every incoming message. None of them care about what's in the body. They care about whether the sending domain is who it claims to be.
SPF — who's allowed to send for you
SPF is a TXT record at your domain that lists which IP addresses and providers are authorized to send mail on your behalf. A typical record looks like:
v=spf1 include:_spf.google.com include:mailgun.org ~allReceivers compare the IP that connected to them against this list. The trailing ~all means "soft fail" anything not listed; -all means "hard fail" (reject). One subtle gotcha: SPF allows a maximum of 10 DNS lookups during evaluation, including nested include: chains. Exceed that and the whole policy returns PermError, which most receivers treat as a fail.
DKIM — a signature on every message
DKIM signs each outbound message with a private key. The corresponding public key lives at selector._domainkey.example.com as a TXT record. Receivers fetch the public key, verify the signature, and confirm the message wasn't tampered with after your server signed it. Unlike SPF, DKIM survives forwarding — the signature still verifies.
DMARC — the policy that ties them together
DMARC, published as a TXT record at _dmarc.example.com, tells receivers what to do when SPF and DKIM fail to align with your visible From: address. A minimal record:
v=DMARC1; p=none; rua=mailto:[email protected]The policy options are:
p=none— report failures, take no action. Use this for the first month while you fix anything legitimate that's failing.p=quarantine— failures go to spam.p=reject— failures are bounced before reaching the inbox.
The rua address receives daily aggregate XML reports from major receivers. Read them. They're the only way to know which IPs are sending under your name.
IP reputation: the silent killer
Even with perfect SPF/DKIM/DMARC, you still need a clean sending IP. Mail servers consult dozens of public blacklists (RBLs). One listing on a major list — Spamhaus SBL or XBL, Barracuda, SORBS — can tank deliverability instantly. Causes range from a compromised account on your platform to inheriting a "hot" IP from the previous tenant on a shared host.
Use IP Blacklist Check on every IP in your sending infrastructure (primary, backup, transactional platform, marketing platform). For a freshly issued IP, also check the previous reverse DNS — if it was something like spammer-server.example, the IP carries baggage even though you're new to it.
Reverse DNS and FCrDNS
Most major mailbox providers reject mail from IPs without a PTR record. Worse, they want forward-confirmed reverse DNS: the PTR points at a hostname, that hostname's A/AAAA points back at the IP, and the loop closes. Reverse DNS verifies this for you. If you're sending from a cloud instance, leaving the default PTR (ec2-x-x-x-x.compute.amazonaws.com) is a red flag — configure your own.
A practical debugging checklist
- Send a test message to a Gmail address. Open headers. Look for "spf=pass", "dkim=pass", "dmarc=pass". Anything else, fix that first.
- Run MX Record Lookup: confirm SPF exists, has exactly one record, and ends in
~allor-all. - Run IP Blacklist Check on every sending IP.
- Run Reverse DNS on every sending IP. Both v4 and v6 if you send over both.
- Check DMARC reports. Real abusers will appear here within a week of publishing the record.
- Warm up new IPs gradually — receivers throttle high-volume traffic from unknown senders even with clean auth.
What's not the problem (usually)
Subject lines with "free" don't get you spammed. Unsubscribe links in the right format don't get you spammed. Plain HTML doesn't get you spammed. Not authenticating gets you spammed. Fix the authentication first; the content tweaks come later.