Why it happens
The sending domain does not say who may send for it. Receiving servers look up the domain's SPF record, check the DKIM signature and read the DMARC policy before they trust a message; a domain that publishes none of them looks exactly like a forged one. Gmail and Yahoo have required all three from bulk senders since 2024, and file the rest away.
How to tell
- No TXT record starting v=spf1 on the sending domain.
- No DKIM key at the selector your provider gave you.
- No v=DMARC1 record at _dmarc.your-domain.
- Your provider's domain page shows the domain unverified or pending.
The fix
- Open your email provider's domain page and add every DNS record it lists — SPF as a TXT record on the domain, DKIM at the selector it names, and a DMARC record at _dmarc with at least p=none — then verify the domain there.
- Send from an address on that domain, not from a gmail.com or the provider's shared domain.
- Send a test to a Gmail address and open the message headers: SPF, DKIM and DMARC should each read pass.
Where to look
The prompt for your builder
Paste this into Lovable, Bolt, Cursor, Claude Code or whatever built the app. Replace anything in capitals. It never asks you to paste a secret into a chat; keys go into your host’s environment, by you.
I send transactional email for MYDOMAIN through PROVIDER and it lands in spam. List the exact DNS records I need — SPF, DKIM (with the selector PROVIDER uses) and DMARC — as name, type and value, tell me where to add them at my DNS host, and how to read a Gmail message's headers to confirm all three pass.
How Keelnest catches it
Backend Guard reads the sending domain's SPF, DKIM and DMARC records from public DNS once an hour and names the missing one; the app is degraded, never down, because mail that does not arrive is serious and is still not an outage.
Know the moment this happens.
Keelnest watches your production app every five minutes and tells you in plain English what broke — with the fix. Free for your first app.