Your SaaS sends transactional and notification email through a provider. When deliverability breaks, your users miss password resets and onboarding emails. Here's how to catch it before your users do.
You built a SaaS product. You're sending password resets, onboarding emails, and transactional notifications through SendGrid, Postmark, Mailgun, or Amazon SES. You're not doing cold email. You're not doing marketing blasts. You're sending the emails that matter: the ones your users need to log in, get started, and use your product.
And then one day, a user emails support and says "I never got my password reset link." Or your onboarding conversion drops 15% and you can't figure out why. Or your users start complaining that they're not getting your product notifications.
This is the SaaS deliverability problem, and it's different from the cold email or marketing deliverability problem in important ways. Let me walk you through what's different, what to check, and how to catch it before your users do.
When you send cold email or marketing email, the cost of a deliverability failure is a lower open rate. You lose a lead, maybe a sale. It's a revenue problem.
When you send transactional email and it fails, the cost is a user who can't log in, can't complete onboarding, or doesn't get a critical notification. They can't use your product. They churn. They leave a bad review. They tell their friends your product is broken.
This is a retention problem, and it's much more expensive than a revenue problem. A user who can't get their password reset is a user who's leaving. A user who misses their onboarding email is a user who never activates.
Here's the thing: most SaaS teams don't monitor their deliverability. They assume their ESP is handling it. They assume if the API returns a 200, the email went out. And that's true: the email went out. But "went out" and "delivered" are different things.
Here's the specific problem SaaS teams face: you're sending through a provider, and the provider can change things without telling you.
SendGrid rotates their IP pools. Postmark changes their signing keys. Mailgun updates their DNS records. Amazon SES changes their sending infrastructure. Any of these changes can break your deliverability overnight, and you won't know until a user complains.
The provider's API will still return a 200. The email will still "send." But it might land in spam, or it might get rejected by the receiving server. Your logs will say "delivered" because the provider's server accepted it. But the user's inbox says otherwise.
This is the gap between "sent" and "delivered," and it's the gap that monitoring closes.
Here's the checklist for SaaS deliverability, in the order you should check it:
Your sending domain (the domain in your From header, e.g. yourproduct.com) needs an SPF record that includes your ESP's IP ranges. If you're sending from mail.yourproduct.com, that subdomain needs its own SPF record.
How to check: Run dig TXT yourproduct.com and look for a record that starts with v=spf1. Make sure it includes your ESP (e.g. include:sendgrid.net for SendGrid).
How often: Once, when you set it up. Then again if you change ESPs or add a new sending domain.
Your ESP signs your emails with DKIM. The public key lives in your DNS. If the key rotates (and it will, eventually), your old signature becomes invalid and your emails fail authentication.
How to check: Run dig TXT selector._domainkey.yourproduct.com (replace selector with your ESP's selector). Make sure the record exists and matches what your ESP is using.
How often: Monthly. DKIM keys can expire or rotate, and you won't know until your emails start failing.
DMARC tells receiving servers what to do when an email fails SPF or DKIM. If your policy is p=none, you're not enforcing anything. If it's p=reject, you're telling receivers to reject any email that fails authentication.
How to check: Run dig TXT _dmarc.yourproduct.com. Look for a record that starts with v=DMARC1. Check the p= value.
How often: Once, when you set it up. Then again if you change your policy.
Your ESP sends from a pool of IPs. If another customer on that IP was spamming, your reputation suffers. This is the shared IP problem.
How to check: Use our Blocklist Checker to check your ESP's IP ranges. Also check your domain's reputation on Spamhaus.
How often: Weekly. IP reputation can change fast, especially if you're on a shared IP pool.
Hard bounces (the recipient doesn't exist) and spam complaints (the user marked your email as spam) are the two metrics that matter most for transactional email. If your bounce rate is above 2% or your complaint rate is above 0.1%, you're in trouble.
How to check: Your ESP's dashboard shows these rates. But the ESP's data is only as good as their tracking. Cross-check with your own logs: how many emails did you send, how many bounced, how many complaints did you get?
How often: Daily. Bounce rates can spike if you're sending to a list with stale addresses.
TLS encrypts email in transit. While it's not a hard requirement for delivery, many ISPs use it as a signal of legitimacy. If your ESP's IP doesn't support TLS, or uses an outdated protocol, receiving servers may flag your email.
How to check: Use our TLS Checker to check your ESP's mail server. Look for TLS 1.2 or higher and a valid certificate.
How often: Monthly. TLS certificates expire, and if your ESP's cert expires, your emails may start failing.
Check all 6 of these at once. No account needed. Get a score, the exact records to fix, and daily monitoring.
Run my free auditYou don't need a dedicated deliverability engineer. You need a system that checks these 6 things daily and alerts you when something breaks. Here's the minimum viable monitoring setup:
Most SaaS teams don't have this. They find out about deliverability problems from support tickets, not from monitoring. And by the time a user complains, they've already had a bad experience.
The cheapest way to catch deliverability problems before your users do is to run a daily check on your sending domain. Not a monthly audit. Not a quarterly review. A daily check that looks at SPF, DKIM, DMARC, IP reputation, and TLS, and alerts you when something changes.
That's what Inboxproof does. Run a free audit on your sending domain, get a score, and set up daily monitoring. When something breaks, you get an alert before your users do.
Free audit. No account needed. Daily monitoring for Pro.
Run my free audit