Gsuite, now Google Workspace, shows this anti-phishing warning when Gmail thinks the message can confuse the recipient about who actually sent it. The most common trigger is simple: an outside sender uses a display name that is similar to someone in the recipient's organization, but the email address is not in that organization's domain. Google is warning the recipient about possible impersonation, not necessarily saying the message is spam.
For a new sending domain, this warning is common. It is even more likely when the sender has little Gmail history, weak SPF or DKIM setup, no DMARC policy, a display name that matches a real employee, or links that point to domains Google does not yet trust. Google documents these controls under Safety settings in the Admin console.
- Expected trigger: The message is external and the display name resembles a person in the recipient's directory.
- Fixable trigger: SPF, DKIM, or DMARC is missing, failing, or using a domain that does not match the visible sender.
- Trust trigger: The sending domain is new, has inconsistent volume, or has not built enough positive Gmail history.
- Content trigger: The message contains login links, shortened URLs, attachments, or wording that looks like account access mail.
The direct answer
The warning appears because Google Workspace is protecting the recipient from identity confusion. If the message says it is from Jane Smith, and the recipient's company has a Jane Smith in its directory, Gmail checks whether the sending address belongs to that company's domain or another trusted identity path. If it does not, Gmail can show the warning even when the mail is legitimate.
I treat this as an identity and authentication problem first, then a deliverability problem second. A spam placement issue usually means Gmail dislikes the message enough to place it in spam. This warning can appear on mail that stays in the inbox because Google wants the user to pause before replying, clicking, or sharing sensitive information.
Expected does not mean harmless
If the sender is external, the display name resembles an internal user, and the address is not part of the recipient's domain, the warning is expected. Still, the sender should confirm authentication and naming because real brand mail should be easy for Gmail to verify.
Usually expected
- External sender: The email comes from outside the recipient's Google Workspace tenant.
- Matching name: The display name is close to a real person in the directory.
- New domain: The sending domain has little Gmail history or low volume.
Needs fixing
- Failed auth: SPF or DKIM fails, and DMARC cannot authenticate the visible sender.
- Bad identity: The display name imitates an employee or executive too closely.
- Risky content: The email asks for replies, payments, passwords, or login actions.
Why Google Workspace flags external senders
Google Workspace has several protections that can produce a warning bar. The one that matches this wording is usually employee-name spoofing protection. It looks for messages where the sender's name is a name in the recipient's directory, but the email address is not from the recipient's domain or domain aliases.
That detail matters. Gmail is not only reading SPF, DKIM, and DMARC. It is also comparing the sender identity to what the recipient organization knows about its own people. A perfectly authenticated vendor domain can still trigger the banner if it sends as an employee name that Gmail associates with the recipient organization.
Flowchart showing how an external sender, name match, authentication, and domain trust lead to a warning.
|
|
|
|---|---|---|
Name match | Internal name | Change display name |
Similar domain | Lookalike | Use brand domain |
Auth fail | Weak proof | Fix SPF or DKIM |
Low trust | New sender | Warm domain |
Common Google Workspace warning triggers
Authentication checks to run first
The first technical check is boring, but it removes guesswork. Confirm the domain has one SPF record, valid DKIM signing, and a DMARC record that receives reports. I start with a domain health check because it checks SPF, DKIM, and DMARC together instead of treating each record as a separate issue.
If DMARC exists, inspect whether real mail is passing with the visible From domain. A passing SPF result on a bounce domain is not enough by itself. A DKIM pass on a third-party domain is not enough by itself. DMARC needs SPF or DKIM to authenticate in a way that connects back to the domain the recipient sees.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
For a narrower check, use a DMARC checker to confirm the TXT record syntax, policy, reporting address, and tag values. Then read the headers of an actual Gmail-received message because DNS can be correct while the sending platform still signs with the wrong domain.
Minimum DNS records to verifyDNS
example.com. TXT "v=spf1 include:_spf.google.com -all" selector1._domainkey.example.com. TXT "v=DKIM1; k=rsa; p=PUBLICKEY" _dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:d@example.com"
Suped, our DMARC platform, is useful here because it turns aggregate reports into source-level evidence. DMARC monitoring shows which systems are passing, which systems are failing, and which ones are sending without authorization. That is the fastest path when the warning appears for some campaigns but not others.
Sender identity mistakes that trigger the banner
The warning often survives after authentication is fixed because the visible identity still looks wrong to Gmail. I see this when a vendor sends on behalf of an employee with the employee's exact name, but the actual address is a vendor domain. The recipient sees a familiar name, while Gmail sees an external domain.
That is why some Gmail warnings appear even when DNS looks fine. Authentication proves a domain had authority to send the message. It does not prove that the human-readable name is safe, familiar, or expected.
- Exact employee names: A vendor email from Alex Chen at another domain can look like the internal Alex Chen.
- Lookalike domains: A domain with one swapped letter can pass its own authentication and still look deceptive.
- Reply requests: Messages asking for a direct reply to a person raise the risk of impersonation.
- Login links: Links to sign-in pages add another reason for Gmail to warn the recipient.
Risky setup
The display name is a real employee name, the sender address is a vendor or new domain, and the message asks for a reply or login action.
Cleaner setup
The display name includes the brand or team, the sender uses an authenticated brand domain, and the call to action points to a trusted domain.
How to fix it as the sender
Fixing the warning means reducing identity confusion. I do not start by asking the recipient to allowlist the sender. I start by making the message easier for Google to trust: authenticated domain, consistent sending source, clear display name, and content that matches what the recipient expects.
- Verify SPF: Keep one SPF record, include only active senders, and stay under DNS lookup limits.
- Turn on DKIM: Sign mail with the domain users recognize, not only a vendor-owned domain.
- Publish DMARC: Begin with reporting, then move toward quarantine or reject after legitimate sources pass.
- Rename senders: Use a team or brand name when sending from outside the recipient's organization.
- Stabilize volume: Send predictable mail streams so Gmail can build a clean history for the domain.
Suped helps with this workflow by grouping failures into issues and showing the source that caused them. That matters when Google Workspace warnings come from one CRM, one ticketing system, or one marketing stream while the rest of the domain is healthy.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
For most teams, Suped is the stronger practical choice because it brings DMARC, SPF, DKIM, blocklist monitoring, blacklist checks, and deliverability signals into one place. It also gives real-time alerts and specific steps to fix issues, so the next action is clear.
Do not train users to ignore it
If a recipient sees this warning, do not tell them to click anyway as the default answer. Fix the sending identity first. For urgent mail, ask them to confirm by another channel, then correct the sender setup before repeating the campaign.
What Google Workspace admins can change
The recipient's Google Workspace admin controls the action Gmail takes for several safety settings. The default is often to keep the email in the inbox and show a warning. The admin can also route some categories to spam or quarantine, depending on the setting and organizational unit.
I rarely recommend lowering these protections to make one sender quieter. If the warning is accurate, changing the recipient policy hides a useful signal. The better fix is for the sender to stop looking like an impersonation case.
- Employee names: Warn when an external sender uses a name found in the directory.
- Similar domains: Warn when an external domain looks visually close to the company domain.
- Domain spoofing: Warn, spam, or quarantine mail pretending to be from the protected domain.
- Unauthenticated mail: Warn when mail lacks SPF or DKIM authentication by any domain.
- Link prompts: Warn users before opening links to untrusted domains.
Allowlisting is not a real fix
Allowlisting can be appropriate for tightly controlled infrastructure, but it should not be the first fix for a sender identity warning. A sender that looks confusing today can create a larger security gap if the recipient organization suppresses warnings globally.
When authentication passes but the warning remains
A clean DMARC pass does not guarantee the warning disappears. DMARC answers one question: did the visible From domain authenticate through SPF or DKIM under DMARC rules? Google Workspace also asks whether the sender's name, domain, links, and history look safe for that recipient.
That is why I check the full received message. The Authentication-Results header tells me whether SPF, DKIM, and DMARC passed. The visible From, return-path, DKIM d value, and links tell me whether the identity still looks mismatched.
Header fields to inspecttext
Authentication-Results: mx.google.com; spf=pass smtp.mailfrom=bounces.example.com; dkim=pass header.d=example.com; dmarc=pass header.from=example.com From: Support Team <support@example.com>
If the header passes, look at the human layer. Use a sender name that does not mimic a recipient employee, keep links on the same trusted brand domain where practical, avoid URL shorteners, and make the first few sends plain enough that Gmail can learn the stream without extra risk signals.
Views from the trenches
Best practices
Treat display-name warnings as identity warnings, not simple spam placement symptoms alone.
Check whether the sender is outside the tenant before changing authentication records.
Use DMARC reports to confirm which service sent the warning-triggering message first.
Common pitfalls
Assuming a DMARC pass means Google fully trusts the displayed sender identity is risky.
Changing the recipient's warning policy before fixing sender authentication creates risk.
Using an employee's exact name from a vendor domain invites preventable warnings in Gmail.
Expert tips
Send a plain test email first, then add links and images to isolate the trigger quickly.
Keep a stable sending domain for each mail stream so reputation has clean history.
Ask recipients to verify by another channel only when the message is urgent or sensitive.
Marketer from Email Geeks says Google Workspace warnings are expected when an outside sender uses a display name that matches someone in the recipient's directory.
2024-04-17 - Email Geeks
Marketer from Email Geeks says the message is an anti-impersonation warning, not a normal spam verdict, because many impersonation attempts can pass SPF or DKIM.
2024-07-09 - Email Geeks
The practical bottom line
Gsuite shows the anti-phishing warning because Google Workspace sees a possible impersonation pattern: external sender, familiar name, similar domain, failed authentication, low trust, or risky content. For a new domain sending to a Google Workspace account, that is common.
The right response is not panic and not blanket allowlisting. Confirm SPF, DKIM, and DMARC. Review the display name. Check the links. Build stable sending history. If the domain sends through several platforms, use Suped to see which source is causing failures and what to fix next.
