Why Are My Sent Emails Going to Spam? What to Check First

Your sent email can land in a recipient's Spam or Junk folder because the receiving service cannot trust its sender identity, your sending history raises concern, the recipient has a filtering rule, or the message looks unwanted. Start with one message that a willing recipient actually found in Spam. Get its original headers and the recipient provider before changing domain settings, copy or sending volume. The evidence may identify a fix; sometimes it only narrows the next check.

In short: Confirm Spam/Junk placement, preserve the exact message, read its authentication results, then ask whether a recipient-side rule or a wider pattern explains what remains. Fix the supported problem and retest comparable messages. A sending platform's “delivered” event typically means the recipient's mail server accepted the mail; check your platform's definition. It does not certify Inbox placement.

If you mean that incoming messages are going to your own Spam folder, start with your mailbox's block, filter and Not spam controls instead. This guide concerns mail you send to other people. It focuses on US B2B senders, but Gmail's sender rules below apply specifically to personal Gmail recipients, while Microsoft 365 evidence concerns an organization's receiving system.

Confirm Spam/Junk placement and collect one message

“My email went to spam” is often a guess based on no reply. Separate four observations before investigating:

• Rejected or deferred: The sending platform shows a bounce, mail-server error or temporary failure. The recipient may never have had a message to place in Spam. Follow that provider's error and investigate rejection separately.
• Accepted and found in Spam/Junk: A willing recipient can locate the actual message there. This is the branch this article diagnoses.
• Accepted into an Inbox category: Gmail's Promotions tab is an Inbox category, not the Spam folder. The sender cannot demand Primary placement.
• Accepted but no reply: That alone does not show where the message landed or whether the recipient wanted to answer.

Make one copyable case file for the confirmed message. These are the fields to capture before asking anyone to diagnose it:

• Required: send time and timezone; recipient provider or organization; sending address and visible From domain; sending platform or mailbox; subject and exact sent body/link domains; and the recipient's observed Spam/Junk folder. Add the platform's send/acceptance or error event if available; otherwise record it as unknown.
• If the recipient agrees: untouched original message and full headers, including Authentication-Results; message ID; a recipient-admin verdict or trace where available. Make a separate redacted copy before sharing beyond the immediate investigation.
• Context: what changed shortly before the problem—email service provider (ESP), sending domain, template, tracking links, list source or volume—and whether other willing recipients saw the same message class in Spam.

Keep each observation tied to a message and date rather than declaring the entire domain “broken.”

Ask a colleague, partner or willing recipient: “Could you share the original message or full headers for the email you found in Spam, with the received time?” A header is the message's routing and security record. They can find it this way:

• Gmail on a computer: Open the message and choose More → Show original, per Gmail Help.
• New Outlook or Outlook on the web: Open the message and choose More actions → View → View message details. In classic Outlook for Windows, open it in a separate window and choose File → Properties → Internet headers, per Microsoft's instructions.

Ask them to keep the original unchanged. Make a separate redacted copy before sharing beyond the immediate investigation; do not request access to a prospect's private inbox. In a Microsoft 365 organization, an admin may interpret the headers and inspect message trace where permitted.

If nobody can provide an original, you can still record the exact recipient provider, send time, sender log, message and recent changes. Mark any diagnosis provisional. A test to an address you control can help reproduce a path, but it cannot substitute for the witnessed message.

Read authentication without mistaking a pass for placement

In the original, find Authentication-Results and copy each result with its domain. The short reading key is:

• Visible From: The sender domain the reader sees, such as company.example.
• SPF (spf, smtp.mailfrom): Did the sending server have permission to send for the return-path domain shown here?
• DKIM (dkim, header.d): Did a cryptographic signature verify for the signing domain shown here?
• DMARC (dmarc, header.from): Does at least one passing SPF or DKIM domain match the visible From domain under DMARC's alignment rules?

An SPF or DKIM pass for a service's own domain does not automatically validate the company domain people see in From. Google's sender guidance and Microsoft's authentication explanation explain the checks. If this original shows DMARC failure for the visible From domain, investigate alignment on the actual route and fix a supported configuration problem before retesting. If DMARC passes through aligned SPF or DKIM, keep investigating recipient policy and unwanted-mail signals; that pass is not an Inbox verdict. One individual SPF or DKIM failure does not by itself mean the visible From domain failed DMARC. An administrator may need to interpret the original, especially when forwarding or multiple services are involved.

For example, spf=pass smtp.mailfrom=service.example and dkim=pass header.d=service.example can coexist with dmarc=fail header.from=company.example. Those passing identities belong to the service, not the visible company domain. Case 1 below shows how to act on that mismatch. Do not publish a new DMARC enforcement policy blindly; an incomplete sender inventory can disrupt legitimate mail.

Also check which route sent this instance. Your ordinary Google Workspace or Microsoft 365 mailbox may be authenticated correctly while a marketing platform, CRM or outbound tool sends through a separate path. A DNS screenshot alone cannot prove that this message passed. Conversely, an aligned authentication pass is a useful check, not a promise of Inbox delivery: receiving systems also assess reputation, recipient settings and message behavior.

The Gmail sender requirements are worth checking against mail to personal @gmail.com and @googlemail.com accounts. All senders need SPF or DKIM, among other requirements. Senders at about 5,000 messages a day to personal Gmail accounts across a primary domain have additional requirements: SPF, DKIM, DMARC with From alignment, and one-click unsubscribe plus a visible body unsubscribe link for marketing or subscribed messages. Unsubscribe requests must be honored within the provider's stated timeframe. The FAQ explains counting and enforcement. These are not a universal threshold for every US corporate mailbox, and compliance still does not guarantee Primary or Inbox placement.

Check whether the recipient's policy made the decision

If authentication passes but one Microsoft 365 organization puts the message in Junk, the recipient's own policy may be involved. Microsoft documents the X-Forefront-Antispam-Report and Authentication-Results headers, as well as recipient admin message trace and filtering rules. The SFV value helps an admin trace how this specific message was handled. For example, SFV:SKS can indicate a mail-flow rule that marked the message as spam, or a spam decision passed from an on-premises Exchange system in a hybrid setup. The header alone does not identify which; the admin's trace or policy review does.

The sender normally cannot see a customer's tenant rules or block list. If a willing recipient reports the problem, ask for the original and have their admin check the verdict and policy if appropriate. If only this organization is affected, first test that local explanation. Changing the sender's SPF record or stripping every link would not fix a recipient's deliberate rule. The admin may decide a false positive needs a policy correction or a submission through its normal channel; the sender should not ask an organization to bypass security controls without a supported diagnosis. If the admin cannot help, leave that organization unresolved and compare consenting recipients at the same provider in other organizations before declaring a domain-wide problem.

An individual's block or Junk rule is another possible local explanation. One recipient moving a message to Inbox may influence their future mail, but it does not repair a sender-wide issue. If multiple independent organizations show the same problem, look for a shared sender, message or audience factor as well. Do not infer a corporate policy from one screenshot of a Junk folder; the admin's trace or verdict is better evidence.

Investigate unwanted-mail and message signals

When the message is authenticated and no recipient-specific rule explains a broader pattern, examine whether the mail is wanted and accurately presented. Compare the actual list source, recipient role, send frequency, subject promise, body, destination links and opt-out handling. A prospect who never had a reason to receive a generic pitch may mark it as spam even if every DNS check passes. The recipient's complaint is a signal about the experience, not a technical bug to hide with a new sending domain.

For permission-based marketing, check that people received what they signed up for and can leave easily. For cold B2B outreach, inspect whether the account and person fit the specific problem and whether the message makes one honest, relevant argument. Alore's cold email guide shows how to build from a specific pain, credible reason and small next step; repeated “just checking in,” fake urgency and unsupported claims add no value. Suppress replies and opt-outs across follow-ups. Alore's Drip Campaigner describes sequences, reminders and analytics, but it does not reveal the recipient provider's filtering reason or guarantee placement.

Gmail's Postmaster Tools dashboards can help a sender of sufficient volume examine personal-Gmail spam reports, authentication and delivery errors. Read the denominator: its spam rate concerns messages that reached an engaged recipient's Inbox and were then marked as spam. If Gmail automatically sends much of your mail to Spam, a low reported-spam rate can be misleading; low-volume days may show no data. Use it as one provider-specific signal, not proof that every address is healthy.

Inspect message changes as hypotheses. A broken or misleading destination, new tracking redirect, impersonating display name, unexpected attachment or malformed HTML merits checking in the actual sent copy. There is no reliable forbidden-word list that turns an unwanted message into a wanted one. Replacing “free” or removing every image without comparing the same recipient-provider path may only change the appearance of the test. If a link is suspect, verify its final destination and whether it matches the sender and promise before running a controlled comparison.

Yahoo's Sender Hub likewise emphasizes authentication, low complaints and easy unsubscribe for relevant bulk mail to its hosted consumer domains. Its rules should not be pasted onto Microsoft 365 business mailboxes as if all providers use the same threshold or verdict.

Three spam-folder cases and the next action

These are fictional diagnostic examples, not Alore campaign results. Each begins with a willing recipient finding the sent message in Spam/Junk.

Case 1: The sender changed platforms and alignment failed

A team moves a subscribed update to a new sending service. A personal-Gmail recipient finds it in Spam. The original reads spf=pass smtp.mailfrom=service.example, dkim=pass header.d=service.example, dmarc=fail header.from=company.example. This rules out the easy conclusion that “SPF pass means our company domain passed.” The new route has authenticated the service but not aligned with the company's visible From domain. This is an identity-configuration problem worth fixing first, though Gmail's full placement decision is still unknown.

Owner and action: The sender's email administrator and service provider configure an aligned DKIM signature or return-path and inventory other legitimate senders before changing policy. Retest: Send the same class of message through the corrected route to consenting personal-Gmail mailboxes and verify the new originals show aligned authentication. Record placement across comparable samples.

Case 2: A recipient organization has a local rule

A sales rep's individual message lands in Junk at one Microsoft 365 customer. A contact and admin share the relevant original and trace. Authentication passes; the admin finds SFV:SKS and the specific mail-flow rule that set a spam score. The trace distinguishes this local rule from the sender-wide authentication failure in Case 1. The sender's “delivered” status could not reveal it, and SFV:SKS alone would not have proved the exact rule.

Owner and action: The recipient admin assesses whether the rule behaved as intended and, if not, follows the organization's false-positive process. The sender supplies the exact message and timestamp; it does not change DNS as a substitute for that check. Retest: With the admin's consent, send a comparable message after any policy change and inspect the recipient verdict. If the admin cannot share details, record the organization as unresolved and compare other consenting Microsoft 365 recipients before inferring a broader fault.

Case 3: Several providers place the campaign in Spam

Test-mailbox observation: Consenting recipients at several providers find the same campaign class in Spam. Their originals show aligned authentication.

Separate campaign record: The team sees 8 opt-outs among 200 platform-delivered messages to a newly imported cohort in its first week, versus 1 among 200 in a comparable earlier cohort and first-week window: 4% versus 0.5%. A list-source audit finds little reason for the new group to expect the pitch.

This fictional difference is a warning to investigate, not a benchmark or causal estimate. The test mailboxes show placement; the cohort opt-outs show unwanted-mail risk. Neither tells the team one hidden filter rule or proves that a particular word caused it.

Owner and action: The sender pauses that cohort, removes people who objected, checks how addresses were obtained, and rewrites the message only after deciding which recipients have a legitimate, relevant reason to hear from the team. A new domain is no substitute for repairing unwanted outreach. Retest: Use a small, comparable eligible cohort and consenting test recipients across the affected providers; record each sample's actual folder and monitor cohort complaint rates and provider-specific errors separately.

Test a repair without claiming an inbox guarantee

Keep a before-and-after record for the same sending route and recipient provider: the original message, observed folder, authentication domains, relevant recipient verdict if available, send and bounce log, campaign and audience. Make the supported change first. If you alter DNS, platform, list, volume and template together, a later Inbox sample will not tell you which mattered. A necessary urgent suppression or security repair takes priority over preserving a neat experiment.

Repeat a comparable send with consenting recipients or test mailboxes. Keep the same route, recipient provider and message class in the record. Verify the mechanical fix directly: aligned authentication after a domain change, a corrected recipient rule in a trace, or functioning suppression after a complaint.

For example, a fictional before/after log uses the same five consenting Gmail mailboxes, message class and route in each period:

• Before: All five originals show DMARC failure; three messages are found in Spam.
• After: The sender configures aligned DKIM. All five new originals show aligned DKIM and DMARC passes; one message is found in Spam.
• What it shows: The originals verify the authentication change. The folder checks are limited placement observations. Record the date, header and folder for every message.

Repeated sends to the same five mailboxes do not prove durable Inbox recovery or that authentication was the only cause of the placement change. Monitor a comparable eligible audience and its opt-outs or complaints separately. There is no universal number of days, daily send cap or “warm-up” schedule that proves recovery. Gradual, consistent sending and monitoring follow Google's guidance, but they cannot compensate for messages people do not want.

A third-party seed test samples those seed accounts, not the exact filters of every buyer. Opens and reply rates can change because of relevance, timing or mailbox privacy features; they are not placement measurements. A lower reported complaint rate may reflect less Inbox exposure; interpret it using the earlier Postmaster denominator, not as automatic proof of improvement.

When should you escalate—and with what evidence?

Escalate when the same message-specific problem persists after a verified mechanical fix, several independent recipient organizations show the same pattern, or a provider returns an actionable error. Send the responsible email service provider or mailbox administrator the case file from the first section, plus the change already made and the comparable retest result. Ask which evidence they can inspect next, not for a guarantee of Inbox placement.

For personal Gmail, verified domain owners who meet its sender requirements can use Postmaster Tools to report a delivery issue; Google describes eligibility and the original-message details it requests. For a Microsoft 365 customer's local verdict, work with the recipient's admin. For a multi-provider unwanted-mail pattern, the sender's audience and campaign owner must repair targeting and suppression before scaling again.

The practical order is simple: witness the folder, preserve the message, inspect identity, check local policy, then investigate whether the mail is wanted. Stop when the evidence no longer supports the next claim. A diagnosis that admits uncertainty is more useful than a list of tricks that declares every Spam folder a DNS problem.