Password-reset mail going to spam
A user can’t reset their password = a churned account. Worst part is you’ll never see it in your funnel because they bounce out silently.
When your transactional mail goes to spam, churn goes up. Unspam continuously tests every product email you send: password resets, magic links, onboarding, billing. You know it’s reaching users before they open a support ticket.
A user can’t reset their password = a churned account. Worst part is you’ll never see it in your funnel because they bounce out silently.
Going from 10K → 1M emails/month in three weeks is the most common way to wreck a fresh sending domain. Most teams don’t monitor until it’s too late.
Marketing, transactional, billing, support: all four often send from the same root domain via different ESPs, each with slightly different SPF/DKIM. One bad include record breaks the rest.
Password resets, magic links, billing receipts: each tracked against its own placement threshold. Cross the line, the on-call gets paged.
Calibrated against actual delivery outcomes, not a generic spam-filter rule list that has nothing to do with real-world inbox placement.
Trigger a real password reset, magic link, or billing email to the Unspam address. Same path your users hit.
SPF/DKIM/DMARC verdict, spam score with actionable diff, inbox placement per provider.
Autopilot runs daily for each transactional flow so you know the morning a placement issue starts.
Alerts go to email or Slack on the same threshold you’d page for an outage. Email-delivery slip = real outage.
Product email is infrastructure. When it breaks it’s a silent outage, no PagerDuty page, just users who can’t log in. These are the patterns SaaS teams set up first.
Three weeks before launch: warm up the domain, verify SPF/DKIM/DMARC across all the sub-domains your stack uses, and lock in a placement number you can compare against post-launch.
Daily Autopilot test on each transactional flow: reset, billing, alerts, magic link. Alert page on regression so an on-call engineer sees it before a user complains.
Run a single test against each ESP your product uses (Postmark for transactional, SendGrid for marketing, etc.) and confirm SPF/DKIM/DMARC alignment across the stack.
Test magic-link emails across consumer Gmail and corporate Google Workspace. A 60% inbox rate is a silent login failure for 40% of your users.
After a spike in complaint rates, run daily placement tests to confirm your billing flow is back in primary before the next renewal batch goes out.
Switching from Postmark to Resend? Run before-and-after tests on every flow so reputation regressions don’t ship to production silently.
Yes: Postmark, SendGrid, Mailgun, SES, Mandrill, Mailjet, Resend, your own SMTP. Unspam tests whatever actually arrives at our seed list; the originating ESP is irrelevant.
Each test breaks down which mechanism passed/failed/aligned. For multi-ESP setups you’ll see per-message exactly which sender record was used, so you can confirm every ESP is correctly aligned without grep-ing through DNS records. The inbox-placement test tells you whether that alignment actually moves placement on the receiving end.
API access is part of the White Label tier. Talk to us about getting an integration set up. Programmatic test runs let you wire a deliverability check into the same pipeline that ships your transactional templates.
For password reset / billing / security, anything below 95% inbox placement at the major providers is worth paging on. Promotions/marketing tolerates more. Set the threshold per flow inside Unspam.
Different layer. Your ESP shows what it accepted, bounced, complained on. Unspam shows where the accepted mail actually went at the receiving end, inbox vs spam vs promotions. They’re complementary.
Free placement test on a real production send. Wire up Autopilot in five minutes.