When transactional email goes to spam, the instinct is to blame the recipient's mail provider, and the cause is almost always configuration on the sending side. Password resets, receipts and verification codes are the messages a product cannot afford to lose, and their deliverability is mostly an identity question: can the receiving system establish that this message genuinely came from you, and that mail from you is normally wanted.
Three DNS records carry most of the weight. SPF states which servers may send on behalf of your domain. DKIM attaches a signature proving the message was authorised by the domain owner and not altered in transit. DMARC ties those together, tells receivers what to do when a message fails, and - the part teams skip - produces reports showing who is sending as you. Publishing a DMARC record and never reading its reports forfeits most of its value.
Separate your sending streams. Transactional and marketing mail should not share a domain or a sending reputation, because the consequences of a campaign nobody wanted should not land on your password reset messages. A subdomain for each, with its own authentication and its own reputation, keeps a marketing mistake from taking out account recovery. This is the single structural decision that most affects deliverability later on.
Reputation is built from recipient behaviour and accumulates slowly. A new domain or address that suddenly emits a large volume looks exactly like a compromised one, so volume should ramp up rather than begin at full rate. What earns a good reputation is people opening, replying and not marking as spam; what destroys it is sending to addresses that bounce or never existed, which is why purchased or stale lists damage the transactional stream sharing their identity.
Content matters less than most guides suggest, with specific exceptions. Messages that are a single image with no text, that hide link destinations behind redirects on unfamiliar domains, or that rely on link shorteners, all resemble the patterns filters are trained on. Plain, clear text linking to your own domain, with a genuine plain-text alternative alongside the HTML, avoids nearly all of it. Chasing lists of forbidden words is superstition; the structural signals are what count.
Instrument the pipeline or you will hear about failures from customers. Bounces, complaints and delivery failures come back from providers and need to be recorded and acted on - a hard bounce means stop sending to that address permanently, and continuing to try is precisely what damages reputation. Alert on delivery rate falling and complaint rate rising, because both move before the problem becomes visible in support tickets.
The unglamorous conclusion is that this is configuration and hygiene rather than engineering, which is why it is usually done once at launch and never revisited. Records drift when infrastructure changes, a new tool begins sending on the company's behalf without authentication, and the reset emails quietly stop arriving. A quarterly check of authentication records and DMARC reports is a small standing cost against a failure that is hard to detect and awkward to explain.
