DEV Community: Luke Thomas

Why your email goes to spam, and how to actually fix it

Luke Thomas — Sat, 04 Jul 2026 13:03:58 +0000

You hit send, and the email never arrives. Or it arrives in the spam folder, and the person on the other end swears they checked. The maddening part is the silence: no bounce, no error, no explanation. Just a message that quietly did not land.

I have spent more Friday afternoons than I would like chasing exactly this, and the lesson every time is the same. The reason your email goes to spam is almost never a mystery once you stop looking at the symptom and start reading what the receiving mail server actually sees. This is the process we use, in order, with a tool for each step.

A quick story, because it makes the point

We build Trace Warrior, and we send our transactional email (signups, receipts, alerts) through a proper provider. Not long ago our own signup emails started vanishing. The sending dashboard cheerfully reported every one as "delivered." The inbox said otherwise.

It turned out Microsoft 365 had accepted the messages at the server, which is all "delivered" means, and then quietly quarantined them as High Confidence Phishing. Quarantine is a holding area that never touches the inbox or even the junk folder, so from our side there was nothing to see. Two lessons fell out of that afternoon, and they shape everything below:

"Delivered" is not "read." It only means the receiving server accepted the handshake. What happens next is invisible from the sending side.
The reasons mail gets filtered live in your DNS records, not in your outbox. You have to go and read them.

The mental model: deliverability is three questions

Almost every "why is my email going to spam" problem is one of three things, and it helps to work them in this order:

Can mail physically reach the domain? That is your MX records.
Can the receiver prove the mail is really from you? That is SPF, DKIM, and DMARC.
Does your sending identity have a bad reputation? That is blacklists, plus content and sending behaviour.

Spam folders and silent filtering are nearly always a failure of number two or number three. Run the checks in order and the black box turns into a short, specific list of things to fix.

1. MX: can mail even reach you?

Before anything else, confirm the domain's mail is pointed somewhere sane. Broken or missing MX records mean mail bounces or, worse, silently routes to the wrong place. The classic mistakes are an MX pointing at a CNAME (which some servers refuse), a host that no longer resolves, or a null MX that declares the domain does not accept mail at all.

Run an MX lookup on your domain. You want to see your real mail provider (Google Workspace, Microsoft 365, and so on), every host resolving to an IP, and no health warnings. If this part is broken, fix it first.

2. SPF: does the sending server have permission?

SPF (Sender Policy Framework) is a DNS record that lists which servers are allowed to send mail as your domain. When a receiver gets a message claiming to be from you, it checks whether the sending server is on that list.

The silent killer here is a limit almost nobody knows about: SPF is allowed a maximum of 10 DNS lookups. Every include: in your record (and every provider you add, from your CRM to your help desk to your newsletter tool) consumes lookups, and they nest. Go over 10 and receivers return a permerror, SPF fails, and your perfectly legitimate mail starts getting filtered.

Run an SPF check on your domain. It walks every include the way a receiving server does, counts your lookups against the limit of 10, and flags the other common faults: multiple SPF records (which invalidate each other), a +all that authorises the entire internet, and broken includes. If you are near the limit, that is very often your answer.

3. DKIM: is the message actually signed?

DKIM (DomainKeys Identified Mail) adds a cryptographic signature to every message, so the receiver can prove the mail genuinely came from your domain and was not tampered with in transit. It is also the authentication method that survives forwarding, which SPF does not.

The annoying part of checking DKIM is that you need the "selector", a short name your provider chose, and most people have no idea what theirs is. Our DKIM checker gets around that: leave the selector blank and it scans the selectors that every major provider documents (Google, Microsoft 365, SendGrid, Fastmail, Proton, and more) until it finds yours. It then validates the key itself, flagging revoked keys, weak 1024-bit keys, and records left in testing mode.

4. DMARC: what should the receiver do on failure?

DMARC ties SPF and DKIM to the domain in your visible From address and tells receivers what to do when a message fails: nothing (p=none), send it to spam (p=quarantine), or reject it outright (p=reject). It also gives you reports on who is sending mail as your domain, which is how you catch both spoofers and forgotten senders.

Two things make DMARC urgent. First, Google and Yahoo now require it from anyone sending in bulk. Second, without it, receivers have no instructions for handling mail that fails your other checks, which makes both spoofing and false-positive filtering more likely.

Run a DMARC check. It reads your policy with organizational-domain fallback exactly like a real receiver, explains every tag in plain language, and verifies something most tools miss: whether your report destinations are actually authorised to receive your reports. If you have no DMARC record, start with p=none to watch the reports, then tighten to quarantine and reject once they look clean.

5. Blacklists: is your IP or domain already burned?

You can pass every authentication check and still land in spam if the IP you send from, or your domain, is on a spam blocklist (a DNSBL). This happens more than you would think: shared IPs at budget hosts, a compromised device on your network, or simply a fresh IP with no reputation.

Run a blacklist check on your sending IP or domain against the major lists (Spamhaus, SpamCop, Barracuda, and others). One warning: be careful which checker you trust here. Spamhaus and some others deliberately refuse queries from shared public resolvers and answer with sentinel codes, and naive tools display those as "listed", a false accusation about your IP. Ours queries through its own resolver to get real answers, and decodes each list's return codes so a residential-policy marker is never reported as a spam listing.

The alignment trap: why "SPF passes" is not enough

Here is the subtlety that trips up even experienced admins. SPF and DKIM can technically pass and still not align with your From domain, and DMARC requires alignment, not just a pass. This is why mail sent "on behalf of" you through a third party often fails DMARC even though SPF is green.

It is also why you want both SPF and DKIM, not just one. When a message is forwarded, SPF breaks (the forwarding server is not on your list), but DKIM survives, because the signature travels with the message. Authenticate on both and your mail holds up through mailing lists, forwards, and the long tail of ways email actually moves.

The boring reasons that still matter

If your authentication is clean and you are not blacklisted, the remaining causes are less technical but just as real:

A brand-new domain or IP has no sending reputation. Warm it up slowly instead of blasting your first campaign to 50,000 people.
Missing reverse DNS (PTR). Many receivers quietly penalise a sending IP with no PTR record.
Spammy content: all-image emails, link shorteners, aggressive subject lines, or a missing unsubscribe link.
Sudden volume spikes, which look exactly like a compromised account.

Fix it once, then keep it fixed

The hard truth about deliverability is that it is not set-and-forget. A fat-fingered DNS edit, an expired DKIM key, an SPF record that quietly grows past 10 lookups as you add tools, or an IP that lands on a blocklist can undo all of this silently, and you find out when your mail stops arriving, usually at the worst possible moment. That is the case for monitoring the records themselves, so drift alerts you instead of your customers.

The 60-second checklist

When someone says their email is going to spam, run these five, in order:

MX resolves to your real mail host, no warnings
SPF exists, ends in -all, stays under 10 lookups
DKIM key is published and valid
DMARC is published, at least p=none with reporting
Blacklists: your IP and domain are clean

Then confirm reverse DNS is set and the content is not obviously spammy.

The reason "my email goes to spam" feels like a black box is that the sending side shows you almost nothing. The receiving side shows you everything, you just have to ask it.

What is the sneakiest deliverability bug you have run into? Mine is still the Microsoft quarantine that reported "delivered" the entire time it was eating our mail.

DNS gets blamed last and breaks first: my symptom-to-root-cause playbook

Luke Thomas — Wed, 01 Jul 2026 18:33:47 +0000

Every incident I have chased that started with "the site is down" and ended in DNS had one thing in common: the error messages pointed everywhere except DNS. Timeouts, TLS warnings, a login screen that spins forever. You go poking at the app, the load balancer, the database, and an hour later it turns out a resolver was handing back a stale answer the whole time.

So I stopped trusting symptoms and started isolating layers. Here is the process I actually run, in order.

Three shapes of the same problem

Almost every DNS failure shows up as one of three things.

NXDOMAIN. The resolver asked the authoritative servers and got a definitive "this name does not exist." Sometimes that is true: an expired domain, a typo. More often the record exists and you are staring at a cache that has not caught up yet. If the name resolves at the authoritative source but your resolver says NXDOMAIN, you are not debugging, you are waiting.

Resolver not responding. Nothing resolves and browsing by name just stops. Usually the resolver itself is unreachable: an ISP outage, a firewall quietly eating port 53 (DNS needs both UDP and TCP), or the wrong resolver addresses in the config.

Slow resolution. Pages hang for a few seconds, then load fast. That is the classic signature of a dead primary resolver, where every lookup burns a full timeout before falling back to the secondary.

The one idea that makes this easy

Separate three questions and never let them blur together:

Can I reach the network at all?
Can I resolve names?
Is the answer I get back correct?

Each step answers exactly one of those.

Reach the network, no names involved:

ping 1.1.1.1

If that fails you have a connectivity problem, not a DNS problem. Stop blaming DNS.

Can you resolve at all:

dig google.com

Raw IP works but names do not? DNS is now confirmed as the failing layer.

Is the answer correct, and whose fault is a bad answer:

dig example.com            # your resolver
dig @1.1.1.1 example.com   # a known-good public one

This is the decisive split. If a public resolver answers correctly and yours does not, the fault is your resolver or the path to it. Point at 1.1.1.1 or 8.8.8.8 and keep working while you fix it. If the public resolver is also wrong, the problem lives at the authoritative side, in the zone itself.

When you suspect a broken delegation, one command settles it:

dig +trace example.com

That walks the chain from the root servers down to the authoritative nameservers and shows every referral. A registrar pointing at the wrong nameservers jumps straight out.

The cache is the liar

The most confusing DNS bugs, the "works on my machine, fails on the server" ones, are almost always stale caches. Flush yours before you theorize:

# macOS
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
# Linux (systemd-resolved)
sudo resolvectl flush-caches
# Windows
ipconfig /flushdns

And because your local cache can lie to you, it helps to get a second opinion from outside your own network. Full disclosure: I build a set of network tools called Trace Warrior, and the DNS lookup runs the query from a neutral vantage point and shows every record type at once, which is the fastest way to tell "my resolver is stale" from "the record is genuinely wrong."

The other half is not waiting for a human to notice. Most DNS incidents I have seen were a record that changed and nobody clocked it: a fat-fingered edit, or worse, a hijack. We ended up adding a DNS record monitor that watches for drift and alerts the moment an answer changes, because "should this record exist?" is a miserable question to be asking in the middle of an outage.

What actually prevents the next one

Lower TTLs before a planned change, raise them after. A TTL left at 86400 turns a five-minute cutover into a full day of split traffic.
Redundant nameservers on separate networks. Two nameservers on the same subnet is one nameserver wearing a disguise.
Reverse DNS, or your mail quietly stops being delivered.

The whole trick is refusing to guess. Reach, resolve, correct, in that order. Run the steps and DNS stops being mysterious and turns into a short walk to whichever layer is lying to you.

What is the DNS bug that took you longest to catch? Mine was a validating resolver throwing SERVFAIL on a broken DNSSEC signature while everyone else resolved fine. I would genuinely love to hear the one that got you.

Your TLS certificates will only last 47 days soon. Most teams have not done the math

Luke Thomas — Fri, 12 Jun 2026 10:51:36 +0000

In April 2025 the CA/Browser Forum voted 25 to 0 to shrink the maximum lifetime of public TLS certificates. Not by a little. The ballot is called SC-081v3 and this is the schedule it locked in:

Effective	Max validity	Roughly
Today	398 days	13 months
March 2026	200 days	6.5 months
March 2027	100 days	3.3 months
March 2029	47 days	1.5 months

I run a small network monitoring product and I keep having the same conversation about this. Someone tells me "we renew certs once a year, we are fine." Then I show them the renewal math and the room goes quiet.

The math nobody is doing

Picture a mid-size company with 600 public TLS certs. Websites, APIs, load balancers, CDN configs, VPN portals, the usual sprawl. Today that means roughly 600 renewals a year. Annoying, but a spreadsheet and a calendar reminder can survive it.

Walk the same estate forward:

2026, at 200 days: about 1,200 renewals a year
2027, at 100 days: about 2,400 renewals a year
2029, at 47 days: about 4,660 renewals a year

That last number is 120 renewals every working day. There is no spreadsheet workflow on earth that survives 2029. Manual cert management is not getting harder. It is ending.

There is a second cost hiding under the headline too. Organisation validation for OV and EV certs can currently be reused for up to 825 days. From March 2026 that drops to 398 days. So even if you buy a multi-year "subscription," you will be redoing the paperwork roughly every year on top of the extra renewals.

Why they are doing this

The short version: revocation never worked. CRLs got too big, OCSP leaks browsing history and mostly soft-fails, and everyone in the room knows it. If a private key leaks today, the worst case exposure is over a year. With 47-day certs the certificate dies on its own within weeks, whether or not revocation does its job.

Short lifetimes also force regular key rotation, which makes future algorithm migrations (hello, post-quantum) far less painful. And they push the whole ecosystem toward what Let's Encrypt already proved works: boring, automated issuance.

You can agree or disagree with the trade-offs. The vote was unanimous, so it is happening either way.

What it means for your setup

Already on ACME (Let's Encrypt, ZeroSSL, etc.): you are mostly fine on the issuance side. Your real risk is silent renewal failure. A DNS change, a rate limit, a webroot misconfig, and nothing tells you until the deployed cert expires. Monitor the certificate that is actually serving traffic, not the cron job that is supposed to renew it. Those are two different things and the gap between them is where outages live.

Manual paid certs (DigiCert, Sectigo, GlobalSign and friends): the calendar-reminder workflow stops being sustainable in 2027 and stops being possible in 2029. Most of these CAs now offer ACME endpoints. Ask your account manager, move to automation this year, and keep the CA relationship if you like it.

Appliances that cannot speak ACME: the long tail of pain. Old load balancers, VPN concentrators, vendor firewalls where renewal means a portal upload and a service restart. Your realistic options are a firmware upgrade that adds ACME, or a reverse proxy in front that owns the cert and re-encrypts upstream. Start the inventory now because procurement cycles are slower than CA/B Forum ballots.

The plan I would follow

2026: inventory and monitor. Find every public cert you own, including the ones nobody remembers (status pages, legacy mail hosts, partner integrations). Put expiry monitoring on all of them, not just the critical ones. Daily checks are plenty. The goal is to never be surprised.
2027: automate everything renewable. By year end, your manual list should be down to appliances you physically cannot upgrade, each with a remediation plan.
2028: dry-run the 47-day cadence. Set internal certs to 47 days a year early and watch what breaks while breaking is still cheap.

And one cultural change: route cert expiry alerts into the same on-call rotation that gets paged for outages. An expired cert is a production outage. It just happens to be one you can schedule.

Disclosure

I build Trace Warrior, a small network tools site with an SSL expiry monitor, so yes, I have skin in this game. The certificate checker is free with no signup if you want to spot-check a host right now. But honestly, use anything. Use a bash script and cron if that is your style. Just do the inventory before March 2026 makes it urgent.

Curious what others are doing: how are you handling renewals on hardware that will never speak ACME? Reverse proxy shims, firmware nagging, or planned replacement?