Transactional email - password resets, verification links, receipts, notifications - is treated as solved because sending is easy. Arriving is the hard part, and the failure is invisible from your side: your logs say sent, the provider says delivered, and the user says they never got it. By the time it is understood as a systemic problem rather than isolated complaints, a meaningful share of signups have already been lost.
Almost all of it comes down to authentication, and there are three records that must exist in your DNS. SPF lists which servers may send for your domain. DKIM cryptographically signs each message so the receiver can verify it was not altered and did come from you. DMARC tells receivers what to do when the first two fail, and gives you reports on who is sending as your domain. Without all three properly configured, major providers will treat your mail with suspicion regardless of its content.
DMARC deserves particular attention because most implementations stop halfway. A policy of none monitors and enforces nothing, which is the correct place to start - but many organisations set it and never move on, because moving to quarantine or reject requires first identifying every legitimate sender using the domain. That list is usually longer than expected: your product, your CRM, your invoicing tool, your recruitment platform, someone's newsletter service. Enforce before you have found them all and legitimate mail stops arriving.
Separate your domains by traffic type. Transactional email should not share a sending domain or a reputation with marketing campaigns, because a bulk campaign generating spam complaints will damage the reputation that your password resets depend on. A subdomain for each, with independent reputation, means a marketing mistake cannot stop people logging in.
The content rules are simpler than folklore suggests but not nothing. Include a plain-text alternative alongside the HTML. Keep the ratio of images to text sane. Use a real reply-to address rather than a no-reply that bounces, since engagement is a positive signal and refusing replies is a negative one. Avoid link shorteners, which are heavily associated with abuse. And send from a real subdomain of your own domain rather than an address at your email provider.
Finally, instrument what happens after sending, because your application's send log is not evidence of anything. Track bounces and complaints per provider - Gmail, Outlook and Yahoo behave differently and a problem usually appears at one first. Process bounces properly: continuing to send to a hard-bounced address is one of the strongest negative signals available, and a list that accumulates dead addresses degrades the deliverability of everything else you send.
