How do I get my Gmail inbox back to normal?

Check the Google Workspace Status Dashboard first if Gmail itself looks broken or unreachable, because Google reports outages and downtime there. If mail is arriving but landing in the wrong folder, that is a placement question instead, so keep the affected message and investigate the sending path. Do not change sender settings for what turns out to be an outage.

How do I change emails from spam to inbox?

If you are the recipient, open the message in Spam and mark it as not spam with Gmail's own control, which moves it and trains your own mailbox. If you are the sender, there is no switch to flip: you have to find and fix whatever failed on the sending path. Keep the original message either way, because its headers are the only hard evidence you have.

Can a public domain check prove Gmail will place messages in the Inbox?

No, because a domain check reads public DNS and nothing else. It cannot see your production sending path, Gmail's private decision, or what happens to your next message. It is a good way to spot a missing or broken record, not a placement forecast.

Back to Learning Center Deliverability

Why emails go to spam instead of inbox Gmail

By Samuel ChenardAugust 13, 20268 min read

Ask AI to explain

In brief

Why emails go to spam instead of inbox Gmail: the Spam folder alone cannot identify the cause. Use message and sender evidence to investigate.

A Gmail message in Spam instead of Inbox does not, by itself, identify why Gmail made that placement decision. The useful answer comes from evidence tied to the affected message and sending path, not from the folder alone. Separate a one-message placement issue from a broader sending problem, retain the message evidence, and check whether Google reports a service outage before treating the event as a sender-side fault.

At a glance

Quick takeaways

A message in Gmail Spam is evidence of placement, not evidence of one specific technical cause.
The same visible symptom can require different evidence for a recipient-side issue and a sender-side issue.
A single public DNS result cannot prove the authentication state of the production message that reached Gmail.
A delivered message's headers can preserve evidence that a public record lookup cannot show.
Google directs users with product-access problems to the Google Workspace Status Dashboard for outage and downtime information.
Broader email deliverability work requires evidence from the real sending path.

Why the Spam folder does not explain the cause

The Gmail Spam folder tells you where a message was placed. It does not expose a complete, universal explanation for that placement. Treat the folder location as the beginning of an investigation.

The first decision is whether the observation concerns a recipient's mailbox or mail sent by an organization. A recipient who sees one wanted message in Spam has a mailbox-level question. A sender who sees messages from a production domain reach Spam has a sending-path question. Those are different problems, and neither should be reduced to an assumption based only on the Spam label.

This distinction matters because the available evidence changes with the question. A sender can retain the message, inspect the sending configuration, and compare results across recipients or campaigns. A recipient may only have the message and Gmail's mailbox controls. The evidence must match the claim you want to make.

Use this rule:

Do not name a cause for Gmail Spam placement until you can connect a specific message, its sending path, and the evidence available for that path.

That is an operational inference, not a published Gmail classification rule. It prevents a common error: treating a visible outcome as proof that one particular record, service, or message property caused it.

For broader context on the evidence that affects inbox-placement investigations, see the email deliverability guide.

Decision flow for separating a Gmail Spam observation from the evidence needed to investigate the affected message or sending path — Source: Palisade.

When the answer changes

The right next action changes with the evidence you have.

If you are a Gmail recipient and the issue appears to be access to Gmail or another Google product, first check the Google Workspace Status Dashboard guidance for reported outages and downtime. An outage check can help distinguish a product-access issue from a message-placement investigation. It does not explain why an individual email appeared in Spam.

If you are responsible for sending the message, preserve the exact message and identify the production path that produced it. Do not substitute a different test email, a marketing preview, or a public DNS lookup for the message that was actually placed in Spam. Those checks can still be useful, but they answer narrower questions.

If the issue affects a newsletter, use the evidence from that campaign and compare it with the broader discussion in why newsletters go to spam. If it concerns a Mailchimp message, the adjacent Mailchimp spam-placement guide is a more specific starting point. A provider-specific symptom is not proof that the same cause applies to Gmail.

If a message reaches Gmail Inbox but has different placement at another mailbox provider, do not treat one provider's result as a verdict for the other. See why email goes to spam in Outlook but not Gmail for that separate comparison.

A worked evidence record for a Gmail Spam report

Record the observation before making configuration changes. The following is an illustrative incident note, not a Gmail header or a documented Gmail diagnostic format.

Technical exampletext

Incident: Message appeared in Gmail Spam instead of Inbox
Affected mailbox: recipient@yourdomain.com
Message identifier: retain the message-specific identifier
Observed time: 2026-08-13T12:00:00Z
Sender visible From domain: yourdomain.com
Sending application: identify the actual production application
Evidence retained: original message and available headers
Scope: one message, one recipient, or repeated placement
Google service status checked: yes or no

This record keeps the observation separate from an explanation. It also makes later comparison possible. For example, if multiple messages from the same production application show the same result, retain examples from that exact path. If only one message is affected, record that limitation instead of asserting a broad sending problem.

Avoid publishing or sharing unredacted message content, recipient addresses, private headers, credentials, or account-generated values. Use redacted copies when an internal team needs help reviewing the issue.

What to do next with the evidence you have

Start with the evidence closest to the observed problem.

If Gmail access itself seems disrupted, check the Google Workspace Status Dashboard guidance. This addresses reported product outages and downtime, not Spam classification.
If you are investigating a single message, preserve the original message and its available headers before moving or deleting it.
If you send from a domain or multiple applications, document which production application sent each affected message. A public DNS result cannot prove that the application used the expected authentication path for that message.
If the issue is recurring, compare the affected messages with messages from the same sender that reached the Inbox. Keep the comparison scoped to the same production path.
If you need a wider framework for the work, use the deliverability learning hub to choose the next topic based on the evidence you have.

Do not change DNS, sender settings, or mailbox rules solely because one message appeared in Spam. First establish what changed, what message path was involved, and what evidence can support a proposed change.

Check the domain's visible security posture

If you administer the sending domain, use Palisade's Email Security Score tool as a domain-level starting point before deciding what to investigate next. Compare any public result with the affected message and the actual production sender.

Check your domain's Email Security Score

A domain-level check cannot prove why Gmail placed one message in Spam, inspect Gmail's private placement decision, or confirm the state of every production sending path.

For an ongoing DMARC investigation across one or more domains, Start with Palisade. Palisade analyzes DMARC aggregate-report data, identifies sending sources and authentication or alignment issues, and creates prioritized remediation tickets. A human reviews the evidence and applies any policy change. This does not control Gmail's private inbox-placement decision or guarantee inbox placement.

Evidence

Sources and further reading

Questions readers ask

Frequently asked questions

Start with the message that actually landed in Spam: keep it, open its full headers, and work out which application really sent it. Check that SPF and DKIM pass and align with the domain in your From address on that exact path, then compare a message that reached the inbox with one that did not. Gmail never publishes its reason for a single placement, so build the case from evidence on your own side.

Gmail judged that message to look more like spam than wanted mail, and it does not publish its reason for any single placement. The usual places to look are authentication that fails or does not align with your From domain, a sending application nobody accounted for, and recipients who never asked for the mail. Narrow it down with the affected message, its headers, and whether the problem hits one recipient or many.