Deliverability 101 — why your transactional email is in spam

Deliverability is the strange middle ground between marketing, security, and infrastructure. If you have ever sent a critical password reset and watched it land in spam, you have run into it.

The three pillars

SPF, DKIM, and DMARC together tell receiving servers that you are who you claim to be. Setting them up is necessary, but not sufficient.

SPF

A TXT record on your domain that lists who is allowed to send mail on your behalf. It is the easy one. Get it right and forget it.

DKIM

A cryptographic signature on every outgoing message, validated against a public key in DNS. SNDR generates a fresh RSA-2048 keypair the moment you add a domain — you publish the public half, we sign with the private half.

DMARC

The policy that ties them together. Start with p=none and watch the reports for a week before tightening to p=quarantine. The default policy SNDR recommends is p=quarantine — strict enough to deter spoofing, lenient enough that mistakes do not vanish into the void.

A good DMARC policy is the difference between an inbox and the trash folder.

Reputation matters more than you think

Even with perfect auth, your IPs and your sending domain accumulate a reputation. Send a single bad batch and you can spend weeks digging out.

SNDR runs a multi-MTA pool with sticky-by-recipient routing — Gmail consistently sees you from the same IP, Outlook from another, Yahoo from a third. The reputations build up in parallel, and a single damaged IP does not take down the whole show.

The unsexy details

A long-form story for another post: PTR records that match your HELO. List-Unsubscribe with one-click POST. Plaintext alternatives for HTML emails. Message-IDs that do not look randomly generated. We get all of this right by default — but you should still understand them, because the day they go wrong you want to know what changed.