Why your Gmail emails go to spam even though SPF passes

You check the email headers. SPF says "pass." DKIM says "pass." And yet the message landed in spam. If you send email from your own domain through Gmail or Google Workspace, this scenario is more common than most senders realize. SPF passing is necessary, but it is not sufficient. Gmail evaluates half a dozen other signals before deciding where your message belongs.

Here is what actually causes emails going to spam when SPF passes, and how to fix each one.

SPF proves less than you think

SPF (Sender Policy Framework) answers one narrow question: did this message originate from an IP address authorized by the domain in the envelope sender (the Return-Path header)? That is it. SPF does not verify the "From" address your recipients see. It does not confirm the message body is legitimate. It does not prove the sender is trustworthy.

A message can pass SPF and still be spam. SPF only confirms the sending server was allowed to use a specific envelope domain. Gmail knows this, which is why SPF alone has never been enough to guarantee inbox placement.

RFC 7208 defines SPF. Section 1 is explicit: SPF is an authorization mechanism, not an authentication mechanism for the visible sender identity. That distinction matters.

DMARC alignment: the gap most senders miss

This is the most common reason for emails going to spam when SPF passes. DMARC (Domain-based Message Authentication, Reporting, and Conformance) adds a critical layer: alignment. DMARC requires that at least one of two checks both passes AND aligns with the domain in the visible "From" header.

• SPF alignment means the domain in the Return-Path matches the domain in the From header.
• DKIM alignment means the domain in the DKIM signature (the d= tag) matches the domain in the From header.

Here is where things break. Many third-party email services set their own domain in the Return-Path when sending on your behalf. Your SPF record authorizes their servers, so SPF passes. But the Return-Path domain is bounce.thirdparty.com, not yourdomain.com. Since the From header shows yourdomain.com, SPF passes but fails DMARC alignment.

Without DKIM also passing and aligning, DMARC reports a failure. Gmail's Email Sender Guidelines now require DMARC for any sender pushing more than 5,000 messages per day. Even below that threshold, a DMARC failure makes spam classification far more likely.

The fix: Check your DMARC alignment, not just your SPF result. If your email provider sets its own Return-Path, you need DKIM configured with your domain in the d= tag to satisfy DMARC through DKIM alignment instead.

Missing or broken DKIM

DKIM (DomainKeys Identified Mail) cryptographically signs your outbound messages. The receiving server verifies the signature against a public key published in your DNS. When DKIM is missing entirely, Gmail loses one of its strongest authentication signals.

Common DKIM failures:

• No DKIM record published. Your email provider gave you a CNAME or TXT record to add to DNS. If you never added it, DKIM silently fails on every message.
• Selector mismatch. DKIM records live at selector._domainkey.yourdomain.com. If the selector in the email header does not match a published DNS record, verification fails.
• Key rotation without DNS update. Some providers rotate DKIM keys periodically. If the old key is removed and the new one is not published in your DNS, every message fails DKIM until the record is updated.
• Body modification in transit. Mailing list software, footer-injection tools, and some security gateways alter the message body after signing. This breaks the DKIM signature.

The fix: Confirm that a valid DKIM record exists for every selector your email provider uses. Send a test message and inspect the headers to verify dkim=pass with the correct d= domain.

Domain reputation problems

Gmail maintains a per-domain sender reputation score. A new domain with no sending history starts with a neutral reputation. If early sends generate spam complaints, bounces, or spam trap hits, reputation drops fast. Once it drops, even perfectly authenticated mail goes to spam.

Factors that tank domain reputation:

• High complaint rate. Gmail's threshold is 0.3%. If more than 3 out of every 1,000 recipients mark your mail as spam, deliverability degrades. Below 0.1% is the target.
• Sending to stale lists. Old email addresses convert to spam traps. Hitting even a few poisons your reputation.
• Sudden volume spikes. A domain that sends 50 emails per day and then blasts 5,000 in one day triggers volume-based filters. Gmail expects gradual ramp-up.
• Shared IP reputation. If you send through a shared email service, other senders on the same IP range affect your deliverability. Their spam becomes your problem.

The fix: Check Google Postmaster Tools for your domain's reputation. If it shows "Low" or "Bad," reduce volume, clean your list, and rebuild gradually. Domain reputation recovers, but slowly.

Content and engagement signals

Gmail uses machine learning to classify messages beyond authentication. Even fully authenticated mail from a reputable domain can land in spam if the content triggers classification rules.

Signals Gmail evaluates:

• Low engagement. If recipients consistently ignore, delete, or mark your messages as spam, Gmail learns that your mail is unwanted for that audience.
• Spam-like content patterns. Excessive links, misleading subject lines, image-heavy messages with minimal text, and certain phrases associated with spam all influence classification.
• Missing unsubscribe header. Google requires a one-click unsubscribe mechanism (RFC 8058 List-Unsubscribe-Post header) for bulk senders. Missing it increases spam likelihood.
• Sending to unengaged segments. A list where 80% of recipients never open is a signal to Gmail that the sender is not providing value.

The fix: Segment your lists. Stop sending to recipients who have not opened in 90 days. Include a working one-click unsubscribe header. Test your content with a seed list before large sends.

Reverse DNS and IP configuration

Gmail checks whether the sending IP address has a valid PTR (reverse DNS) record. If the IP resolves to a hostname that does not match the sending domain or service, Gmail flags the configuration as suspicious.

This primarily affects senders running their own mail servers. If you use a hosted email provider, they handle PTR records for their infrastructure. But if you send from a VPS, a dedicated server, or an on-premises mail gateway, a missing or mismatched PTR record can cause spam placement even with SPF and DKIM fully passing.

The fix: Verify that your sending IP has a PTR record and that the hostname it resolves to matches the HELO/EHLO identity your mail server presents.

How to diagnose the real problem

When emails are going to spam despite SPF passing, work through this checklist:

1. Pull the full headers from a message that landed in spam. Look at the Authentication-Results header for SPF, DKIM, and DMARC verdicts.
2. Check DMARC alignment. A line like dmarc=fail (p=none dis=none) confirms the alignment problem. Note the policy: p=none means DMARC is monitoring only, not enforcing. Gmail still uses the failure as a spam signal.
3. Verify DKIM. Look for dkim=pass with a d= value matching your From domain. If DKIM is absent or failing, that is your primary issue.
4. Check domain reputation in Google Postmaster Tools.
5. Review your DMARC reports. Aggregate reports (sent to the rua= address in your DMARC record) show which sources pass and fail alignment across all your mail streams.

Paste the raw headers into the AcuityScan Email Header Analyzer to decode the authentication chain without reading RFC syntax manually. If you need to build or fix your DMARC record, the DMARC Record Generator walks through each tag and produces a valid TXT record.

For a broader view of your domain's email authentication posture, run a full scan at acuityscan.com. The email module validates SPF syntax, checks DMARC enforcement and alignment policy, probes 16 common DKIM selectors, and scans your domain against 77 verified active email blacklists.

TL;DR

• SPF passing only means the sending IP was authorized by the envelope domain. It does not guarantee inbox placement.
• The most common cause of spam placement despite passing SPF is failed DMARC alignment, where the Return-Path domain does not match the From domain, and DKIM is missing or misaligned.
• Missing DKIM, poor domain reputation, spam-like content, and bad PTR records all cause spam placement independently of SPF results.
• Check the full Authentication-Results header, not just the SPF line. DMARC alignment is where most problems hide.
• Fix DKIM first, then DMARC policy, then work on reputation and content signals.