Why do my emails go to spam?

Three records decide most of it

A receiving server has one second to judge a message from a domain it may never have seen. It starts with three DNS records, because those are the only things about your email that cannot be forged.

Missing DKIM is the single most common reason a legitimate app's mail lands in spam. Everything else on this page matters less than getting that one record right.

The records to publish

Add your domain under Domains and we generate the exact values for you, including a DKIM key pair that only ever exists on our side as a private key. They look like this:

; DKIM — required. The selector is generated per domain.
mail._domainkey.yourdomain.com.   TXT   "v=DKIM1; k=rsa; p=MIIBIjANBgkq..."

; SPF — one record per domain, merged if you already have one
yourdomain.com.                   TXT   "v=spf1 include:<the token we show you> ~all"

; DMARC — start here, tighten later
_dmarc.yourdomain.com.            TXT   "v=DMARC1; p=none; rua=mailto:[email protected]"

Two rules that catch people out. A domain may have exactly one SPF record — if you already send through Google Workspace or anyone else, merge the includes into the existing record rather than adding a second one, because two SPF records is a permanent error, not a warning. And if your DNS is behind a proxy such as Cloudflare, these TXT records must stay DNS-only; proxying applies to HTTP, and a proxied mail hostname simply stops answering.

Alignment: the part nobody explains

You can have SPF passing, DKIM passing, and DMARC still failing. That is not a bug — DMARC does not ask “did SPF pass?”. It asks did SPF or DKIM pass for the domain in the From: header, the one your reader sees.

It matters here because of how bounces work. We send with an envelope sender on our own bounce domain, so that failures come back to us and get recorded against the message instead of vanishing. SPF is checked against that envelope domain, which means SPF is authenticated but not aligned with your From domain.

So DKIM is what carries DMARC for your mail. That is why the DKIM record is marked required in your dashboard and SPF is not: SPF is useful, and some filters weigh it, but it is DKIM that makes DMARC pass. Publish both; never skip DKIM.

Check what receivers actually see

Send yourself a real message from your app, then in Gmail open the message menu and choose Show original. The top of that page states SPF, DKIM and DMARC as plain pass or fail, for that specific message. It is the only opinion that counts, and it takes ten seconds.

What you want to see:

SPF:    PASS with IP 62.238.46.237
DKIM:   'PASS' with domain yourdomain.com
DMARC:  'PASS'

A DKIM line naming a domain that is not yours means the message was signed, but not for you — the From address is on a domain you have not verified. A DKIM failure with the right domain usually means the DNS record was pasted with a line break or a missing character: the key is long, and copying it by hand is where it goes wrong.

Beyond that, mail-tester.com scores a single message out of ten and names what it dislikes, and the rua= address in your DMARC record collects daily XML reports from every large receiver. Point it somewhere you will read.

When the records are right and it still goes to spam

Authentication gets you considered, not accepted. Once the three records pass, what is left is reputation and behaviour:

• A brand-new domain has no history. Filters are cautious with a domain first seen last week. Volume that ramps gently over two or three weeks reads as a real product; a thousand messages on day one reads as a list.
• Bounces are the loudest signal. Repeatedly mailing addresses that do not exist is what list-buyers do. Keep hard bounces suppressed — we do it automatically, and you should not be re-adding those addresses.
• Nobody opening anything. Transactional mail is normally opened. Recipients who never engage, over weeks, pull the whole domain down.
• Mixing marketing into transactional mail. Receipts and password resets enjoy high engagement; newsletters do not. Sent from the same domain, the newsletter's complaints follow your password resets into spam. Use a subdomain for anything bulk.
• The message itself. A single image with no text, link shorteners, an unfamiliar tracking domain, ALL CAPS subjects, or an HTML part with no plain-text alternative all cost you.
• No unsubscribe on anything bulk. Since 2024, Gmail and Yahoo require one-click unsubscribe and a complaint rate under 0.3% from anyone sending in volume. Transactional mail is exempt from the unsubscribe rule — but only if it is genuinely transactional.

Getting out of the spam folder

Reputation recovers slowly and only through behaviour. In order: fix authentication so every message passes DMARC; stop sending to anything that bounced; cut volume back to the people who actually use your product; and let two or three weeks of clean sending accumulate.

In the short term, asking a handful of real users to move the message to their inbox and reply to it does more than any header you can add — engagement is the signal filters trust most. What does not work is sending more, changing the subject line repeatedly, or moving to a fresh domain and starting the same pattern again.

Tightening DMARC later

Start at p=none, which asks receivers to report but change nothing. Once your reports show your own mail passing consistently for a few weeks — including anything sent by other services on the same domain — move to p=quarantine, then p=reject.

Going straight to p=reject before reading reports is how a company discovers, one Monday morning, that its invoicing tool was sending from the same domain and every invoice is now being refused outright.

Quick diagnosis