Why your email lands in spam — and the four records that decide it

Almost every “our email goes to spam” ticket we open ends the same way: nothing is technically broken, nothing is misconfigured in the mail client, and yet half the messages are filed away from the inbox. The cause is almost never the subject line. It is that the receiving server could not answer one question — is this really from that domain? — with a yes.

This guide is the checklist we run before quoting a deliverability fix, written so you can run it yourself in about ten minutes. It assumes you can edit DNS; that is the whole job.

The receiver asks four questions, not ten

Gmail, Outlook and Yahoo do not score your HTML. They ask four yes/no questions, each answered by one DNS record:

Question	Record	What it proves
Where does mail for this domain go?	MX	The domain can receive at all — a broken MX is why bounces look like spam rejections
Which IPs may send as this domain?	SPF (TXT)	The sending IP is on your list
Did this message leave with your signature intact?	DKIM (selector._domainkey)	The message was not altered in transit, and which domain signed it
What should I do when the first two disagree?	DMARC (_dmarc)	Your policy, and where to send reports

Everything else — content, links, images, subject — is a secondary signal. Fixing the records does not guarantee the inbox, but no amount of good copy survives a failed alignment check.

Alignment is the part people miss

SPF and DKIM both produce a “pass”, and both can still be useless. What DMARC actually checks is alignment: does the domain that passed SPF or DKIM match the domain in the From header the recipient sees?

That distinction matters the moment a relay is involved. When your mail server hands a message to a delivery service, the envelope sender usually becomes something like em1234.yourdomain.com — a subdomain owned by the provider. SPF then passes for that name. If DMARC is set to aspf=s (strict), em1234.yourdomain.com does not align with yourdomain.com, and the message fails DMARC while every individual check looks healthy. Set adkim=r and aspf=r until you have verified your senders, then tighten only if you control every envelope.

The same logic applies to DKIM: a signature with d=yourdomain.com that survived transit is what saves a message whose SPF failed. This is why we insist on both legs, not the easier one.

The four failures we see most often

1. No SPF record at all. The domain sends fine from a client that ignores the missing record, and fails everywhere that does not. A blank answer is not permission.
2. SPF that does not cover the real sender. A record listing only mx while invoices leave through a third-party API is a promise you are not keeping. Each provider you add must be in the list.
3. DKIM broken by the path. Own mail server signs, relay rewrites the body footer, signature dies. You then rely on SPF alignment that never covered the domain in the first place.
4. DMARC at p=none forever. Reports arrive, nothing is enforced, and a forger can send as you with no consequence. p=none is a starting point, not a resting place.

There is also the record you cannot see from outside: two SPF records on the same name. Receivers treat that as a permanent error, not a merge. If you have ever pasted a second v=spf1 TXT beside the first, every SPF check for that domain has been failing since that day.

Run the check before you change anything

Type your domain into our free email health check. It queries MX, SPF, DKIM and DMARC from your browser against a public resolver — no signup, no server in the middle, nothing sent to your mail server — and tells you which of the four is missing or weak, with the record to add.

Read it in this order:

• MX missing or pointing nowhere → fix receiving first; nothing else matters.
• SPF missing or multiple → one record, listing every legitimate sender, ending in -all once you are sure.
• DKIM missing → publish the selector your provider gives you, and confirm the d= domain matches your From domain.
• DMARC missing or p=none → publish or tighten the policy, and add a rua= address you actually read.

The order to fix them

Records first, policy last. Changing DMARC before SPF and DKIM are correct just teaches receivers to reject your own mail.

1. Publish or repair SPF, one record, listing every sender.
2. Publish DKIM for each sender, verify a real message passes with the signature intact.
3. Publish DMARC at p=none with a rua= mailbox you monitor.
4. Read the aggregate reports for a week or two. They are XML, ugly, and the only honest answer to “who is sending as us”.
5. Raise the policy in steps — p=quarantine; pct=25, then pct=100, then p=reject — and keep watching between steps.

Each step is reversible. The only irreversible mistake is skipping to the last one.

What records cannot fix

We would rather say this plainly than sell a fix that cannot work. If your records are correct and mail still lands in spam, the cause is behavioural:

• Reputation of the sending IP, especially a shared one you do not control.
• Blocklist listings — check the big ones before blaming Gmail.
• Content and link patterns that trip filters, including shorteners and mismatched link domains.
• Volume and velocity — a brand-new domain sending 2,000 messages on day one looks exactly like a spam run.
• Complaint rate — one bad list purchase can undo months of clean sending.

Those are fixed by sending history, list hygiene and time. Records only remove the excuse: with SPF, DKIM and DMARC aligned, receivers stop judging you on someone else’s IP reputation and start judging your actual behaviour, which is the only signal you can improve.

If you would rather hand it over

We do this as a fixed-scope job: audit the current records, publish the correct set, test with real messages to Gmail, Outlook and Yahoo, then watch the first week of reports and tell you what changed. Or take the checklist above and do it yourself — the free check will tell you when you are done.