You sent an invoice. The customer swears they never got it. You check your sent folder — it's there. So where did it go? Almost always, the same place: a spam folder, or worse, a silent black hole where the receiving server just refused it.
Here's the uncomfortable truth. Inboxes like Gmail, Outlook, and Apple Mail don't trust email by default. Anyone can type your address into the "From" field of a message — that's how phishing works — so receiving servers assume mail is fake until it proves otherwise. The proof lives in three DNS records on your domain: SPF, DKIM, and DMARC. If they're missing, broken, or contradicting each other, your legitimate mail looks exactly like spam, and it gets filed accordingly.
The good news: these records are public, checkable in a few minutes, and fixable without touching a single line of code. You just have to know what you're looking at.
By the end you'll know:
- How spam filtering actually decides where your email lands
- What SPF, DKIM, and DMARC each do — and how they work together
- The two settings most people get wrong (the SPF 10-lookup limit and the
-allvs~allqualifier) - How to check whether your domain is on a blacklist
- The exact order to fix everything, lowest-risk first
Part 1 — How Inbox Spam Filtering Actually Works
Before the records, understand what the receiving server is doing. When a message arrives, the inbox provider runs it through a gauntlet in roughly this order: is the sender authenticated (do the DNS records check out?), is the sender's reputation good (has this domain and IP sent spam before?), and does the content look spammy (deceptive subject lines, image-only emails, sketchy links)? Authentication is the gate. Fail it and the other factors barely matter.
1.1 Authentication, reputation, content — in that order
The plain version: filters first ask "did this really come from who it claims?" That's SPF, DKIM, and DMARC. Then "do we trust this sender?" — built up over months of people opening, not deleting, not marking-as-spam. Then "is the message itself shady?"
What "bad" looks like: mail that fails authentication outright, sent from a domain with no sending history, full of "FREE!!!" and a single giant image with no text.
What to do: you can only directly control authentication, and it's the foundation everything else sits on. Fix that first. Reputation follows from good behavior over time; content is on you to keep clean.
1.2 The "From" address is a claim, not a fact
Email was designed in a more trusting era. The address in the "From" line is just text the sender typed — there's nothing stopping a scammer from putting your domain there. SPF, DKIM, and DMARC exist precisely to turn that unverified claim into something a server can verify.
What "bad" looks like: a domain with no authentication records at all. Every message from it is an unverified claim, and modern filters treat unverified mail with deep suspicion — especially Gmail and Yahoo, which since 2024 require authentication from bulk senders outright.
What to do: set up all three records. Each one closes a different gap, and DMARC only works when the first two are in place.
Part 2 — SPF: Who's Allowed to Send
SPF (Sender Policy Framework) is a public list, published as a DNS TXT record, of which mail servers are authorized to send email for your domain. When mail arrives, the receiver checks the sending server's IP against your list. On the list? Pass. Not on it? Fail.
2.1 Find and read your SPF record
An SPF record is a single TXT record on your root domain that starts with v=spf1. A typical one looks like v=spf1 include:_spf.google.com include:sendgrid.net ~all. Each include authorizes a sending service (Google Workspace, SendGrid, Mailchimp, your CRM). You can read yours with a free tool like MXToolbox's SPF checker, or your DNS provider's dashboard.
What "bad" looks like: no v=spf1 record at all, or — surprisingly common — two SPF records on the same domain. Having two is invalid by the spec, and many receivers will fail both. You're allowed exactly one.
What to do: confirm you have exactly one SPF record, and that every service you actually send through (email host, newsletter tool, CRM, helpdesk, invoicing software) is represented by an include. If you switched from Mailchimp to a new tool last year, make sure the old include is gone and the new one is in.
2.2 Watch the 10-lookup limit
This is the SPF trap nobody warns you about. Every include and a few other mechanisms force the receiver to do a DNS lookup, and the SPF spec caps the total at 10 lookups. Go over and SPF returns a "permerror" — a permanent failure — which can sink your deliverability even though your record looks fine to the naked eye. Each include can itself contain more includes, so the count adds up faster than you'd think.
What "bad" looks like: an SPF record stuffed with eight or ten include statements because you've accumulated every tool you've ever tried. It validates visually but blows the lookup budget.
What to do: count your lookups (MXToolbox flags this automatically). If you're near or over 10, remove services you no longer use, or "flatten" the record — replacing some includes with the actual IP ranges. Flattening needs maintenance when providers change IPs, so prune first.
2.3 Choose -all vs ~all deliberately
The last term in an SPF record tells receivers what to do with mail from servers not on your list. ~all is "softfail" — treat it as suspicious but probably still deliver. -all is "hardfail" — reject it outright. The difference matters: -all is stricter and better protects your domain from spoofing, but if your SPF list is incomplete, -all will actively block your own legitimate mail.
What "bad" looks like: +all (authorizes the entire internet to send as you — a gift to spammers), or jumping straight to -all before you're certain every sending service is in your record.
What to do: start with ~all while you confirm everything is captured, then tighten to -all once you've verified — ideally using DMARC reports (Part 4) — that nothing legitimate is failing. End state for a well-configured domain is -all.
Part 3 — DKIM: The Cryptographic Signature
SPF proves the message came from an authorized server. DKIM (DomainKeys Identified Mail) proves the message content wasn't tampered with in transit and genuinely came from your domain. Your sending server signs each message with a private cryptographic key; the matching public key sits in your DNS. The receiver uses the public key to verify the signature. Match means the message is authentic and unaltered.
3.1 Confirm DKIM is enabled and published
DKIM lives at a "selector" subdomain — something like google._domainkey.yourdomain.com or s1._domainkey.yourdomain.com. The selector name is assigned by your email provider when you turn DKIM on. Because the selector name varies, the easiest check is to send a test message to a Gmail account, open it, click "Show original," and look for DKIM: PASS.
What "bad" looks like: DKIM: 'fail' or no DKIM result at all in the headers — meaning your provider either never had you set it up, or the published key is wrong.
What to do: enable DKIM in your email provider's admin console (Google Workspace, Microsoft 365, and every major newsletter tool have a one-click "authenticate domain" flow that generates the DNS record for you). Publish the record they give you, then re-test with "Show original" until you see PASS.
3.2 Make sure every sending service signs
Here's the catch with DKIM: each service that sends on your behalf needs its own DKIM setup. Your Google Workspace mail might pass DKIM beautifully while your Mailchimp newsletters fail it, because you authenticated one and not the other.
What "bad" looks like: transactional mail (invoices, receipts) passes, but marketing email fails — or vice versa. Customers get some of your mail and not the rest, seemingly at random.
What to do: for every tool in your SPF record, go find its "authenticate your domain" or "DKIM" setting and complete it. One pass per sender, all of them green.
Part 4 — DMARC: Policy, Alignment, and Reporting
DMARC (Domain-based Message Authentication, Reporting and Conformance) is the conductor. It ties SPF and DKIM together, tells receivers what to do when mail fails, and — the underrated part — emails you reports on who's sending as your domain. It's a single TXT record at _dmarc.yourdomain.com.
4.1 Understand alignment
DMARC adds a rule SPF and DKIM don't have on their own: alignment. It's not enough to pass SPF or DKIM — the domain that passed has to match the domain in your visible "From" address. This is what stops a spammer from passing SPF using their domain while displaying yours. A message passes DMARC if it passes SPF or DKIM and that result aligns with the From domain.
What "bad" looks like: mail that technically passes SPF but for a different domain than the one shown to the recipient — common when a third-party tool sends without proper domain setup, so it fails DMARC alignment even though SPF "passed."
What to do: when you authenticate each sending tool, use its custom-domain / branded-sending option so the passing domain aligns with yours. The DMARC reports will tell you exactly which senders are misaligned.
4.2 Set a policy: none → quarantine → reject
The DMARC policy (p=) tells receivers what to do with mail that fails. p=none means "do nothing, just report" — monitoring mode. p=quarantine sends failures to spam. p=reject blocks them entirely. Reject is the strongest anti-spoofing protection, but like SPF's -all, getting there before your legitimate mail is fully authenticated will block your own email.
What "bad" looks like: no DMARC record at all (you're invisible to spoofing and Gmail/Yahoo now penalize bulk senders without it), or p=reject set on day one before you've confirmed everything passes.
What to do: publish v=DMARC1; p=none; rua=mailto:you@yourdomain.com to start. Read the reports for a few weeks, fix any legitimate senders that fail, then step up to p=quarantine, then p=reject.
4.3 Turn on reporting (the part everyone skips)
The rua= tag in your DMARC record asks receivers to email you aggregate reports — a daily roll-up of every source sending as your domain, and whether each passed or failed. This is the only way to see who's sending mail as you, including services you forgot about and spammers spoofing you.
What "bad" looks like: a DMARC record with no rua= address — you've set a policy but you're flying blind.
What to do: add rua=mailto: pointing to an inbox you'll read (the raw XML is dense — a free DMARC report reader makes it human). Use the reports to drive your move from none to reject.
Part 5 — Blacklists: Is Your Domain (or IP) Flagged?
Even with perfect authentication, mail can still be blocked if your sending IP or domain lands on a blacklist (also called a blocklist or DNSBL). These are lists of known spam sources that receiving servers check against. You can end up on one from a compromised account, a shared IP a neighbor abused, or a bad email campaign.
5.1 Check the major lists
The three that matter most: Spamhaus (the most widely used and most influential — being listed here hurts the most), SpamCop, and Barracuda. MXToolbox's blacklist checker queries dozens of these at once against your domain or mail-server IP in one click.
What "bad" looks like: a "Listed" result on Spamhaus, or listings on several lists at once — a strong signal something is compromised or misconfigured.
What to do: find your mail server's IP (your email provider can tell you, or it's in your sent-mail headers), run it through a blacklist checker, and note any "Listed" results.
5.2 Get delisted — after fixing the cause
Getting off a list is usually straightforward, but pointless if you don't fix what put you there. Each list has its own removal process, linked directly from the "Listed" result.
What "bad" looks like: requesting delisting, getting removed, then landing right back on the list a week later because the compromised account or spammy campaign is still running.
What to do: first find the cause — a hacked mailbox, a sketchy purchased list you mailed, malware on a device. Fix it. Then submit the delisting request on each list. If you're on a shared IP with a host that won't address it, that's a sign to move to a sender with better IP hygiene.
This guide gets you reading your records and spotting the obvious failures. What it can't do is read every record on your domain for you, parse the dense DMARC report XML, probe the dozen-plus DKIM selectors your various tools might use, or check your IPs against every blacklist at once and translate it all into a single prioritized to-do list.
A few things that need an actual scan of your domain:
- Whether your SPF record is quietly over the 10-lookup limit (it validates visually but fails)
- Which of your many sending tools have DKIM and which silently don't
- Whether your "passing" mail actually aligns for DMARC, or just looks like it does
- Which specific blacklists your mail-server IPs are on right now
If you'd rather see all of that laid out in plain language than chase it record by record, that's exactly what the paid check is for.
If you'd rather not spend an afternoon cross-referencing TXT records and blacklist lookups, the Email Deliverability Check — $19.99 one-time does the whole scan for you. Give it a domain name — no inbox access, no API keys, nothing to install — and it reads your public DNS for SPF (including the 10-lookup count and your all qualifier), DMARC (policy strength and whether reporting is on), DKIM (probing the common selectors), plus MX and BIMI, then checks your mail-server IPs against Spamhaus, SpamCop, and Barracuda. You get it all back in plain English — "your invoices and newsletters may be landing in spam, here's why" — with a prioritized fix list, in under 24 hours. It's a fraction of an agency retainer, with no subscription. You can run the Email Deliverability Check on your domain here and have answers today.
Deliverability rarely travels alone — if your mail is getting flagged, it's worth a look at whether your site has the same trust problems. Our guides on why visitors don't trust your site and why your link looks broken when shared cover the public-facing side of the same problem.
Rather have it done for you? The Email Deliverability Check pulls the data, runs every check above, and hands you a prioritized, plain-English report in under 24 hours — a fraction of an agency retainer, no subscription, no upsell.
FAQ
include removed when you changed tools), a new blacklist listing from a compromised account, or a recent spammy campaign that tanked your reputation. Start by checking SPF, DKIM, and DMARC — a single broken record can flip you from inbox to spam overnight.~all (softfail) while you're confirming every sending service is in your record, then tighten to -all (hardfail) once you've verified — ideally via DMARC reports — that no legitimate mail is failing. -all is the stronger anti-spoofing setting and the right end state; jumping to it too early will block your own email. Never use +all.p=none to monitor, then tighten.