Subscribe or follow on X for updates when new posts go live.
When I first needed to send email for SaaS apps and other features, I assumed it was a solved, boring problem.
It turns out email is anything but simple and getting it right meant learning way more about infrastructure, trust, and reputation than I expected.
It was more work than I planned for, but absolutely worth it once I understood what was really going on under the hood.
Until I started doing this for myself, I naively thought email was simple: you type a message, hit “send,” and it shows up in someone’s inbox.
Behind the scenes, however, it’s a distributed system involving multiple actors, protocols, and trust mechanisms. From an app or business perspective, sending email is less like sending a message and more like handing a letter to a global postal network and hoping it clears every checkpoint along the way.
At a high level, sending an email looks like this:
Each step has failure modes, security checks, and reputation implications.
From an engineering perspective, email is:
It’s a system built for resilience and decentralization, not developer convenience.
This is your product, backend service, or system that wants to send email (password resets, invoices, notifications, marketing messages, etc.).
The application typically:
Most apps use a mail transfer agent (MTA) or a third-party Email Service Provider (ESP) like SendGrid, Amazon SES, or Postmark.
Responsibilities include:
This server represents your “sending identity” to the rest of the internet.
We'll go into this in more detail below, but essentially DNS is the directory email servers rely on to find each other and establish trust.
Critical DNS records include:
If DNS is misconfigured, mail may be rejected before content is even considered.
depending on what you choose, the email provider might automatically generate these records for you and all you need to do is plug them into your registrar or web hosting provider
use dmarcian or easydmarc if you really wanna learn the ins and outs of dmarc services, email visibility and protection.
This is the server run by the recipient’s provider (Gmail, Outlook, Yahoo, corporate email, etc.).
Its responsibilities:
This is where most delivery failures happen.
The final consumer interacts only with the result:
By this point, all technical decisions have already been made.
Before continuing on too far w/ sending and receiving emails, it's important to understand some basics about email in general.
Think of deliverability as a three-legged stool:
When sending emails, you need to take into account a lot of factors like reputation, spam (maybe add a cpl others here) etc in order to keep email inbox placement high
No email provider can guarantee inbox placement, but using any email provider + correct DNS + sane sending behavior is absolutely sufficient to avoid spam in practice for transactional email.
In order to be able to send email from an application using a particular domain, you must control the DNS for that domain.
These are mandatory, non-negotiable and usually the real bottleneck. If any of them are missing or wrong, your email is either no sent or it will hit spam.
For each sending domain, the following DNS records must exist:
MX answers the question:
“Where should email for this domain be delivered?”
When someone sends an email to @yourdomain.com, the recipient’s mail server:
MX records define:
No MX records = mail bounces.
Incorrect MX records = mail disappears into the void.
MX records do not:
They only answer where mail goes, not whether it should be trusted.
MX is the foundation.
SPF, DKIM, and DMARC sit on top of it.
If MX is wrong, nothing else matters.
SPF answers the question:
“Is this server allowed to send email on behalf of this domain?”
The recipient server:
SPF does not validate message content.
Failing SPF = spam or outright rejection.
DKIM answers:
“Was this message modified after it was sent?”
The sending server:
The recipient:
This ensures message integrity and domain alignment.
Proves the email wasn’t altered
Massive positive signal to Gmail, Outlook, Yahoo
This is one of the biggest factors
No DKIM = you’re playing on hard mode.
DMARC ties SPF and DKIM together and defines policy. Tells inboxes how to treat failures.
DMARC tells recipient servers:
DMARC is critical for preventing spoofing and phishing.DMARC isn’t required to send, but it dramatically improves trust.
Authentication proves who you are. Reputation decides where your email lands.
You can have perfect SPF, DKIM, and DMARC and still go straight to spam if inbox providers don’t trust your sending behavior. Authentication is table stakes. Reputation is the game.
Inbox providers continuously evaluate whether you behave like a real application—or like a spammer who just learned DNS.
Inbox providers don’t look at one thing. They look at patterns over time.
They evaluate:
A single bad signal won’t kill you. A pattern of bad signals will.
This is why even “technically correct” email setups can fail in production.
Warm-up is not ceremony. It’s trust-building.
When a brand-new domain starts sending email, inbox providers assume neutral intent, not good intent. You haven’t earned trust yet.
If you go from zero to high volume immediately, you look exactly like:
Warm-up is how you prove, gradually, that you’re none of those things.
It’s volume plus behavior, over time.
During warm-up, inbox providers watch engagement far more closely than raw volume.
Good signals:
Bad signals:
Warm-up isn’t about convincing filters. It’s about convincing users, and letting inbox providers observe that.
Reputation is scoped to each sending domain.
This is good because:
It’s also painful because:
There’s no global “account reputation” that saves you.
Every domain earns its own reputation from scratch.
Most modern providers do a lot right:
What they cannot do for you:
Reputation is behavioral. That part is always on you.
There are two separate reputations in play.
Domain reputation almost always applies. This is the primary signal for most application email.
IP reputation depends on your setup:
Most apps only need to worry about domain warm-up.
With:
Typical outcomes look like:
This is the same setup used by startups, banks, internal tools, and infrastructure platforms. There’s nothing exotic about it. Just disciplined execution.
Warm-up should be boring. Predictability beats speed.
This assumes real users and real transactional email only.
Days 1–2 5–10 emails per day Password resets, signups, receipts No marketing, no blasts
Days 3–4 20–30 emails per day Same message types Spread across the day
Days 5–7 50–100 emails per day Still transactional No bursts or cron spikes
Week 2 200–500 emails per day
Week 3+ Gradually ramp to normal volume
If your app only sends ~50 emails a day total, you’re effectively always warm. No special handling needed.
The fastest ways to sabotage yourself:
Inbox providers love consistency. They hate surprises.
Healthy signals:
If you see:
Slow down immediately. Reputation recovers slowly, but it does recover if you stop digging.
Warm up isn’t about speed.
It’s about proving, quietly and repeatedly, that your app behaves like a real system sending real email to real people.
To be honest, your content could matter more than the email provider you choose to use.
All the right DNS records and perfect Reputation won’t save you if your emails start to look like this:
🚨 ACT NOW 🚨
FREE FREE FREE
Click here immediately!!!
Things that will get you flagged
Things that help inboxing
But for normal app emails like:
...content is usually not the problem.
I mentioned above but sending test emails to yourself over and over can hurt reputation if you do it in production outside of a sandbox.
with all that in mind, how are you suppoed to even test your email sending works and what the emails look like before you send them to real customers without getting penalized? lets go into this below
Before you ever worry about sending emails “in the wild,” you should get ruthless about cost control. During early development, most emails exist for one reason only: to verify that something works. Password resets, invites, confirmations, alerts, all of which usually go straight to you and then straight to the trash.
Paying for those emails is unnecessary. Worse, it’s a habit that quietly leaks money and can even harm your real sending domain if you’re not careful.
For development and testing, where you don’t care about real delivery and don’t want to spam actual inboxes, the right move is to send emails locally and virtually.
The simplest approach is to run a local SMTP “catcher.” Your app thinks it’s sending real email, but nothing ever leaves your machine.
Instead:
http://localhost:8025No logins. No credentials. No cleanup.
This is ideal when:
MailHog is a popular option here. It runs locally, captures all SMTP traffic, and gives you a clean UI to review messages. This is what I use for local development.
Papercut is another solid alternative. It serves the same purpose and works well across platforms. If MailHog isn’t your thing, Papercut fills the same role with almost no mental overhead.
Both tools let you fully exercise your email logic without:
If self-hosting a dev email tool is a non-starter, many cloud email providers offer sandbox or test modes where messages don’t actually reach real recipients.
These can be useful, but they come with tradeoffs:
They’re fine in a pinch, but for day-to-day development, local capture tools are usually simpler, cheaper, and more predictable.
At some point, your app will need to send real emails. The mistake founders make is baking that decision directly into their application logic.
Instead, build a thin email-sending interface that lets you swap implementations based on environment:
Your app shouldn’t care how an email is delivered, only that an email was requested.
This gives you:
This boundary is important.
Email delivery is an implementation detail, not application logic. Treat it that way.
This is exactly how mature SaaS platforms operate:
You save money during development, avoid reputation penalties on your real domain, and keep your system flexible as you scale.
By this point, I've shown you how email actually works: sending, receiving, DNS, SPF/DKIM/DMARC, reputation, and even how to safely develop and test email locally.
Now comes the part founders usually care about most:
How much does this cost, and which provider should I actually use?
The good news: sending email is cheap.
The bad news: the operational trade-offs between providers are what trip people up.
Let’s bring everything together.
Email providers typically charge based on a mix of:
At the infrastructure level, email is a solved problem. What you’re really choosing is how much time and friction you want to trade for money.
Below are the most common options I've found that founders evaluate for transactional email.
Best for: High-quality transactional email with minimal fuss.
Postmark is opinionated and intentionally narrow in scope: it does transactional email extremely well.
Strengths
Trade-offs
If email is mission-critical (password resets, invoices, alerts) and you want it to just work, Postmark is often worth the premium.
Best for: Teams that want dashboards, analytics, and marketing-style tooling.
SendGrid is a full-featured platform that spans transactional and marketing email.
Strengths
Trade-offs
SendGrid makes sense if email is a business function, not just an infrastructure detail.
Best for: Developers who want flexibility without AWS complexity.
Mailgun sits nicely between SES and SendGrid.
Strengths
Trade-offs
Mailgun is often chosen when SES feels too raw, but SendGrid feels like overkill.
Best for: Founders who care about cost, scale, and control.
Amazon SES is not flashy. It’s cheap, reliable, and brutally honest about what it is: infrastructure.
SES charges only for usage. If you send nothing, you pay nothing.
SES lets you send from:
example.com)no-reply@example.com)You can verify:
All at no additional cost.
If you verify a single domain, you can send from unlimited addresses under it:
Because SES doesn’t optimize for:
It assumes you know what you’re doing or are willing to learn.
SES usually breaks down organizationally, not technically:
That’s when teams migrate away from SES. Not because it can’t scale, but because time becomes more valuable than money.
| Provider | Pricing Model | Approx. Cost per 1,000 Emails | Free Tier / Trial |
|---|---|---|---|
| Amazon SES | Pay-as-you-go | ~$0.10 | 3,000/month (first year, eligible accounts) |
| Mailgun | Usage or tiered | ~$0.80 (Flex pricing) | Limited trial |
| SendGrid | Monthly plans | ~$0.40–$0.90 (effective) | 100/day free |
SES continues scaling linearly at ~$0.10/1,000.
Mailgun and SendGrid scale via increasingly expensive tiers.
Here’s the practical decision table most founders eventually arrive at:
| Your Goal | Best Choice |
|---|---|
| Absolute lowest cost at any scale | Amazon SES |
| Developer-friendly APIs with tooling | Mailgun |
| Dashboards, analytics, and marketing features | SendGrid |
| Best-in-class transactional deliverability | Postmark |
Email isn’t expensive. Poor understanding is.
Once you understand:
…the choice becomes obvious.
Most early stage founders should:
Email is infrastructure until it becomes product-critical. Choose accordingly.
If there’s one mental model to keep, it’s this:
Think of email as:
Sending email isn’t just “sending a message.”
It’s participating in a long-running, adversarial system designed to stop abuse at massive scale. In that system, consistency and correctness matter far more than clever code.
Every time your application sends an email, you are:
Your email either earns trust over time or it doesn’t get delivered at all.
This is why email problems often look random until you understand the mechanics underneath.
To build a reliable email system, you have to think like both a developer and DevOps:
Email is one of the few systems where early mistakes are expensive and hard to undo.
If you remember nothing else, remember these:
p=none is better than nothing)Email works remarkably well when you respect how it works.
Founders who treat email as “just another API” often pay for it later with:
Founders who understand the system can:
Email isn’t magic, but it is a system that rewards understanding.