Why does Gsuite show an anti-phishing warning when sending emails?
Published 14 Aug 2025
Updated 16 Oct 2026
12 min read
Summarize with
Updated on 16 Oct 2026: We clarified Google Workspace warning types and added checks for DKIM activation, sender identity, and forwarded mail.
G Suite, now Google Workspace, shows an anti-phishing warning when Gmail detects a possible sender identity or message safety issue. One common banner says "Be careful with this message." One documented trigger is an outside sender using a display name found in the recipient's directory, while the email address is outside the organization's domain or domain aliases. This warning can appear on legitimate mail that stays in the inbox.
Read the sentence beneath the warning before changing DNS. Authentication failures and employee-name spoofing involve different checks, so domain age alone does not explain a specific banner. Google documents these protections under Safety settings in the Admin console.
- Expected trigger: The message is external and the display name matches a person in the recipient's directory.
- Fixable trigger: SPF or DKIM fails, or the authenticated domains do not meet DMARC's domain-matching rules.
- Reputation check: Review spam complaints and abrupt sending-volume changes when investigating broader delivery problems.
- Content trigger: Gmail detects a suspicious link or attachment. Check the delivered content rather than assuming every login link causes a warning.
Identify the Gmail warning before changing DNS
Read the whole warning and note whether it appears while composing, replying, or reading a delivered message. The heading "Be careful with this message" alone does not identify which check triggered it.
|
|
|
|---|---|---|
A name resembling a colleague | Possible display-name impersonation | Compare the sending address with the recipient's directory domains |
An unverified sender or question mark | Missing or failed authentication | Read SPF and DKIM results in the received message |
An "External" label or external-recipient reminder | Someone in the conversation is outside the organization | Review the recipients; the indicator alone is not a phishing verdict |
A suspicious link or attachment | Message-content safety | Verify the request through a known channel before opening anything |
Different Gmail warnings require different checks
Google's Safety settings distinguish spoofing and authentication protection from link and attachment protection. Keep the exact warning text with your troubleshooting notes.
Why a legitimate sender gets an impersonation warning
An employee-name warning appears when Google Workspace detects possible 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 domain aliases. With employee-name spoofing protection enabled, Gmail can show the warning even when the mail is legitimate.
For this banner, check identity and authentication before investigating spam placement. Gmail can keep the message in the inbox and still warn the recipient to pause before replying, clicking, or sharing sensitive information.
Expected does not mean harmless
If an external sender uses a name in the recipient's directory, the warning is consistent with employee-name spoofing protection. Confirm the sender through a known channel and check authentication before trusting a sensitive request.
Employee-name warning conditions
- External sender: The email comes from outside the recipient's Google Workspace tenant.
- Matching name: The display name matches a person in the recipient's directory.
- Recipient policy: Employee-name spoofing protection is enabled with the action to keep mail in the inbox and show a warning.
Needs fixing
- DMARC failure: Neither SPF nor DKIM has a passing result with a domain that meets DMARC's matching rules.
- Bad identity: The display name imitates an employee or executive too closely.
- Risky content: An unverified request for payments or sign-ins needs independent confirmation.
Why Google Workspace flags external senders
Google Workspace has several protections that can produce a warning bar. One documented setting is employee-name spoofing protection. It checks for a sender name in the recipient's directory when the email address is outside the recipient's domain or domain aliases.
That detail matters. Gmail evaluates SPF, DKIM, and DMARC while comparing the sender identity with what the recipient organization knows about its own people. A vendor domain that passes authentication can still trigger the banner if it sends under an employee name that Gmail associates with the recipient organization.
Google Workspace warning flowchart with external sender, name match, authentication, and domain trust checks.
|
|
|
|---|---|---|
Name match | A directory name used with an external address | Use a clear brand or team display name |
Similar domain | A domain resembling the recipient's company domain | Use the correct, recognizable sending domain |
Authentication failure | No passing SPF or DKIM result | Repair authentication for the actual sending service |
Unsafe destination | A suspicious link or linked image | Investigate the destination and remove unsafe content |
Common checks behind Google Workspace warnings
Authentication checks to run first
Confirm each sending domain has the appropriate SPF policy, valid DKIM signing, and a DMARC policy with aggregate reporting configured. Start with Suped's domain health check to review published authentication records, then verify the results on a delivered message.
If DMARC exists, inspect whether real mail passes through SPF or DKIM with a domain that matches the visible From domain under DMARC rules. 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 passes only when at least one of those authenticated domains matches the domain the recipient sees. Under default relaxed matching, bounces.example.com can match a From domain of example.com; strict matching requires identical domains for the relevant method.
?
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 uses a return-path or DKIM signing domain that does not meet DMARC's matching rules.
Illustrative DNS records for Google Workspace mailDNS
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"
Replace the example domain, DKIM selector and public key, and reporting mailbox with your own values. This SPF example authorizes only Google Workspace; incorporate any other legitimate senders into the existing SPF policy before using -all. The p=none policy requests monitoring without quarantine or rejection for DMARC failures.
Suped, our DMARC platform, turns aggregate reports into source-level evidence. DMARC monitoring shows which sending systems pass or fail authentication. Compare unknown sources with your sending inventory before classifying them as unauthorized.
Sender identity mistakes that trigger the banner
The warning often remains after authentication is fixed because the visible identity still looks wrong to Gmail. This often happens 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. SPF authenticates the envelope-sender domain, and DKIM verifies a signature for its signing domain. DMARC connects a passing result to the visible From domain; none of these checks verifies the person's display name.
- 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: An unexpected Reply-To address can divert a conversation. Check it against the sender's normal contact details.
- Login links: Verify the destination of an unexpected sign-in link through a known channel before opening it.
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.
Check every linked and tracking domain
Gmail can evaluate domains beyond the visible From address. Landing pages, redirectors, tracking links, linked images, and file hosts can add risk signals. A message can pass SPF, DKIM, and DMARC but still show a warning when Google identifies a suspicious destination or linked image.
- Expand redirects: Follow every tracking link to its final destination and remove unexpected hops.
- Use recognizable domains: Keep links and tracking on domains that clearly belong to the sender's brand.
- Check every host: Review landing pages, image hosts, and redirect domains for blocklist (blacklist) entries, while treating Gmail's warning as a separate signal.
- Remove avoidable risk: Replace URL shorteners, broken HTTPS destinations, and links unrelated to the message.
Test the delivered message
Audit links in a message received by Gmail instead of relying on the campaign editor. Sending platforms often rewrite URLs or add tracking domains during delivery.
How to fix it as the sender
Fixing the warning means reducing identity confusion. Do not start by asking the recipient to allowlist the sender. Make the message easier for Google to trust through an authenticated domain, a consistent sending source, a clear display name, and content that matches what the recipient expects.
- Verify SPF: Keep one SPF policy per evaluated domain, authorize only active senders, and stay within the 10-term limit for DNS lookups, including nested includes.
- Turn on DKIM: Sign mail with the domain users recognize. In Google Workspace, publish the key from Apps > Google Workspace > Gmail > Authenticate email, then select Start authentication.
- Publish DMARC: Begin with reporting, then move toward quarantine or reject after legitimate sources pass. A stricter policy does not remove display-name warnings.
- Rename senders: Use a team or brand name when sending from outside the recipient's organization.
- Audit linked domains: Check final destinations, tracking links, image hosts, and blocklist or blacklist status.
- Stabilize volume: Send mail recipients expect and avoid sudden volume increases. There is no fixed waiting period that removes a warning.
Suped, our DMARC platform, groups authentication failures by sending source and provides steps to investigate them. Use that workflow when warnings affect mail sent through one CRM or ticketing system while other mail passes authentication.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
DMARC aggregate reports do not contain Gmail's banner text or a per-message phishing verdict. Use Suped's source-level results to investigate authentication, then verify the warning separately in the recipient's delivered message.
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 action for many categories is to keep the email in the inbox and show a warning. The admin can instead route those categories to spam or quarantine and can apply settings by organizational unit. Open Apps > Google Workspace > Gmail > Safety, then review Spoofing and authentication for the recipient's organizational unit.
Do not lower these protections merely to silence one sender. 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 neither SPF nor DKIM authenticates the message with any domain.
- Link prompts: Warn users before opening links to untrusted domains.
Google's admin guidance says the yellow warning banner appears only in Gmail web, so a third-party mail app will not display it. Safe-sender entries do not override advanced security checks. Separate spam settings that explicitly bypass filters and hide warnings can suppress banners, but that creates a wider policy exception than fixing one sender.
Review narrowly scoped exceptions
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 a matching SPF or DKIM domain? Google Workspace also asks whether the sender's name, domains, links, and history look safe for that recipient.
Open the message in the recipient's Gmail inbox, select More next to Reply, then Show original. Read the receiving system's Authentication-Results header and compare the visible From domain, return-path, DKIM d= domain, and Reply-To address. An unexpected Reply-To needs investigation, but it does not itself cause DMARC failure.
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 only forwarded or mailing-list copies fail authentication, compare them with a direct delivery. Forwarding can break SPF, and message changes can break DKIM. Inspect ARC (Authenticated Received Chain) results before changing an otherwise working sender configuration.
If the header passes, inspect the human-facing identity and delivered links. Use a sender name that does not mimic a recipient employee, keep links on a recognizable brand domain where practical, avoid URL shorteners, and introduce new sending streams with stable volume.
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.
Match DMARC source data with received headers before assigning a warning to a service.
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
Use a plain test email, then add links and images one at a time to compare warning behavior.
Keep a stable sending domain for each mail stream to compare reputation changes over time.
Verify unexpected sensitive requests through a known channel before replying or opening links.
Marketer view
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 view
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
Frequently asked questions
Not always. DMARC failure is one cause, but Google Workspace can show the warning because of display-name spoofing, similar domains, low sender trust, or risky links.
Domain age alone does not explain a specific warning. Diagnose it using the exact banner text and the delivered message's authentication results. Consistent sending and correct DNS do not guarantee that an employee-name warning will disappear.
Yes. Legitimate emails trigger it when the display name resembles someone in the recipient's organization or the sending setup makes identity unclear.
Yes. Gmail evaluates shortened URLs, redirectors, linked images, and untrusted destination domains. Inspect links in the delivered message because the sending platform can rewrite them after campaign setup.
Usually no. The sender should fix authentication and identity signals first. Recipient-side changes can hide real impersonation attempts.
Record the exact warning text, then use More > Show original in the received Gmail message to inspect SPF, DKIM, and DMARC. Compare the visible From domain, return-path, display name, Reply-To address, and delivered links.
