Resets and receipts get filtered
A user who never receives the reset link cannot log in. That is a churn event, and it arrives in your tracker as a product bug.
For SaaS and transactional email
Transactional email is infrastructure, and it fails the way infrastructure fails: quietly, after a change nobody connected to email, in a system no engineer is watching.
14-day free trial · no credit card · cancel anytime
LitInboxes is an email deliverability monitoring platform for businesses and agencies that depend on email for revenue, customer communication, or client results.
The problem
All five are configuration problems, which means all five are detectable.
A user who never receives the reset link cannot log in. That is a churn event, and it arrives in your tracker as a product bug.
A new SES identity, a rotated DKIM key, a Terraform apply that rewrote a TXT record. Nothing errors, and the next reset lands in spam.
Providers rotate keys and add selectors. Monitoring that checks a single selector reports green while a real signing key is unpublished.
The policy file expires, or the DNS record and the hosted policy stop agreeing. Nobody checks a thing that worked once.
Deliverability lives in a marketing tool nobody on the engineering rota opens. If it does not reach the channel you watch, it is not monitoring.
The fix
The same monitoring, addressed to engineers instead of marketers.
SPF with its lookup count, DKIM for up to three selectors per domain, DMARC policy and alignment, MTA-STS and BIMI. Re-resolved and compared, so a change becomes an event.
Slack, Discord or a webhook on Pro, email on every plan, carrying what changed and the corrected value, so whoever is on call gets the same output as the person who owns deliverability.
Point rua at LitInboxes and aggregate reports are ingested and grouped by sending source, which is how you find the internal system nobody authenticated.
A REST API with per-resource scoped keys on Pro, plus a hosted MCP server with OAuth 2.1, so an AI assistant can answer why is our reset email going to spam against your own workspace.
ESP webhooks feed bounce and complaint events into the same workspace as your DNS and blocklist state, so a spike arrives with the reason next to it.
In the product
The infrastructure view lists each record, what resolved, whether it passes, and what to change. It reads like a check output, because that is what it is.
DNS & authentication
SPF, DKIM, DMARC and MTA-STS, rechecked every 6 hours.
DMARC
99.2%912 reports · 48,120 messages
Deliveries
Healthy0.02% complaint rate
Blocklists
CleanSpamhaus, Barracuda, SpamCop and 21 more
Recent activity
The domain overview, as it looks in the app.
The numbers
Four checks that catch the configuration failures that filter transactional mail.
How many DNS lookups your SPF record costs, measured against the limit of 10.
Bad looks likeAt 10 or more, SPF returns permerror and stops passing everywhere.
Up to three selectors per domain, each resolved and validated on its own rather than as a single pass or fail.
Bad looks likeA selector that stops resolving after a provider rotates keys.
The published policy, the reporting addresses, and whether real mail aligns with the domain it claims.
Bad looks likep=none indefinitely, or aligned mail dropping after a subdomain change.
The policy record, the hosted policy file, and whether the two still agree.
Bad looks likeA max_age that lapsed, or a policy file that no longer matches the record.
The mechanism
Transactional email tends to work until something changes. An SPF include added by a new vendor pushes the record past 10 DNS lookups and SPF starts returning permerror. A provider rotates DKIM keys and publishes a new selector while your zone still advertises the old one. A service starts sending from a subdomain that inherits no policy from the root. None of these are mysteries. They are configuration states, and configuration states can be asserted on.
Which makes this monitorable the way the rest of your infrastructure is monitorable: define the expected state, re-resolve it on a schedule, diff it against the last known good, and raise an event on the difference. That is what the 6-hour check loop does across SPF, DKIM per selector, DMARC policy and alignment, MTA-STS and BIMI. DMARC aggregate reports close the loop from the other direction by naming systems that send as you, including the ones no one registered.
The gap in most teams is ownership rather than tooling. Deliverability signals sit in a marketing tool, while the people who can fix DNS are on an engineering rota that never opens it. Slack alerts, a scoped REST API and a hosted MCP server exist for exactly that reason: to put the signal where the on-call person already looks.
Getting started
Step two is the one that catches rotations.
Usually a subdomain like mail.yourapp.com, or the SES identity domain, rather than your marketing site.
Add up to three per domain, so a provider rotation cannot hide behind the one selector you happened to check.
Update rua in the DMARC record. Aggregate reports arrive daily from the large providers and are grouped by source.
Slack, Discord or a webhook on Pro, or pull the state through the REST API if you would rather route it into your own alerting.
Pro, $99/mo
Wire deliverability checks into your stack.
Honest limits
Three things a product team might want that LitInboxes does not do.
Questions
No. Keep SES, Postmark, Resend, SendGrid or your own MTA. LitInboxes monitors the domains they send from and the records that make them trusted.
Up to three per monitored domain, each resolved and validated separately so a rotation surfaces as a specific failure.
Yes, on Pro. Bearer keys prefixed lit_, scoped per resource, a documented OpenAPI 3.0 spec, and per-IP and per-key rate limits with Retry-After on 429.
Yes, on Pro. The hosted MCP server uses OAuth 2.1 with PKCE and exposes domain health, DNS records, DMARC summaries, Postmaster data, blocklist status, email events, alerts and verification.
Yes. Add the subdomain as its own monitored domain and its policy, alignment and reports are checked separately from the root.
Checks run every 6 hours per domain, and you can trigger one on demand at any time.
Pro, $99/mo
Wire deliverability checks into your stack.
Past a few thousand messages a day, providers stop judging emails and start judging you. The numbers that decide it are published.
Read the use caseReceipts, shipping updates and campaigns leave from different subdomains. When one drifts, support tickets tell you before your ESP does.
Read the use caseAuthentication, blocklists and DMARC reports on a 6-hour loop, with an API and an MCP server on Pro.
14-day free trial on every plan. No credit card required, nothing is charged unless you choose a plan, cancel anytime.
A partner referred you. Allow a cookie so they get credit if you sign up?Details in ourprivacy policy.