Why Your Emails Go to Spam in Gmail, and How to Diagnose It

Gmail sends mail to spam when it cannot confirm who sent it, or when it can and does not trust that sender. Diagnose in that order: open the message's full header with Show original, confirm SPF, DKIM and DMARC pass and align with your From domain, then check your reputation and spam rate in Postmaster Tools.

Most guides give you a list of twenty possible causes and leave you to guess. This one is a diagnosis flow. You send one test message, look at three specific places, and each place either clears a cause or names it. For the deeper mechanics of reading a raw header line by line, see the companion post on how to read email headers.

Step 0: Confirm it is actually in spam, not rejected

If the message bounced, it is not a spam folder problem. Gmail rejected it at the door, and the rejection text usually tells you why.

This distinction saves hours. A rejected message never reaches Spam or the inbox; your sending platform logs a bounce instead. Gmail's published SMTP error reference includes messages such as:

Code	Gmail's text (abridged)	What it means
550 5.7.26	"This email has been blocked because the sender is unauthenticated. Gmail requires all senders to authenticate with either SPF or DKIM."	No passing authentication
550 5.7.26	"Unauthenticated email from domain-name is not accepted due to domain's DMARC policy."	DMARC failed and the domain's policy says reject
550 5.7.1	"This message is likely unsolicited email. To reduce the amount of spam sent to Gmail, this message has been blocked."	Reputation or content
550 5.7.25	"...the sending IP address doesn't have a PTR record..."	Missing or mismatched reverse DNS
421 4.7.28	"Gmail has detected an unusual rate of unsolicited email originating from your IP address"	Temporary, volume- and reputation-driven

If you are seeing these, the fix starts with the code, not the folder. Our page on 550 5.7.1 walks through the most common one. If the problem is bounces from dead mailboxes rather than policy blocks, that is a list problem, covered in why cold emails bounce.

Google also says that since November 2025 it has been "ramping up its enforcement on non-compliant traffic", with "temporary and permanent rejections" for mail that fails its requirements (sender guidelines FAQ). Mail that used to land in spam can now bounce instead.

Step 1: Send a test to a Gmail account you control

Use a personal Gmail address that has never interacted with you, sent through your real sending path. Testing from your laptop's mail client when campaigns go out through a platform tests the wrong thing.

Send exactly what your recipients get: same platform, same From address, same template. Then find it in that account's inbox or Spam folder.

One test is a sample of one, and Gmail filters per recipient as well as per sender, so a test inbox landing is a necessary result, not proof. But a test that lands in Spam is very informative, because a fresh account has no personal history with you to blame.

Step 2: Read the banner Gmail puts on the message

When a message is in Spam, Gmail shows a short warning explaining its reason. Read it before touching DNS, because it often names the category outright.

Gmail's help page on spam warnings lists the reasons recipients may see. The ones a legitimate sender can act on are:

• Messages from an unconfirmed sender: "Gmail can't confirm who sent you the email." This is an authentication failure. Go to Step 3.
• Spoofed email addresses: the address "looks very similar to the email address of a known sender". Common when people send from lookalike domains.
• You tried to unsubscribe from this sender: Gmail says that if someone sends after you unsubscribe, "their emails go directly to Spam". If unsubscribes are not honoured fast, this hits every recipient who tried.
• Messages content is empty: an empty body or subject. Usually a broken template or merge field.
• Emails you sent to Spam: that recipient reported you before.

If there is no specific banner and the message is simply in Spam, the cause is most often reputation (Step 5) rather than a broken setup.

Step 3: Open Show original and check authentication

Click More, then Show original, and look at the SPF, DKIM and DMARC results. All three should say PASS for a bulk sender. Anything else is your first fix.

Google's instructions are: open the message, next to Reply click More, then Show original; the full header opens in a new window, with a Copy to clipboard button. Above the raw text Gmail shows a short summary that includes SPF, DKIM and DMARC verdicts. The full detail is in the Authentication-Results line Gmail added. A real one, published by Valimail from a message received at Gmail (source), looks like this:

Authentication-Results: mx.google.com;
       dkim=pass header.i=@valimail.com header.s=google2048 header.b=Z8L6tjHb;
       spf=pass (google.com: domain of [redacted]@valimail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=[redacted]@valimail.com;
       dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=valimail.com

What each failure usually means:

Result	Likely cause	Where to fix
spf=fail or softfail	Your platform's servers are not in your SPF record	Add the platform's include to your SPF record
spf=permerror	SPF record is broken, often too many DNS lookups	Count lookups per include and flatten or remove
dkim=none	Message was not signed with your domain	Enable custom DKIM in your sending platform
dkim=fail	Signature did not verify, or the public key in DNS is wrong or missing	Re-publish the key at the selector named in s=
dmarc=fail with SPF and DKIM passing	Neither passing check is aligned with your From domain	See below
dmarc=none	No DMARC record	Publish one; bulk senders must

The alignment trap

DMARC passes only when SPF or DKIM passes for the same organisational domain as your visible From address. This is the failure that catches most people, because SPF and DKIM both say pass.

Look at the header above. The From domain (header.from=valimail.com) matches the DKIM signing domain (header.i=@valimail.com) and the SPF domain (smtp.mailfrom=...@valimail.com). That is alignment.

Now imagine a platform that signs with d=platform-mail.net and bounces to bounces.platform-mail.net, while your From says you@yourcompany.com. SPF passes (for the platform's domain), DKIM passes (for the platform's domain), and DMARC fails, because nothing that passed belongs to you. Google's sender guidelines require bulk senders' From domain to be aligned with either the SPF or the DKIM domain. The fix is almost always to set up custom DKIM for your own domain in the platform.

The current DMARC specification, RFC 9989, published in May 2026, replaced RFC 7489, and either aligned SPF or aligned DKIM is enough to pass.

Step 4: Check the infrastructure basics Gmail requires

Gmail requires every sender to have valid forward and reverse DNS and to send over TLS. If you use a mainstream ESP these are handled for you; if you run your own server, check them.

From the same Show original page:

• TLS: the Received line Gmail added when it accepted the message records the protocol. ESMTPS means the session was encrypted (RFC 3848 defines the keyword); plain SMTP or ESMTP means it was not, and Google lists TLS as a requirement for all senders.
• Reverse DNS: take the sending IP from the spf= comment or the first Received line Gmail added, and run dig -x on it. It should return a hostname, and that hostname should resolve back to the same IP. For the header above, on 1 October 2026, dig -x 209.85.220.41 returned mail-sor-f41.google.com.
• Message format: Google asks that every message include a valid Message-ID and that single-instance headers such as From and Subject appear only once.

You can check SPF, DKIM, DMARC and blocklist status for your domain in one pass with the deliverability audit.

Step 5: If authentication is clean, it is reputation

When everything passes and mail still lands in Spam, Gmail does not trust your domain or IP based on how its users have treated your mail. No DNS change fixes that. Only what you send, and to whom, does.

Open Google Postmaster Tools for your domain and check the user-reported spam rate. Google's guidance is to "keep spam rates reported in Postmaster Tools below 0.10% and avoid ever reaching a spam rate of 0.30% or higher". Its FAQ adds that bulk senders above 0.3% are ineligible for mitigation until they have stayed below it for seven consecutive days. If you have not used the dashboards before, our Postmaster Tools guide explains each one.

Reputation problems trace back to a short list of causes:

Symptom	Probable cause
Spam rate climbing after a new list or campaign	Recipients did not expect your mail
Sudden drop after a volume jump	Too much, too fast from a domain with little history
Problems only on a shared IP	Another sender on the IP; Google notes that "the activity of any senders using a shared IP address affects the reputation of all senders for that shared IP"
Gradual decline over months	Mailing people who stopped engaging long ago
Marketing drags transactional mail into Spam	Mixed streams on one domain or IP

Google's guidelines speak directly to the last two: "Don't mix different types of content in the same message", and if you send from more than one IP, "use a different IP for each message type". Separating receipts from promotions, ideally on a subdomain, stops one from poisoning the other. If reputation has already taken damage, a reputation recovery plan is the next read.

Step 6: Then, and only then, look at content

Content is the last thing to check, not the first. Senders who rewrite subject lines while DMARC is failing are fixing the wrong layer.

That said, Google does name a few content practices in its guidelines. It warns: "Don't use HTML and CSS to hide content in your messages. Hiding content might cause messages to be marked as spam." Its spam warnings also flag empty messages, as covered in Step 2. Bulk marketing mail must also support one-click unsubscribe with a clearly visible link, which matters here because a recipient who cannot leave easily reports you as spam instead.

A worked diagnosis, start to finish

Here is the flow applied to a typical case, written as the decisions you make:

1. Campaign recipients say mail is in Spam. The platform logs no bounces, so it is placement, not rejection.
2. A test to a fresh Gmail account lands in Spam with the banner "Gmail can't confirm who sent you the email."
3. Show original reads spf=pass, dkim=pass header.i=@platform-mail.net, dmarc=fail header.from=yourcompany.com.
4. Diagnosis: authentication passes, alignment does not. The platform signs with its own domain.
5. Fix: add the platform's custom DKIM records for yourcompany.com, wait for DNS, resend the test.
6. Show original now reads dkim=pass header.i=@yourcompany.com and dmarc=pass. If mail still lands in Spam, move to Postmaster Tools and look at the spam rate.

Steps 3 to 6 take about fifteen minutes once you know where to look. What takes weeks is the reputation repair that follows if you skip the diagnosis and keep sending.

The short version

• A bounce is a rejection; read the code. A message in Spam is a placement decision; read the header.
• Read Gmail's banner first. "Can't confirm who sent" means authentication.
• In Show original, SPF, DKIM and DMARC should all pass, and DMARC needs an aligned domain, not just two passes.
• If authentication is clean, the cause is reputation. Check spam rate in Postmaster Tools and stay well under 0.10%.
• Fix content last.

To check your SPF, DKIM, DMARC and blocklist status in one go, run the free deliverability audit on your sending domain.