Email Goes to Spam in Gmail but Not Outlook

Why Gmail can spam mail that Outlook accepts

The odd part is the clue: the same message reaches Outlook, but Gmail buries it. That usually means your mail is technically allowed, but Gmail trusts it less.

Gmail and Outlook do not share one spam score. Each provider weighs authentication, domain reputation, IP history, user complaints, engagement, content, links, sending pattern, and local policy in its own way. A message can pass SPF, DKIM, and DMARC and still land in spam because authentication proves who sent it. It does not prove people want it.

Start with the received headers from one Gmail spam copy and one Outlook inbox copy. Look for Authentication-Results, the sending IP, the DKIM selector, the visible From domain, and any spam reason Gmail shows. Then check the live DNS records with the free domain scorecard so you are not guessing from old screenshots.

• Confirm the Gmail message passes SPF or DKIM, and that DMARC passes through alignment.
• Compare the sending IP and return-path used for Gmail and Outlook. Some ESPs route providers differently.
• Check whether Gmail is seeing a new domain, a new IP, or a sudden jump in volume.
• Look for Gmail-only friction: high complaints, low opens, link redirects, URL reputation, or missing one-click unsubscribe on bulk mail.

Fix authentication first, even if Gmail says it passed

Passing once is good. Passing cleanly, every time, with aligned domains is what keeps provider-specific filtering from getting worse.

SPF is a DNS TXT record that lists which hosts may send for the envelope sender domain, also called MAIL FROM or Return-Path. Publish one SPF record only. Keep it under the SPF 10 DNS-lookup limit from RFC 7208. Too many include, a, mx, ptr, exists, or redirect lookups can return a permanent error. Use ~all while you are still finding senders, then consider -all only when every real sender is covered. Never use +all.

DKIM signs the message with a private key at your mail provider and a public key in DNS. The selector in the DKIM header points to that key, often something like selector1._domainkey.example.com. Make sure each sender signs mail, the selector exists, the key is current, and the DKIM signing domain lines up with your visible From domain when DMARC needs it.

DMARC checks whether SPF or DKIM passed and aligned with the From domain. Start with p=none and a rua mailbox so you can see who is sending. Move to p=quarantine and then p=reject only after the reports show your real mail is passing. If the XML reports are hard to read, use the free DMARC report reader to group senders, failures, and alignment problems.

• SPF: one record, no +all, under 10 DNS lookups, includes only real senders.
• DKIM: enabled for Google Workspace, Microsoft 365, your ESP, CRM, and support desk.
• DMARC: present at _dmarc, aligned, reporting to rua, and tightened after cleanup.
• MX: points to the service that receives your mail. Bad or stale MX does not usually cause outbound spam placement by itself, but it is part of a trustworthy domain setup.

Then isolate Gmail reputation

If authentication is clean, treat this as a Gmail reputation problem until the evidence says otherwise.

Gmail may distrust a sender that Outlook still accepts because Gmail has different user feedback and different abuse models. A few common triggers are cold lists, old subscribers who stopped engaging, sudden volume spikes, shared IP pools with bad neighbors, URL shorteners, redirect chains, image-heavy messages, attachments, and copy that looks like phishing. Public blocklists can matter too, especially for IP reputation, but a clean blocklist check does not guarantee inbox placement.

For bulk mail to personal Gmail accounts, follow Google's sender rules: authenticate with SPF or DKIM, use DMARC, keep spam complaints low, send over TLS, keep forward and reverse DNS valid, and make unsubscribe easy. Outlook.com also expects clean reputation, no blocklist problems, and proper authentication. Microsoft has published high-volume requirements for consumer Outlook domains that require SPF, DKIM, and DMARC when a sender crosses its stated volume threshold.

• Send a plain text test with one trusted link from the same domain. If it lands, the original content or URL chain is part of the problem.
• Segment Gmail recipients who opened or clicked in the last 30 to 90 days. Pause cold Gmail addresses while reputation recovers.
• Warm changes slowly. Do not switch domains, IPs, templates, and tracking links in the same week.
• Check Google Postmaster Tools if you send enough Gmail volume. Watch domain reputation, IP reputation, spam rate, and authentication.
• Search major blocklists for the sending IP and domain. Fix the root cause before asking for delisting.

Do not ignore AI-search crawlability

This does not decide Gmail inbox placement, but it affects whether people and AI answer engines can find the page where you explain your mail, product, or docs.

The live AI-search crawlers to allow are OAI-SearchBot for ChatGPT search, Claude-SearchBot for Claude, PerplexityBot for Perplexity, Googlebot for Google Search and AI Overviews, and Applebot for Apple search features. Disallowing these in robots.txt removes you from that engine's answer surface. Google AI Overviews use the normal Google Search index, so there is no separate AI Overviews crawler to block.

Training controls are different. GPTBot, ClaudeBot, CCBot, Google-Extended, and Applebot-Extended are training or opt-out controls. Blocking them does not remove you from live AI-search visibility. Google-Extended and Applebot-Extended are robots-only control tokens, not separate crawlers that fetch pages on their own.

Robots.txt is a stated policy. It is not proof of what happened in server logs. Perplexity-User and Bytespider have been reported to ignore robots.txt, so treat logs as evidence and robots rules as instructions. Google documents a full crawl, render, and index flow for Googlebot, and Apple says Applebot may render pages. For OAI-SearchBot, Claude-SearchBot, and PerplexityBot, JavaScript rendering behavior is not promised in the same way, so client-side-only text is a crawlability risk. Put important text in server-rendered HTML and test it with the free AI visibility checker.

A practical recovery order

Do the boring checks in order. Random template edits waste days when the real issue is alignment or Gmail reputation.

• Run the domain scorecard and fix SPF, DKIM, DMARC, MX, and obvious DNS drift.
• Read DMARC aggregate reports for the last few days. Find every sender and every Gmail failure.
• Compare headers from Gmail spam and Outlook inbox copies sent at the same time.
• Remove risky links, URL shorteners, large attachments, and image-only layouts.
• Send first to engaged Gmail recipients, then raise volume only after spam placement improves.
• Keep a changelog. Gmail reputation can take days or weeks to recover, so you need to know which fix changed the trend.

For deeper checks, use the related deliverability guides at InboxRadar guides. The main point is simple: Outlook inboxing does not prove Gmail will trust the same mail. Prove the sender, clean the list, simplify the content, and rebuild Gmail-specific trust.