TL;DR — Legitimate mail lands in spam for a small number of fixable reasons, almost always in this order of likelihood: broken or misaligned authentication (SPF/DKIM/DMARC), a sending IP or domain with poor reputation, and content or sending patterns that look bulk-y. This guide is the diagnostic checklist we'd run — what to check, in what order, and how to read the one tool that answers most of it (Gmail's "Show original"). It's written for people sending real one-to-one mail from their own domain, not marketers blasting lists.
First, the 30-second diagnosis
Send a message from your domain to a Gmail account you control, open it, and click ⋯ → Show original. You get a verdict table:
SPF: PASS with domain yourdomain.com
DKIM: PASS with domain yourdomain.com
DMARC: PASS
Three PASSes with your domain on the SPF and DKIM lines is the all-clear — if you have that and mail still spam-folders, skip to the reputation and content sections. Anything less, and you've found your problem; the rest of this guide is how to fix each line.
Cause 1: authentication (the majority of cases)
This is where most "good mail in spam" actually originates, and it's the most fixable.
- SPF fails or is missing. The receiving server couldn't confirm your sending server is authorized. Usual culprits: no SPF record, multiple SPF records (an automatic permanent failure), or blowing the 10-lookup limit. One merged record ending in
-all. - DKIM fails or is absent. No signature, a mangled key in DNS, or content altered after signing. The DKIM guide covers the silent failure modes.
- The killer: passing but not aligned. This is the subtle one. Your mail can show
SPF: PASSandDKIM: PASSand still fail DMARC — because the domain that passed doesn't match the From address people see. A newsletter tool sending "as you" but signing with its domain produces valid authentication that does nothing for your domain's reputation. DMARC alignment is what ties it together, and misalignment is the most common reason a technically-authenticated message still gets filtered. Fix: make every tool that sends as your domain sign as your domain (their CNAME/DKIM setup flow).
If Show original doesn't say your domain on all three lines, stop here and fix it — nothing downstream matters until this is clean.
Cause 2: reputation (the invisible one)
Once authentication is clean, receivers judge the sending IP and the sending domain by their history. This is where the choice of how you send matters more than anything you can put in a DNS record.
- Shared-IP pools. Most budget and mid-range hosts send your mail from IPs shared with other customers. You inherit their behavior — one spammer in the pool, and everyone's mail gets scrutinized. A host that actively polices its pool (rate-limiting new senders, monitoring blocklists, suppressing bounces) protects you; one that doesn't, can't. It's a fair question to ask a provider directly, and a vague answer is itself an answer.
- Blocklists (RBLs). Dozens exist; a handful (Spamhaus above all) actually influence Gmail and Outlook. A listing of your sending IP — or your domain — can spam-folder or outright reject your mail until it clears, which can take days. For hosted users this is the provider's job to monitor; you can spot-check their sending IP at multirbl.valli.org.
- A cold or brand-new IP/domain. Reputation is earned by consistent, un-complained-about sending. A brand-new domain that suddenly sends is treated cautiously by design. This resolves itself with normal use; it's only a real problem when combined with volume spikes (below).
- New TLDs. Very new or very cheap top-level domains carry a worse baseline reputation, so mail from them faces extra scrutiny. A boring domain on a mainstream TLD is the low-friction choice.
Cause 3: content and sending patterns
With clean auth and decent reputation, content is rarely the deciding factor for genuine one-to-one mail — but a few things still tip filters:
- Volume spikes from a quiet domain. A domain that sends five messages a day suddenly sending five hundred looks like a compromise, to filters and to good providers' own throttles. Consistency beats bursts.
- Bulk-mail fingerprints in personal mail. A single tracking pixel, a link-shortener URL, an image-only body with almost no text, or a mismatch between the visible link text and its destination — each nudges the spam score. For normal correspondence, just don't.
- Mailing dead addresses. Repeatedly sending to addresses that hard-bounced is one of the fastest ways to wreck a sending reputation; serious senders suppress bounced addresses automatically. (If you're sending any kind of list mail, this is the single highest-leverage habit.)
- Missing unsubscribe / bulk headers — only relevant if you actually send bulk mail, in which case Gmail and Yahoo now require one-click unsubscribe and a DMARC record from bulk senders.
The diagnostic order, condensed
- Show original on a test to Gmail → are SPF, DKIM, DMARC all PASS with your domain? If not → fix authentication first, full stop.
- Check the sending IP and domain against Spamhaus / multirbl → listed? Request delisting (or lean on your provider to).
- Look at your sending pattern → any recent volume spike, new domain, or bounce-hammering? Normalize it.
- Read the content → tracking pixels, shorteners, image-only bodies, link mismatches? Remove them.
- Still filtered? → the receiver may weight the recipient's prior behavior (did they mark earlier mail as spam?). Ask a recipient to mark one message "Not spam"; that trains their filter for your domain.
Ninety percent of real cases resolve at step 1.
What you can't fix from your side
Worth stating plainly so you don't chase it: you cannot force a specific receiver to inbox you, individual recipients' filters learn from their behavior, and no DNS record or header guarantees placement. What you can do is remove every reason to filter you — clean aligned authentication, a sending IP whose reputation someone actively defends, and mail that looks like the human correspondence it is. Do that, and inbox placement follows for the mail that matters.
The hosted-provider angle
Most of causes 1 and 2 are exactly what you're paying a mail host to handle: authentication set up correctly and rotated, sending IPs monitored and kept off blocklists, new senders warmed and bounces suppressed. When you evaluate a provider, "how do you protect deliverability?" is the question that separates the ones doing this work from the ones hoping. (It's the work we consider the actual product — a real answer names IP monitoring, warmup limits, and bounce handling, not just "we use good servers.")
The mechanics behind each authentication line: SPF · DKIM · DMARC · MX records. The full picture: Email on Your Own Domain: The Complete 2026 Guide.