Transactional emails land in spam
Receipts, password resets, magic links, or notifications reach some users' spam folders — or vanish entirely. Deliverability quietly worsens as you send more.
- Any stack
- Bubble
- Webflow
- Email delivery
Root cause, in plain English
Mailbox providers judge the sending domain, not the message copy. Mail fails their checks when SPF and DKIM records are missing or don't align with the domain in your From address — common when an email service was connected without finishing its DNS setup. Major providers like Gmail and Yahoo now require authenticated, DMARC-covered sending, so an unauthenticated or brand-new domain with no history gets filtered no matter how legitimate the email is.
How to fix it
Send a test to a deliverability checker (mail-tester.com or similar) and read the report — it names exactly which of SPF, DKIM, and DMARC are missing or misaligned for your actual sending path.
In your email provider's dashboard (Postmark, Resend, SES, SendGrid…), complete domain verification and add every DNS record it lists: the DKIM keys and the SPF include for that provider.
Publish a DMARC record (start with p=none and a reporting address) so providers can see your domain claims its mail — then tighten policy once reports look clean.
Make the From domain match the authenticated domain. Sending "from" your domain through a service that isn't authorized for it is precisely what filters are built to catch.
Separate transactional from marketing sending (different subdomains, e.g. mail. and news.) so a newsletter complaint spike can't drag receipts and magic links down with it.
How Nightlamp detects this automatically
- Email flow
An email_flow monitor triggers your real transactional sends on a schedule and verifies the message actually arrives in a dedicated mailbox within the expected window — missing or badly delayed mail raises an alert. Because it exercises the genuine send path (your app, your provider, your domain), it catches DNS record regressions and provider issues the moment they start, not when users complain.
Catch this before your customers do
Nightlamp runs these checks continuously against your live app and sends a plain-English diagnosis — not a wall of logs — the moment this pattern shows up.
Related patterns
Frequently asked questions
- Why did deliverability get worse after a domain or DNS change?
- SPF, DKIM, and DMARC live in DNS. A site migration or DNS cutover that drops those records silently de-authenticates your email — everything keeps sending, but receivers stop trusting it. Re-verify your email DNS records after any domain work.
- My SPF record exists — why does authentication still fail?
- Alignment matters, not just existence: the domain that passes SPF/DKIM must match your From domain. Sending through a shared provider that signs with its own domain passes DKIM for them, not for you. Complete the provider's custom-domain setup so signatures use your domain.
- Does email content (spammy words, too many links) still matter?
- Far less than authentication and domain reputation. Fix SPF/DKIM/DMARC first; content tweaks on an unauthenticated domain are rearranging deck chairs. Once authenticated, keep complaint rates low and volume consistent.
Newsletter
Get new incident patterns as we publish them
One email when new failure patterns, fixes, and monitoring recipes for no-code and AI-built apps land. No fluff, unsubscribe any time.
Double opt-in. One-click unsubscribe. No spam, ever.