A deliverability canary for your transactional email

The idea

A hosted canary that sends your actual transactional templates — password reset, magic link, receipt — to a pool of seed mailboxes across Gmail, Outlook, Yahoo, iCloud, and a couple of corporate Microsoft 365 tenants, on a schedule. It logs into each seed box, finds the message, and records where it landed: inbox, promotions, spam, or nowhere at all. Alongside that it parses your inbound DMARC aggregate reports and watches for authentication drift. The output is one dashboard that answers a question nobody can currently answer: are the emails my product depends on actually arriving?

Why build this

Every SaaS product has a silent single point of failure in its signup funnel. When Gmail starts filing your magic links into spam, nothing breaks, no error rate spikes, no alert fires — support tickets just get vaguer and conversion sags a few percent. Founders usually discover it weeks later, by accident.

The trigger is usually invisible too: a shared IP on your ESP's pool went bad, someone in marketing sent a campaign from the same domain, your SPF record hit the ten-lookup limit after adding a new vendor, or you rotated DKIM keys and only published one of them. Gmail and Yahoo's bulk sender rules made authentication and complaint rates hard requirements rather than best practices, so the failure modes are now sharper and more sudden. Existing tools in this space are priced and packaged for marketing teams running campaigns; a solo founder wants a $19/month smoke alarm for the six emails their product actually sends.

Stack sketch

• Seed mailbox harvesting: imapflow (Node) against real accounts for Gmail/Yahoo/iCloud via app passwords; Microsoft Graph API for the M365 tenants, since IMAP basic auth is dead there. Store per-account creds in a KMS-backed secret, never in the app DB.
• Placement detection: match on a per-run UUID in a custom header, then read the folder the message landed in plus Gmail's X-Gm-Labels for tab placement (Primary vs Promotions vs Updates).
• Send path: the customer points a webhook or SMTP relay at you, or you send on their behalf via their own Postmark/SES/Resend credentials so the test uses their real reputation — this is the part that has to be honest.
• Auth monitoring: an inbound address for rua= DMARC reports, parsed with mailauth, plus scheduled DNS checks for SPF lookup count, DKIM selector presence, and DMARC policy changes.
• Backend: Postgres for runs and placements, a job queue (BullMQ or Postgres-backed) for the schedule, since IMAP polling is slow and flaky and needs retries.
• Alerting: Slack and PagerDuty webhooks, triggered on placement regression rather than absolute state.

Scope for v1

In:

• Five seed mailboxes across three providers.
• Daily runs of up to three templates.
• Placement timeline per template per provider.
• Alerts on any transition from inbox to spam or missing.
• SPF/DKIM/DMARC record checks with diffing.

Out:

• Content scoring and spam-word linting. It is noise, and every competitor leads with it.
• Blacklist monitoring — cheap to add later, and mostly false positives.
• Campaign or bulk-send analytics. Stay on transactional.
• Any inbox-placement claim for providers you do not have a real seed account on. Never extrapolate.

Where it could go

The obvious next layer is per-recipient-domain reporting for B2B senders. If your customers are all at a handful of corporate domains, aggregate placement matters far less than "is mail reaching acme.com" — and that answer comes from bounce logs and DMARC forensic data you are already ingesting. Sell that as the enterprise tier.

The second path is a pre-send guard: an API endpoint that checks the current health of a sending domain before your app fires a critical email, so you can fall back to SMS or an in-app code when deliverability is degraded. That turns a monitoring product into part of the customer's auth flow, which is a much stickier place to sit.

Watch out for

Provider terms of service are the whole ballgame — automated seed accounts sit in a grey area, and Gmail in particular will lock accounts that look synthetic, so age them slowly and give them real usage patterns. Also resist the temptation to send from your own shared infrastructure: results are only meaningful when the mail travels the customer's exact send path.