Email is the protocol that everyone supports and no one understands. Every SaaS product needs to send transactional email — receipts, password resets, webhook delivery failures, monitor alerts — and every SaaS product eventually discovers that "the email was sent" and "the customer received the email" are two completely different sentences. The gap between them is the discipline of deliverability, and it has accumulated four decades of complexity because email itself was designed without authentication and the ecosystem has been bolting on layers ever since.
This post is the practical guide for the SaaS engineer who knows enough to call a transactional email API and is now discovering that calling the API is the easiest part. It covers the three authentication standards (SPF, DKIM, DMARC), the reputation system that actually decides where your mail lands, the infrastructure choices that compound, and the operational signals you should be monitoring whether or not anyone has yet complained.
The three authentication records
Email authentication is a Jenga tower of three protocols layered on top of SMTP. SPF (Sender Policy Framework) is a TXT record listing the IP addresses authorized to send mail from your domain. The receiving mail server looks up the SPF record for the envelope-sender domain and checks whether the connecting IP is in the list. If not, the message can be rejected, marked spam, or delivered with a warning depending on the receiving policy.
DKIM (DomainKeys Identified Mail) is a public-key signature on the message itself. You publish your public key as a TXT record, your sending infrastructure signs every outgoing message with the corresponding private key, and the receiver verifies the signature. Unlike SPF, DKIM survives forwarding — the signature is on the message, not the connection.
DMARC (Domain-based Message Authentication, Reporting, and Conformance) is the policy layer on top of SPF and DKIM. It tells receivers what to do when authentication fails (none, quarantine, reject) and where to send aggregate failure reports. DMARC also enforces alignment: the From-header domain must match the SPF or DKIM domain, which closes the loophole where a message could pass SPF for one domain while claiming to be from another.
The three records together are the modern email authentication baseline. Sending without all three in 2026 means many of your messages will be quietly delivered to spam folders or rejected outright, especially by Gmail and Yahoo, which since February 2024 have required all three for any sender exceeding 5,000 messages per day.
Reputation is the actual gatekeeper
Authentication says the message is genuinely from you. It does not say the message is welcome. The reputation system, run by each major mailbox provider on their own opaque rules, decides whether messages from your domain and IP get inboxed, junked, rejected, or rate-limited. Reputation is built from a mix of signals that the providers do not publish in detail: complaint rates, bounce rates, engagement (opens, replies, time-in-inbox), unsubscribe rates, and the consistency of your sending pattern.
The reputation is attached to both your sending IP and your sending domain. A new domain with no history starts with zero reputation, which means the first messages you send are subject to extra scrutiny. A new IP starts with no history too. Warming up — gradually increasing volume over weeks — is what builds the reputation that lets you send at full volume without triggering rate limits. ESPs (Email Service Providers) like Postmark, SendGrid, and Mailgun handle warmup for you on shared IPs, which is one of the reasons most small SaaS products should use them rather than running their own SMTP.
Transactional vs marketing: the separation that matters
The single largest deliverability mistake is sending transactional and marketing email from the same domain or IP. Transactional email (receipts, password resets, alerts) has high engagement, low complaint rate, and is genuinely wanted. Marketing email (newsletters, product announcements, promotions) has lower engagement and higher complaint rate. Mixed on the same reputation, the marketing complaints poison the transactional reputation, and customers stop receiving the password reset emails they actually need.
The fix is two separate sending domains: mail.yourcompany.com for transactional, news.yourcompany.com for marketing. Both can be subdomains of the same root, and both can use the same ESP, but they should have separate reputation. The cost is one extra domain configuration. The benefit is that your password reset emails do not get destroyed by a marketing campaign that someone marked as spam.
The infrastructure choices that compound
The choice of how to send email compounds over years. The options, in increasing order of cost and control: a transactional ESP (Postmark, SendGrid, Mailgun, Resend) handles infrastructure and authentication for you, dedicated IPs through an ESP give you reputation isolation, self-hosted SMTP through an MTA like Postfix gives you full control and full responsibility for everything including IP reputation and deliverability monitoring.
For most SaaS products under 100,000 messages per month, a transactional ESP is correct. The shared IP pool has good reputation, the authentication is configured for you, the bounce handling is automated, and the diagnostic tooling is mature. The cost is real but small relative to the engineering time saved. Self-hosting SMTP is correct only when the volume justifies a deliverability engineer, which is rarely under 1 million messages per month.
The bounce-and-complaint loop
Every time you send to an invalid address (hard bounce) or a recipient marks your mail as spam (complaint), the receiving provider sends a feedback signal to your sending infrastructure. If you do not process these signals — removing bounced addresses from future sends, removing complainants from future sends — your reputation deteriorates with each repeat offense. Most ESPs handle this for you, suppressing addresses on your behalf. Self-hosted senders need to implement the bounce parsing and the complaint feedback loop processing themselves, which is one of the reasons self-hosting is harder than it looks.
The discipline is to monitor bounce rate and complaint rate as continuous metrics. Bounce rate above 5% is a red flag — your list quality is poor or you have a code path generating addresses that do not exist. Complaint rate above 0.3% is a red flag — your messages are being perceived as unwanted, regardless of whether the recipient explicitly opted in. Both metrics are leading indicators of reputation collapse.
What to monitor
The minimum operational signals are: delivered rate (messages accepted by the receiving server), bounce rate split into hard and soft bounces, complaint rate from feedback loops, DMARC aggregate reports parsed for authentication failures, and inbox placement rate from a service like Postmaster Tools (Gmail) or Microsoft SNDS (Outlook).
The DMARC aggregate reports are the most underused signal. They are XML files sent daily by major receivers to the address listed in your DMARC record's rua field, and they show every authentication result for every IP claiming to send mail from your domain. The first time you read them you will discover three or four IPs you do not own attempting to send mail from your domain — that is what DMARC reporting is for, and it is how you discover spoofing attempts before they damage your reputation.
The List-Unsubscribe header
The 2024 Gmail/Yahoo requirements added a header that small senders often overlook: List-Unsubscribe with both mailto and https variants, plus List-Unsubscribe-Post: List-Unsubscribe=One-Click. The combination tells the receiver that the unsubscribe link can be activated by a simple POST without further confirmation. Gmail surfaces a one-click unsubscribe button in its UI for messages with this header, and senders without it are penalized for the friction of unsubscribing. The header should be on every transactional and marketing message, even if the unsubscribe semantics are slightly different per type.
Where the four products fit
All four products in our portfolio — DocuMint, CronPing, FlagBit, WebhookVault — send transactional email for account confirmations and alerts. All four use the same infrastructure pattern: dedicated transactional subdomain (mail.anethoth.com), SPF and DKIM and DMARC configured, ESP-handled bounce and complaint processing, and the One-Click unsubscribe header on every message. The setup is identical across products because deliverability does not vary by product line — it varies by domain and reputation, and we share the reputation across all four.
The honest summary
Email deliverability is one of those topics that you can spend a career on or a weekend on. The weekend version is: use a transactional ESP, configure SPF/DKIM/DMARC correctly, separate transactional from marketing on different subdomains, monitor bounce and complaint rates, parse the DMARC aggregate reports occasionally. That gets you to 95% inbox placement for legitimate transactional mail, which is good enough for most SaaS products to operate without customer-impacting deliverability failures.
The career version is what large senders pay deliverability consultants for, and what makes the difference between 95% and 99.5% inbox placement at scale. Most readers of this post do not need that. They need the weekend version, applied with discipline, and revisited the next time a customer says "I never got the email."