Back to Blog
EmailDevOpsUX

Why Your Transactional Emails Don't Work

·6 min

Inline CSS, table-based layouts, plain-text fallbacks, and everything else we learned about getting emails into inboxes instead of spam folders.

The Spam Folder Problem

You design a beautiful transactional email. You craft the copy. You test the layout. You send it to a new user. They never see it because Gmail put it in spam.

Email deliverability is a dark art. The rules are opaque, change without notice, and differ between providers. But the fundamentals are well-established, and getting them right is the difference between emails that arrive and emails that disappear.

The Authentication Trifecta

Modern email requires three authentication protocols. Missing any one tanks deliverability.

SPF (Sender Policy Framework) tells receiving servers which IP addresses are authorized to send email for your domain. It's a DNS record that lists allowed senders. If an email claims to be from your domain but originates from an unlisted IP, receivers can reject or flag it.

DKIM (DomainKeys Identified Mail) cryptographically signs each email. The signature is verified against a public key published in your DNS. If the signature doesn't match, the email was tampered with in transit—or wasn't sent by an authorized party.

DMARC (Domain-based Message Authentication) ties SPF and DKIM together and tells receivers what to do with failures. You can instruct them to monitor, quarantine, or reject messages that fail authentication.

Start with DMARC in monitor mode. Review the reports it generates. You'll discover legitimate senders you forgot about and misconfigured services. Once you understand your email ecosystem, tighten the policy.

HTML Email Is Not Web HTML

Email clients strip or ignore most modern CSS. What works on the web fails in email. The constraints are severe.

Tables for layout. Divs and flexbox behave unpredictably across email clients. Tables are ugly but universal.

Inline styles only. External stylesheets and style blocks are stripped by many clients. Every element needs its styles inline.

Web-safe fonts. Custom fonts won't load. Plan for Arial, Georgia, and their fallbacks.

Fixed widths. Responsive units behave inconsistently. Use pixels for predictable rendering.

This feels like 1999 web development because email clients are, effectively, stuck there. Fighting this constraint wastes time; accepting it enables progress.

Plain Text Matters

Always include a plain text alternative alongside HTML. Some users prefer it. Some corporate email systems strip HTML entirely. Spam filters reward multipart messages because spammers often don't bother.

The plain text version should be readable on its own, not an afterthought. Extract the essential information and format it cleanly. Links should be visible as URLs.

Content Traps

Certain content patterns trigger spam filters. The rules aren't public, but patterns emerge from testing.

Excessive caps look like shouting, which looks like spam. Exclamation marks in clusters raise flags. Certain words—"free," "winner," "act now"—are overrepresented in spam and penalized accordingly.

The text-to-image ratio matters. Emails that are mostly images with little text look like spammer tricks to evade content filters. Include substantial text content.

Link density matters. Ten links in a short email look suspicious. Be judicious.

These aren't hard rules; they're heuristics. Testing tools score emails before sending and identify potential issues.

Reputation Is Everything

Email deliverability depends on sender reputation. Reputation accumulates at the domain and IP level. High complaint rates, high bounce rates, and spam trap hits damage reputation. Good engagement—opens, replies, clicks—builds it.

New domains have no reputation, which receivers treat with suspicion. Warm up gradually: start with small volumes to engaged recipients, then scale. A sudden spike from zero to ten thousand emails gets you blacklisted.

Bounce handling protects reputation. Hard bounces (invalid addresses) should immediately stop sending. Repeated soft bounces should eventually be treated as hard. Continuing to send to addresses that bounce tells receivers you don't maintain your list.

Complaint handling matters even more. When someone marks your email as spam, that's a strong negative signal. Immediately suppress that address from future sends. Investigation why complaints happen—confusing unsubscribe flows, unclear sender identity, unexpected content—and fix the root causes.

Testing Before Sending

Several tools help validate emails before they reach real inboxes.

Scoring tools like Mail Tester give you a deliverability score and identify specific issues: missing authentication, content problems, blacklist presence.

Rendering tools show how your email appears across different clients. What looks perfect in Gmail might be broken in Outlook.

DNS validators confirm your authentication records are correct and propagated.

Seed lists let you send to addresses at major providers and check whether emails arrive in inbox or spam.

Testing catches problems before users experience them.

The Checklist

Before launching transactional email:

SPF, DKIM, and DMARC configured and verified. Plain text alternative included. Inline CSS with table-based layout. Working unsubscribe mechanism. Physical address in footer (required by law in many jurisdictions). Bounce and complaint handling implemented. Warm-up plan for new sending domains. Monitoring for deliverability metrics.

Email deliverability isn't glamorous engineering. But it's the difference between your carefully crafted messages reaching users and disappearing into the void. Get the fundamentals right, monitor continuously, and respond quickly when problems emerge.

Questions about this article?

Happy to dive deeper on any of these topics.

Get in Touch