Internal Email Going to Spam in Google Workspace: How to Fix It

Mail from your own domain landing in the spam folder inside Google Workspace feels like a contradiction. The sender and recipient are on the same domain, so why would Google distrust it? The answer is that Gmail does not treat a From: address as proof of anything — it checks how the message was actually sent.

When an app, server, or forwarding path sends as your domain without passing authentication, Gmail's own anti-spoofing rules catch it. This guide diagnoses why internal email is going to spam in Google Workspace and fixes it in the right order: authentication first, allowlisting last. That order matters, because the common advice — add the sender to an allowlist — hides the symptom while leaving the real hole open.

What 'internal email going to spam' actually means#

Gmail authenticates every inbound message against three checks: SPF (is the sending server allowed to send for this domain?), DKIM (is the message signed with the domain's key, and does the signature verify?), and DMARC (do those results line up with the visible From: address?). None of those checks care whether the From: address happens to match your own domain.

'Internal' is not a trust level on its own. A message earns trust from passing authentication and from staying inside Google's infrastructure end to end. The moment a third-party app sends as [email protected] from its own servers, the message leaves and re-enters Google as outside mail claiming your domain — which is the exact pattern Gmail's spoofing protection exists to stop.

So the message is not being punished for being internal. It is being flagged because, to Gmail, it looks like an outside party impersonating your domain. Understanding that distinction is what makes the difference between a fix that lasts and an allowlist entry you have to keep widening.

Why your own-domain mail gets filtered: the causes#

There are four common causes, and they need different fixes. Work down this table in order — the first two are authentication problems and account for most cases, and the last two are configuration problems you confirm in Email Log Search.

Fix 1: Authenticate the app or server that sends as your domain#

This is the fix that resolves most cases, and it is the one the allowlist advice skips. The goal is that every source sending as your domain passes SPF or DKIM in a way that aligns to your domain, so DMARC passes.

1. 1

   Inventory every source that sends as your domain

   List each app and server allowed to send as [email protected]: CRM, help desk, marketing platform, billing, monitoring and alerting, scan-to-email printers, and any departmental mail server. You cannot authenticate a source you have not identified, and a single unlisted printer is enough to keep tripping the spoofing rule.

2. 2

   Add each source to your SPF record

   Google's recommended base record is v=spf1 include:_spf.google.com ~all. Add each third-party sender with its own include: mechanism from the vendor — for example v=spf1 include:_spf.google.com include:spf.protection.outlook.com ~all. SPF evaluation is capped at 10 DNS-querying mechanisms (RFC 7208); go over that and the record returns a permerror and SPF fails outright, so consolidate includes as you approach the limit.

3. 3

   Turn on DKIM for your domain

   In Admin console, go to Apps > Google Workspace > Gmail > Authenticate email. Generate a key — choose 2048-bit if your DNS provider supports it — publish the TXT record at the host google._domainkey (google is the default selector prefix), then start authentication. Google notes it can take up to 48 hours for DKIM to begin working after you add the record.

4. 4

   Make the third-party app sign as your domain

   Google's DKIM key signs the mail your users send through Gmail, not the mail an outside app sends. For each third-party sender, either configure it to DKIM-sign with a key published on your domain (the vendor supplies the selector and value), or route its mail through Google's SMTP relay service so Google signs it with your key. One of the two has to be true for DKIM to align.

5. 5

   Confirm DMARC alignment, then publish or tighten DMARC

   DMARC requires SPF and/or DKIM first; allow 48 hours after setting them up before adding DMARC, and start with p=none while you read the aggregate reports. Alignment is the part people miss: SPF aligns when the Return-Path (envelope) domain matches the From: domain, and DKIM aligns when the signature d= domain matches it. Point the app's bounce/Return-Path at a subdomain of yours, or give it a DKIM key on your domain, so a technical pass becomes an aligned pass.

Fix 2: Check what your spoofing and authentication safety settings are doing#

The safety settings are the mechanism that files your mail into spam or quarantine. They are doing their job — the real fix is authentication above — but you need to know which one is firing, and you may need to soften its action while you complete Fix 1.

1. 1

   Open the safety settings

   Sign in to Admin console as an administrator and go to Apps > Google Workspace > Gmail > Safety. Scroll to the Spoofing and authentication section. Scope the account selector to the affected organisational unit first if you only want to change it for some users.

2. 2

   Read each setting and its action

   The settings are: 'Protect against domain spoofing based on similar domain names', 'Protect against spoofing of employee names', 'Protect against inbound emails spoofing your domain', 'Protect against any unauthenticated emails', and 'Protect Groups from inbound emails spoofing your domain'. Each has one of three actions: Keep email in inbox and show warning, Move email to spam, or Quarantine.

3. 3

   Identify the one catching your internal mail

   The two that usually catch own-domain mail from an unauthenticated app are 'Protect against inbound emails spoofing your domain' and 'Protect against any unauthenticated emails'. If either is set to Move email to spam or Quarantine, that is where your message went. Email Log Search names the safety setting that acted on the message.

4. 4

   Soften the action temporarily, not permanently

   While you finish authenticating the sender, you can set the action to Keep email in inbox and show warning so mail is delivered with a banner instead of hidden. Restore Move to spam or Quarantine once authentication is in place. Leaving the setting permanently relaxed is not a fix — it turns off the protection for every spoofed message, not just yours.

Fix 3: Find the compliance rule or split-delivery route that mislabels internal mail#

If authentication is clean and the safety settings are not the cause, a rule or a routing quirk is. Both are visible in Email Log Search, so confirm before you change anything.

1. 1

   Confirm what acted on the message

   Open Apps > Google Workspace > Gmail > Email Log Search, find the message by sender, recipient, or subject, and expand the Delivery section. It shows whether a named compliance rule or a safety setting acted on the message, and what action it took. This is the difference between a five-second diagnosis and an afternoon of guessing.

2. 2

   Narrow an over-eager compliance rule

   If a content compliance or objectionable-content rule is named, open Apps > Google Workspace > Gmail > Compliance and find it. A rule with the 'Internal - receiving' direction checked acts on user-to-user mail. Uncheck the directions it should not cover, tighten the matching expression, or scope the rule to the correct organisational unit so it stops catching legitimate internal messages.

3. 3

   Fix split or dual delivery re-authentication

   If headers show the message left Google and came back through another server, Gmail re-evaluated it as external mail claiming your domain. Register the relay's IP addresses as an inbound gateway under Apps > Google Workspace > Gmail > Spam, phishing, and malware > Inbound gateway, so Gmail reads authentication from the correct hop, and make sure that source is covered by your SPF record and DKIM.

4. 4

   Watch the inbound-gateway and allowlist interaction

   One documented gotcha: if an IP address is already used in an inbound gateway configuration, adding that same IP to the email allowlist does nothing — Gmail resolves the true source IP before applying the allowlist. Configure the gateway correctly rather than stacking an allowlist entry on top of it.

How to tell which cause you have#

Do not guess. Two tools give you a definitive answer: Show original on the message itself, and Email Log Search in Admin console. Open the filtered message, choose Show original, and read the Authentication-Results header — it states the SPF, DKIM, and DMARC results plainly.

Map the result to the cause with the table below. If all three pass, the problem is a rule or a safety setting, not authentication; if any fail, you are in Fix 1 territory.

Preventing it from happening again#

Most recurrences trace back to a new sending source that nobody authenticated, or a DNS change that quietly broke alignment. A short standing checklist keeps both from surprising you.

• Keep an inventory of every app and server allowed to send as your domain, and authenticate each one before it goes live.
• Stay under the 10-DNS-lookup SPF limit — one include per vendor, and consolidate or flatten as you approach it.
• Publish DMARC, start at p=none, read the aggregate reports, then tighten to quarantine or reject once every legitimate source aligns.
• Review the Gmail spoofing and authentication safety settings after any migration, domain change, or new sending vendor.
• Prefer routing third-party mail through Google's SMTP relay when the vendor supports it, so Google signs it with your DKIM key.
• Re-check DKIM after DNS edits — a rotated or missing selector silently breaks alignment and sends mail back to spam.

Where a client-side layer helps after the gateway#

Every fix above happens at the domain gateway, in Admin console, and that is the right place to fix authentication — it governs what enters and leaves under your domain's name. What it does not do is manage the individual inbox once mail has passed: the authenticated-but-noisy notifications, the internal threads that need filing, the outside message that is legitimate yet still not worth your attention. We build AI Emaily, an AI-native email client that adds a triage layer above Gmail, Outlook, and IMAP, acting on sender behaviour and the context you set rather than on a single header check.

It does not replace SPF, DKIM, or your Workspace safety settings, and it is not a deliverability tester — if your problem is authentication, fix that first with the steps above. Once mail is landing correctly, a 7-day free trial on the Pro and Autopilot plans lets you test whether an approve-before-send agent earns a place on top; every action it takes is logged and reversible.