Email Deliverability Basics: Why Messages Land in Spam and How to Fix It
Learn why your email goes to spam and how SPF, DKIM, DMARC, PTR records, and reputation checks fix it — verify everything with dnslab tools.
By the DNSLab team Updated July 9, 2026
Quick answer
Email goes to spam when receiving servers doubt that a message is legitimate, usually because of missing or failing authentication (SPF, DKIM, DMARC), a poor sender reputation, or spam-like content. To land in the inbox, authenticate your domain correctly, send from a warmed-up IP with low complaint rates, keep your recipient lists clean, and avoid misleading subject lines and suspicious link patterns.
What deliverability actually means
Deliverability is the share of your legitimate mail that reaches the inbox instead of the spam folder or a silent bounce. It is not the same as "delivered": a receiving server can accept a message with a 250 response and then quietly file it under spam. Two forces decide the outcome. First, authentication — does the receiver trust that the message really came from your domain? Second, reputation — does the receiver's history of your sending IP and domain look like a legitimate correspondent or a spammer? Most spam-folder problems trace back to one of these two, and both are inspectable with public DNS and header data.
Why messages get filtered to spam
The common causes are surprisingly mechanical. A missing or wrong SPF record means the receiver cannot confirm your sending server is authorized. No DKIM signature means the message body and key headers are unsigned, so tampering cannot be ruled out. No DMARC policy means Gmail and Yahoo have no instruction on what to do when SPF or DKIM fail — and since 2024 both require DMARC for bulk senders. Beyond authentication, a listed IP on a blacklist, a mismatched reverse DNS (PTR) record, a brand-new domain with no sending history, or content that trips spam heuristics (link shorteners, spammy phrases, image-only mail) all push you toward the spam folder.
The three records that build trust: SPF, DKIM, DMARC
SPF is a TXT record listing which servers may send for your domain, for example "v=spf1 include:_spf.google.com ~all". DKIM adds a cryptographic signature: the sending server signs the message with a private key, and receivers fetch the matching public key from a DNS TXT record at selector._domainkey.yourdomain.com. DMARC ties them together with a policy — "v=DMARC1; p=none; rua=mailto:you@domain" tells receivers how to handle failures and where to send aggregate reports. DMARC also enforces "alignment": the domain in the visible From address must match the SPF or DKIM domain. Use the dnslab SPF and DMARC lookup tools to confirm each record parses correctly.
Step by step: audit and fix your setup
Start by looking up your domain's SPF record with the dnslab SPF tool and verify it lists every service that sends on your behalf, ending in ~all or -all with no more than ten DNS lookups. Next, confirm a DKIM public key exists at your selector and that outgoing mail is actually signed — check a received message's Authentication-Results header for "dkim=pass". Then publish a DMARC record, beginning with p=none so you monitor without blocking, and read the aggregate reports before tightening to quarantine or reject. Finally verify your sending IP has a valid PTR record and matching forward DNS, since many providers reject or downgrade mail from IPs with no reverse DNS.
Reputation, blacklists, and reverse DNS
Even perfect authentication will not save a sender with a poor reputation. Receivers score your domain and IP on volume, complaint rates, spam-trap hits, and blacklist status. Run your sending IP and domain through the dnslab Blacklist tool to check major DNSBLs such as Spamhaus, and if you appear, fix the underlying cause before requesting delisting — delisting a still-compromised server is pointless. Reverse DNS matters too: your IP's PTR record should resolve to a hostname that forward-resolves back to the same IP, ideally on your own domain. Use the dnslab WHOIS and DNS lookup tools to confirm ownership details and record consistency across your infrastructure.
Common mistakes that silently hurt you
Publishing two separate SPF records — receivers treat this as a permanent error and SPF fails entirely; merge them into one. Exceeding the ten-lookup SPF limit with too many include statements causes the same failure. Using p=reject in DMARC before confirming all your legitimate senders pass alignment will block your own newsletters and transactional mail. Forgetting to sign mail from a new marketing platform breaks DKIM alignment even when the platform "supports" DKIM. Sending from a subdomain that inherits no DMARC policy. And relying on a shared IP whose reputation you cannot control. Each of these is invisible until deliverability drops.
How to verify the fix worked
Do not guess — measure. Send a test message to an address at Gmail and open the headers (Show original) to read Authentication-Results; you want spf=pass, dkim=pass, and dmarc=pass all aligned to your From domain. Re-run the dnslab SPF, DMARC, and Blacklist tools to confirm the records resolve as published and no listing remains. Watch your DMARC aggregate reports over the following week for any unexpected sources failing authentication, which reveals forgotten senders or spoofing. Once monitoring is clean, tighten your DMARC policy from p=none to p=quarantine, then p=reject, checking reports at each step.
Frequently asked questions
- Why does my email go to spam even with SPF, DKIM, and DMARC all passing?
- Authentication proves who you are, not whether receivers trust you. If your sending IP or domain has a weak reputation, appears on a blacklist, lacks reverse DNS, or the message content trips spam filters, mail still lands in spam. Check your IP and domain with the dnslab Blacklist tool and review complaint rates.
- Do I really need DMARC, or are SPF and DKIM enough?
- Since February 2024, Gmail and Yahoo require a valid DMARC record for bulk senders, so it is effectively mandatory for anyone sending volume. DMARC also enforces alignment and gives you aggregate reports that reveal who is sending as your domain. Start with p=none to monitor, then tighten once your legitimate mail passes.
- How long after fixing DNS records before deliverability improves?
- DNS changes propagate within your TTL, often minutes to a few hours, so SPF, DKIM, and DMARC lookups reflect fixes quickly. Reputation recovery is slower — days to weeks — because receivers need a fresh history of authenticated, low-complaint mail. Blacklist delisting can be near-instant once you fix the root cause and request removal.