Why Email Lands in Spam: SPF, DKIM and DMARC Together
Common reasons sent mail goes to spam, and how to align SPF, DKIM and DMARC together.
Almost everyone has watched a carefully written email vanish into the recipient’s spam folder instead of their inbox. Deliverability is not about whether you sentthe message—it is about whether it actually landed in the inbox. Receiving servers (Gmail, Outlook, and others) weigh whether the sending domain really authorized the message, what its reputation looks like, and whether the content resembles known spam, then route it to Inbox, Promotions, or Spam accordingly.
The single biggest factor is authentication: SPF, DKIM, and DMARC. Get all three right and you have solved roughly half of deliverability. Add reverse DNS (PTR) with solid IP reputation, plus clean content and list hygiene, and you cover the rest. This guide walks through everything in priority order and shows you how to verify each piece yourself.
SPF, DKIM and DMARC work together, not in isolation
Turning each one on individually is not enough—the key concept is alignment. DMARC considers a message a pass only when at least one of SPF or DKIM passes and that result aligns with the domain in the visible From: address.
| Mechanism | What it proves | Record location |
|---|---|---|
SPF | That the sending IP is allowed to send for this domain (checked against Return-Path) | Domain root TXT |
DKIM | That the message was not altered after sending (cryptographic signature) | selector._domainkey TXT |
DMARC | That SPF/DKIM align with the From: domain, plus the policy on failure | _dmarc TXT |
DMARC is the umbrella layer that binds SPF and DKIM together to assert “this message truly belongs to our domain.” If you enable SPF but ignore alignment, SPF can technically pass while DMARC still fails. Check your current state with SPF Lookup, DKIM Lookup, and DMARC Lookup—or see all three at once with the all-in-one Email Deliverability check.
Reverse DNS (PTR) and IP reputation
Even flawless authentication will not save a low-trust sending IP. One of the first things a receiver inspects is reverse DNS (PTR). A reverse lookup on your sending IP should return a proper hostname (e.g. mail.example.com) that resolves forward to the same IP—so-called forward-confirmed reverse DNS. A missing PTR or a generic carrier default like ip-1-2-3-4.isp.net is a penalty.
- Dedicated vs shared IP: on a shared IP, other senders’ spam drags down the whole pool’s reputation.
- Blocklists (RBL/DNSBL): periodically check whether your IP or domain is listed on Spamhaus and similar.
- Warm-up: never blast a brand-new IP/domain at full volume—ramp sending up gradually over several days.
Content and list hygiene
Reputation is ultimately decided by how recipients react. Spam complaints, non-opens, and bounces pile up and cast suspicion on the whole domain. A few hygiene basics make a large difference.
- Opt-in lists only: addresses scraped or purchased without consent are the top source of bounces and complaints.
- Remove hard bounces immediately: repeatedly mailing nonexistent addresses tanks your reputation.
- One-click unsubscribe: never hide the opt-out link—an unsubscribe is far better than a spam report.
- Content: avoid single-image emails, excessive shortened URLs, and shouty subject lines (ALL CAPS, !!!).
Priority checklist
- Check your SPF record — does it include every real sending service (mail server, SendGrid, etc.) and end in
~allor-all? - Enable DKIM signing — is the public-key TXT published under your sending tool’s selector?
- Publish DMARC — start at
p=none, collect reports, then tighten toquarantineand finallyreject. - Verify alignment — do the SPF/DKIM domains match the From: domain?
- PTR and blocklists — reverse DNS in order, not listed anywhere.
- List and content hygiene — opt-in, bounces removed, clean body.
Worked example: DMARC breaking due to SPF misalignment
Suppose shop.example.com sends marketing mail through a third-party platform. The setup looked like this:
- From:
news@shop.example.com - The platform uses its own envelope (Return-Path):
bounce@mailer-platform.net - SPF passes, but against
mailer-platform.net
Taken alone, SPF is a pass. But DMARC checks alignment: the SPF-passing domain (mailer-platform.net) does not match the From: domain (shop.example.com), so SPF alignment fails. If DKIM is also unsigned, there are zero aligned authentications—a DMARC fail. With a policy of p=reject, the message is simply rejected.
The fix: (1) have the platform DKIM-sign using a selector under shop.example.com (or a subdomain), which establishes DKIM alignment; or (2) delegate a custom Return-Path (e.g. bounce.shop.example.com) to the platform so SPF aligns. Either one alone is enough for DMARC to pass. After the change, confirm the policy with DMARC Lookup and re-run the all-in-one check to make sure all three are green at the same time.