Why Is My Email Going to Spam? A Browser-Only Triage for SPF, DKIM, DMARC, PTR and Blocklists

Few things are as quietly maddening as a perfectly normal email landing in someone's spam folder. A password reset, an invoice, a reply to a customer: gone, filed next to fake lottery wins. The good news is that most deliverability problems come down to a small set of DNS records and reputation signals, and you can check nearly all of them from a browser in about fifteen minutes.

This guide walks through the triage in the order I'd actually do it. No terminal, no paid dashboards. Just evidence first, then fixes.

Step 0: Get one real message that went to spam

Don't start by guessing at DNS. Start with a message that actually failed. Ask the recipient to forward it as an attachment, or send a test to a Gmail or Outlook account you control and find it in Junk.

Then open the full headers ("Show original" in Gmail, "View message source" in Outlook). This raw text is the single most useful thing you'll look at today, because it contains the receiving server's own verdict.

Step 1: Read the headers before touching anything

Paste the raw headers into the Email Header Analyzer. It traces the routing path hop by hop, lists the IP address of each server along the way, and pulls out the SPF, DKIM and DMARC results.

Look for the Authentication-Results line. You'll typically see something like spf=pass, dkim=fail, dmarc=fail. That tells you where to dig:

• All three pass, still spam? The problem is probably reputation or content, not authentication. Skip ahead to Steps 5 and 6.
• SPF fails: the sending IP isn't authorized for your domain.
• DKIM fails or is missing: the message wasn't signed, or the signature doesn't match the published key.
• DMARC fails: neither SPF nor DKIM passed in alignment with the From domain (more on that below).

Also write down the IP of the first external hop, the server that actually handed the mail to the internet. You'll need it for the PTR and blocklist checks.

Step 2: Check SPF

What it is: SPF (Sender Policy Framework) is a TXT record on your domain that lists which servers are allowed to send mail for it. It looks like this:

v=spf1 include:_spf.google.com include:sendgrid.net -all

v=spf1 include:_spf.google.com include:sendgrid.net -all

Run your domain through the Email Security Checker, which inspects SPF, DKIM, DMARC, MTA-STS, TLS-RPT and BIMI in one pass. If you want to see the raw records yourself, the DNS Lookup tool will show every TXT record on the domain.

Common SPF mistakes:

• Two SPF records. You're allowed exactly one TXT record starting with v=spf1. Adding a second one when you sign up for a new service is the most common way people break SPF. Merge them into one.
• Too many lookups. SPF has a limit of 10 DNS lookups (each include, a, mx and redirect counts, and nested includes count too). Go over and receivers return a permerror, which often behaves like a fail.
• Forgetting a sender. Your newsletter tool, your CRM, your helpdesk, the billing system: every service that sends as your domain needs to be covered, or needs to send from a subdomain with its own record.
• This authorizes the entire internet. Never do it. Use ~all (soft fail) while testing and -all once you're confident.

Step 3: Check DKIM

What it is: DKIM adds a cryptographic signature to each message. The receiving server fetches your public key from DNS at selector._domainkey.yourdomain.com and verifies the signature.

The selector is in the DKIM-Signature header of your message (the s= value). Look up that exact name as a TXT record with DNS Lookup, or let the Email Security Checker find it.

Common DKIM mistakes:

• Signing is never turned on. Many providers require you to publish the key and click an "enable" or "authenticate" button. Publishing the record alone does nothing.
• Broken key formatting. Long keys are sometimes split into multiple strings, and some DNS panels add stray quotes or line breaks. A single missing character invalidates the key.
• Signing with the provider's domain. If the signature says d=mailprovider.net instead of d=yourdomain.com, DKIM may "pass" but won't align for DMARC.

Step 4: Check DMARC

What it is: DMARC is a TXT record at _dmarc.yourdomain.com that tells receivers what to do when a message fails authentication, and where to send reports:

v=DMARC1; p=none; rua=mailto : dmarc-reports@yourdomain.com

v=DMARC1; p=none; rua=mailto : dmarc-reports@yourdomain.com

The key idea is alignment. DMARC passes only if SPF or DKIM passes and the domain they validated matches the domain in the visible From address. This is why a message can show spf=pass and still fail DMARC: SPF validated your email provider's bounce domain, not yours.

Common DMARC mistakes:

• No record at all. Major mailbox providers now expect bulk senders to have DMARC. Even p=none is better than nothing.
• Jumping straight to p=reject. If you haven't confirmed every legitimate sender aligns, you'll block your own mail. Start at none, read the reports, move to quarantine, then reject.
• Reports going nowhere. A rua address that no one reads means you're flying blind.

For a broader look at your domain's email-related DNS (MX, SPF, DKIM, DMARC together), the DNS Security Scanner gives a useful second opinion.

Step 5: Check reverse DNS (PTR)

What it is: A PTR record maps an IP address back to a hostname. Receiving servers check that your sending IP has one, and ideally that the hostname resolves back to the same IP (forward-confirmed reverse DNS).

Take the sending IP from Step 1 and run it through the Reverse DNS Lookup.

• If you use Google Workspace, Microsoft 365, or a major sending service, PTR is their job, and it's almost always fine.
• If you run your own mail server or send from a VPS, a missing or generic PTR (something like 123-45-67-89.static.isp.net) is a classic spam trigger. PTR records are set by whoever owns the IP block, so you'll usually configure it in your hosting provider's panel, not your DNS provider's.

Step 6: Check blocklists

If authentication passes and PTR looks right, reputation is the next suspect. Put the sending IP into the IP Blacklist Checker, which queries five DNS-based blocklists (Barracuda, SpamCop, UCEPROTECT, JustSpam and PSBL) in one go.

Be honest with yourself about the results:

• On a shared sending service? A listing on a shared IP is the provider's problem to solve. Open a ticket with them.
• On your own server? Find out why before requesting delisting. A compromised account, an open form that sends mail, or a purchased list will get you relisted within days.
• Clean everywhere and still in spam? Five lists aren't the whole picture. Big providers like Gmail and Microsoft keep their own internal reputation data, and content, engagement and sending volume all matter. Check their postmaster tools for your domain.

Step 7: Re-check after you change DNS

DNS changes aren't instant. After editing a record, use the DNS Propagation Checker to confirm resolvers around the world see the new value before you conclude a fix "didn't work." Then send a fresh test message and read the headers again. That's the only verdict that really counts.

The quick checklist

• [ ] Got the raw headers from a real message that went to spam
• [ ] Read Authentication-Results: which of SPF, DKIM, DMARC failed?
• [ ] Exactly one SPF record, under 10 lookups, covering every sender, ending in ~all or -all
• [ ] DKIM enabled at every sending service, signing with your domain (d=yourdomain.com)
• [ ] DMARC record exists at _dmarc, with a rua address someone actually reads
• [ ] SPF or DKIM aligns with the From domain
• [ ] Sending IP has a PTR that resolves back to the same IP
• [ ] Sending IP isn't on any blocklist (and you know why if it was)
• [ ] DNS changes have propagated before you re-test
• [ ] Sent a fresh test and confirmed the new headers say pass

A final word

Deliverability problems feel mysterious, but they rarely are. In most cases the headers tell you exactly what failed, and the fix is a single DNS record: a duplicate SPF entry, a DKIM key that never got enabled, a missing DMARC policy. Work through it in order, change one thing at a time, and verify with a real message after each change.

All the tools linked above are part of FindUtils, a collection of 463 free tools that run in your browser. No sign-up, no installs.

Originally published at https://dev.to on October 14, 2026.