Skip to main content
Relaymetry

SPF, DKIM, and DMARC pass but Gmail sends email to spam

SPF, DKIM, and DMARC passing means Gmail can authenticate the message. It does not mean Gmail trusts the sender enough for inbox placement. If authentication passes but Gmail sends mail to spam, check public blacklist status, domain age, sending volume, complaint risk, content, recipient engagement, and Google Postmaster Tools.

Quick answer

SPF, DKIM, and DMARC passing means Gmail can authenticate the message. It does not mean Gmail trusts the sender enough for inbox placement. If authentication passes but Gmail sends mail to spam, check public blacklist status, domain age, sending volume, complaint risk, content, recipient engagement, and Google Postmaster Tools.

Authentication is necessary, not sufficient

SPF, DKIM, and DMARC answer a narrow but important question: is this message authorized for the domain it claims to use? Gmail also has to answer a different question: is this message wanted and safe for this recipient?

Those two questions overlap, but they are not the same. Authentication failure can cause rejection or spam placement. Authentication success removes that failure, but Gmail can still classify a message as spam because of reputation, sudden sending behavior, user complaints, content patterns, or recipient engagement.

This is why "perfect SPF/DKIM/DMARC" can feel confusing. The technical baseline is clean, but the delivery outcome is still bad.

Check whether DMARC really passes for the From domain

Before moving on, confirm that DMARC passes for the visible From domain, not just that SPF and DKIM each say "pass" somewhere in the header.

SPF can pass for a bounce-path domain. DKIM can pass for a signing domain owned by the ESP. DMARC only passes if SPF or DKIM aligns with the visible From domain. If alignment fails, Gmail may still treat the message as unauthenticated for the domain users see.

Use the DMARC checker to inspect the public policy, then inspect a real Gmail header to confirm the actual message result. DNS tells you what should happen. Headers tell you what happened to a specific message.

Check public blacklist status, but do not stop there

If your sending IP or domain is listed on a public blocklist, fix that first. A listing can explain spam placement or rejection at some receivers.

If public blacklist checks pass, that is good evidence, but not a guarantee. Gmail has its own internal reputation systems. A sender can be absent from public DNSBLs and still have weak Gmail reputation.

The right conclusion from a clean blacklist check is not "Gmail is wrong." The right conclusion is "public list reputation is not the obvious problem; continue with Gmail-specific evidence."

Check domain age and sending history

New domains and quiet domains often lack enough positive history. If you only just started using the domain, Gmail may not have a stable model of your sending behavior.

Low-volume senders can also struggle because there is not much engagement history. A sudden campaign from a domain that used to send almost nothing can look riskier than the same volume from a domain with a long, consistent history.

If the issue began after a launch, migration, new ESP, IP change, or large campaign, treat the timing as evidence. Passing authentication after the change does not erase reputation effects from the change.

Check volume changes

Sudden volume changes are a common cause of spam placement. Gmail does not only evaluate the message in isolation. It also sees whether sender behavior changed quickly.

Examples:

  • A new product launches and sends to every user at once.
  • A marketing team imports an old list.
  • A domain moves from personal replies to cold outreach.
  • A sales team starts using a new automation tool.
  • A migration changes the outbound IP or DKIM domain.

If volume changed, slow the ramp and separate streams where possible. Transactional mail, lifecycle mail, newsletters, and cold outreach should not all share the same risk profile.

Authentication does not make unsafe-looking content safe. Gmail can still react to suspicious links, URL shorteners, misleading subjects, attachment patterns, aggressive sales language, or content that recipients frequently ignore or mark as spam.

Do not start with random word swaps. First separate technical health from content risk. If Relaymetry reports a broken SPF, DKIM, or DMARC setup, fix that before rewriting copy. If the technical baseline is clean, then review content and engagement evidence.

Practical checks:

  • Are links using the same domain users expect?
  • Did a new tracking domain appear?
  • Did the signature recently gain a link, banner, or attachment?
  • Are recipients expecting this message?
  • Is the list opt-in and recently engaged?
  • Are bounces and complaints controlled?

Check recipient engagement

Gmail can weigh how recipients interact with mail from a sender. If recipients ignore, delete, report, or rarely reply, authentication alone will not create trust.

This is uncomfortable because it is not visible from DNS. A domain health checker can tell you whether the public technical setup is broken. It cannot prove whether recipients want the mail.

If the messages are legitimate but low-engagement, focus on list quality, segmentation, frequency, and recipient expectation. Do not keep increasing volume while spam placement is unresolved.

Use Google Postmaster Tools where possible

Google Postmaster Tools can show Gmail-specific signals that public DNS cannot expose, such as domain reputation and spam-rate indicators when enough volume exists. It is not a replacement for DNS checks; it is the Gmail-specific evidence layer after DNS is clean.

Relaymetry and Postmaster Tools answer different questions. Relaymetry checks the public technical baseline quickly, without signup. Postmaster Tools helps you inspect Gmail's view after you verify domain ownership and have enough traffic.

Use both when the problem is persistent.

What to do next

  1. Run a full public technical check.
  2. Confirm SPF, DKIM, and DMARC alignment in a real Gmail header.
  3. Check public blacklist status.
  4. Check whether the domain, IP, ESP, or volume changed recently.
  5. Review Google Postmaster Tools if available.
  6. Review content, links, list quality, and engagement.
  7. Send smaller controlled tests instead of repeating the same blast.

What this does not prove

A clean Relaymetry report does not prove Gmail will place every message in the inbox. It proves that the public technical signals Relaymetry can inspect are not obviously broken.

That distinction matters. It prevents false fixes. If public authentication is broken, fix it. If public authentication is clean, stop changing DNS randomly and move to the evidence Gmail actually uses for reputation and classification.

FAQ

Can Gmail spam-folder mail even when DMARC passes?

Yes. DMARC passing proves domain authentication and alignment, not recipient-level inbox placement.

Does a clean blacklist check mean Gmail should trust me?

No. Public blocklists are one signal. Gmail also uses private reputation, engagement, complaint, and content systems.

Is this a DNS problem?

Maybe. If SPF, DKIM, DMARC, MX, blacklist, or TLS checks fail, fix the technical problem first. If they pass, the issue is probably outside public DNS.

Should I change from ~all to -all?

Do not treat SPF hardfail as a spam-folder cure. It can be appropriate after you know every real sender is authorized, but it will not create reputation by itself.

Why did this start after switching ESPs?

The new ESP may use different IPs, DKIM domains, bounce domains, tracking links, and sending patterns. Even if DNS is now correct, Gmail may need consistent positive history for the new path.

Frequently asked questions

Can Gmail spam-folder mail even when DMARC passes?

Yes. DMARC passing proves domain authentication and alignment, not recipient-level inbox placement.

Does a clean blacklist check mean Gmail should trust me?

No. Public blocklists are one signal. Gmail also uses private reputation, engagement, complaint, and content systems.

Is this a DNS problem?

Maybe. If SPF, DKIM, DMARC, MX, blacklist, or TLS checks fail, fix the technical problem first. If they pass, the issue is probably outside public DNS.

Should I change from `~all` to `-all`?

Do not treat SPF hardfail as a spam-folder cure. It can be appropriate after you know every real sender is authorized, but it will not create reputation by itself.

Why did this start after switching ESPs?

The new ESP may use different IPs, DKIM domains, bounce domains, tracking links, and sending patterns. Even if DNS is now correct, Gmail may need consistent positive history for the new path.

Other Gmail issues

References