Why do your emails keep landing in spam?

The short version

When legitimate mail ends up in the spam folder, it is almost never random. Receiving servers such as Gmail, Outlook and corporate filters score every message on three questions: does the sender prove who it is, does the sending IP have a clean reputation, and does the message look like mail people actually want? Fix those three and the problem usually disappears. Below is how to diagnose each one, in order of how often it is the real cause.

1. Email authentication: SPF, DKIM and DMARC

This is the most common cause by far. Since 2024, Gmail and Yahoo require authentication for anyone sending in volume, and unauthenticated mail is quietly demoted or rejected. You need three DNS records on your sending domain.

SPF lists which servers are allowed to send for your domain. DKIM adds a cryptographic signature so the receiver can verify the message was not altered. DMARC ties the two together and tells receivers what to do when a check fails.

Check what you currently publish:

dig +short TXT example.com
dig +short TXT default._domainkey.example.com
dig +short TXT _dmarc.example.com

Typical healthy records look like this:

SPF:   v=spf1 mx include:_spf.yourprovider.com -all
DMARC: v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; adkim=s; aspf=s

Start DMARC with p=none to collect reports, then move to quarantine and finally reject once SPF and DKIM pass reliably. If DKIM returns nothing, the selector name is wrong or your mail server is not signing at all; check the selector your provider uses.

2. Reverse DNS (PTR) and the HELO name

If you run your own mail server, the sending IP must have a valid PTR record that resolves back to a real hostname, and that hostname should match the name the server announces in its HELO/EHLO greeting. A mismatch or a missing PTR is an instant reputation hit.

dig -x 203.0.113.10 +short

The result should be something like mail.example.com, and a forward lookup of that name should return the same IP. PTR records are set by whoever owns the IP block, so if it is blank, ask your hosting provider to add it.

3. IP and domain reputation, and blacklists

A brand new domain or IP has no history, so filters treat it with suspicion. Never send bulk mail from a fresh IP on day one; ramp volume up gradually over a few weeks. Also confirm you are not listed on a blocklist such as Spamhaus. Sending from a residential or dynamic IP address will almost always be blocked, which is why mail should go through a proper server with a static IP and clean rDNS.

Quick reputation checks: send a message to a test tool like mail-tester.com for a scored report, and enrol your domain in Google Postmaster Tools to watch spam rate and authentication over time. Keep your reported spam complaint rate below 0.3 percent.

4. Content and sending habits

• Send over an encrypted connection (STARTTLS/TLS). Plain unencrypted mail is penalised.
• For newsletters and notifications, include a working List-Unsubscribe header with one-click support.
• Avoid image-only emails, link shorteners, misleading subject lines and ALL-CAPS shouting.
• Make the From address match the sending domain, and warm addresses by removing bounces and inactive recipients.
• Keep a consistent sending domain instead of switching between many.

A fast diagnostic checklist

1. Run the three dig commands above. SPF, DKIM and DMARC must all be present and pass.
2. Check PTR with dig -x and confirm HELO matches.
3. Send one message to mail-tester.com and fix whatever scores below 10.
4. Verify the IP is not on a blocklist.
5. Confirm TLS is active and the unsubscribe header exists for bulk mail.

Takeaway

Ninety percent of spam-folder problems are authentication and reputation, not content. Publish correct SPF, DKIM and DMARC records, give the sending IP a matching PTR and a clean history, send over TLS, and monitor your spam rate. Get those right and your mail lands in the inbox where it belongs.