If your product sends password resets, invoice receipts, or “your export is ready” notifications, deliverability isn’t a marketing metric — it’s a support ticket waiting to happen. This guide is for founders and engineering leads who’ve noticed one-time codes landing in spam, or who are about to bolt email onto a new product and want to get the architecture right the first time. We’ll cover transactional email deliverability from an engineering angle: authentication, sending architecture, and the ongoing monitoring that keeps your messages out of the junk folder.
Why transactional email deliverability is an engineering decision, not a marketing one
Most founders first hear about email deliverability from a marketing team worrying about newsletter open rates. But transactional email — the messages your application sends automatically in response to user actions — is a different problem with higher stakes. A promotional email landing in spam costs you a click. A password reset or two-factor code landing in spam locks a paying customer out of your product and generates a support ticket within minutes.
Spam filters at Gmail, Outlook and Yahoo don’t know or care that your message was “transactional.” They evaluate the sending domain, the sending IP, authentication results and historical sending patterns. If your transactional mail shares infrastructure with a sloppy marketing campaign, both suffer together. That’s why deliverability has to be designed into your sending architecture, not patched on afterwards.
Separate transactional and marketing streams from day one
The single highest-leverage decision is to keep transactional email and marketing/promotional email on separate sending domains or subdomains — for example notify.yourapp.com for transactional mail and news.yourapp.com for campaigns. Each stream builds its own sender reputation. If a marketing send gets flagged for complaints, it shouldn’t be able to drag down the domain your app uses to send login links.
This is a five-minute DNS change if you plan for it early, and a genuinely awkward migration if you don’t. It’s the same category of decision as choosing your database schema or your authentication provider: cheap now, expensive to unwind once you have real send volume and reputation history attached to a shared domain.
Authentication is no longer optional
Since early 2024, Google and Yahoo have required proper authentication for bulk senders, and enforcement has only tightened since. In practice, every sending domain needs:
- SPF — declares which mail servers are allowed to send on behalf of your domain.
- DKIM — cryptographically signs outgoing mail so receivers can verify it wasn’t tampered with.
- DMARC — tells receiving servers what to do with mail that fails SPF/DKIM checks, and gives you reporting on abuse of your domain. Even a starting policy of p=none is better than nothing, because it gives you visibility before you tighten enforcement.
Mailbox providers now expect complaint rates to stay well under 0.3%, with penalties ranging from spam-foldering to outright rejection for non-compliant senders. If you’re only setting up authentication once and never revisiting it, you’re treating a live requirement as a one-off checkbox — it needs to be part of your launch checklist for every new sending domain or subdomain, not just the first one.
Choosing an email service provider
Very few teams should be running their own mail transfer agent. Providers like Postmark, SendGrid, Mailgun and Amazon SES exist specifically to maintain IP reputation, handle authentication, and give you delivery and bounce data through an API. The choice between them is really a choice about how much reputation management you want to own yourself versus delegate.
Postmark, for instance, deliberately restricts its platform to transactional mail and will suspend accounts that send bulk marketing through it — which is exactly the kind of separation discussed above, enforced for you. Others like SES are cheaper at volume but leave more of the reputation and compliance work to you. Whichever you choose, treat it like any other paid dependency: understand the pricing model before volume grows, not after. We’ve written more generally about the real cost of integrating third-party APIs, and the same logic applies here — the sticker price rarely includes the engineering time to handle failures gracefully.
Don’t send email in the request-response cycle
A common and avoidable mistake: firing off the email send synchronously inside the HTTP request that triggers it. If the ESP’s API is slow or briefly unavailable, your user’s checkout or sign-up hangs waiting on a network call that has nothing to do with the response they’re expecting. Push the send onto a background job instead, so the request returns immediately and the email goes out (with retries) a moment later. If you haven’t set one up yet, our guide to background job queues for startups covers when this is worth the added infrastructure and when it isn’t.
Queuing also gives you a natural place to implement retry-with-backoff for transient ESP errors, rather than silently dropping a password reset because the provider returned a timeout once.
Handle bounces and complaints, don’t just send and hope
Every reputable ESP sends webhook events for bounces, spam complaints and unsubscribes. Ignoring these is one of the fastest ways to quietly wreck your sender reputation — if you keep sending to addresses that have hard-bounced for weeks, mailbox providers read that as carelessness, and it drags down deliverability for every message you send, including the transactional ones your business depends on.
At minimum, build a webhook handler that suppresses future sends to hard-bounced or complained addresses. This is a smaller version of the same reliability problem covered in our webhook reliability guide for SaaS founders — verify signatures, handle retries and duplicate deliveries, and make sure a dropped webhook doesn’t leave you sending into a void indefinitely.
Monitor deliverability like any other production metric
Deliverability degrades quietly. A slowly rising bounce rate, a domain reputation dip, or a spike in spam complaints rarely triggers an obvious error — your emails just start arriving less reliably, and you often find out from a confused customer rather than a dashboard. Track send success rate, bounce rate and complaint rate as first-class metrics alongside your application’s other health indicators, and set alerts on thresholds rather than checking manually. If you’re already thinking about what to instrument as you scale, our piece on observability for startups covers the broader principle: know before your users tell you.
Common mistakes worth avoiding
- Sending OTPs and receipts from the same domain as newsletters. One marketing misstep shouldn’t be able to lock users out of their accounts.
- Skipping DMARC because SPF and DKIM “already work.” Without DMARC alignment, you have no policy and no visibility into spoofing of your domain.
- Never cleaning your list. Repeatedly emailing addresses that don’t exist is one of the fastest ways to burn sender reputation.
- Treating deliverability as a launch-day task. Authentication requirements and provider policies change; review your setup at least twice a year.
Getting transactional email right is a small piece of a much bigger picture — reliable infrastructure, sensible third-party integrations, and monitoring that catches problems before customers do. If you’re planning a new product or auditing an existing one, DELLIUX builds this kind of infrastructure as part of our web and app development work. If you’d like a second opinion on your setup, book a free consultation.
FAQ
Do transactional emails need SPF, DKIM and DMARC even at low volume?
Yes. Mailbox providers evaluate authentication regardless of volume, and Google and Yahoo’s bulk sender rules apply once you cross a few thousand messages a day to their domains — a threshold most growing products reach faster than expected.
Should we use the same email service provider for marketing and transactional email?
You can use the same provider, but send from separate domains or subdomains so the two streams build independent sender reputations.
What’s the fastest way to check if our emails are landing in spam?
Check your ESP’s bounce and complaint dashboards first, then send test messages to accounts on major providers (Gmail, Outlook, Yahoo) and inspect the authentication results in the message headers.
Is Amazon SES a good choice for a startup?
It’s inexpensive at volume, but it gives you less built-in reputation management than providers like Postmark or SendGrid, so you’ll need to invest more engineering time in monitoring and list hygiene.
