Skip to Main Content

Provider deliverability · Gmail (personal Gmail and Google Workspace inboxes)

Why does Gmail show 'this message seems dangerous'?

Samuel Chenard

By Samuel Chenard · CEO & Co-Founder, Palisade · Reviewed September 2, 2026

Gmail shows "this message seems dangerous" when its filters score your message as a phishing risk. Google does not publish the exact trigger, but the documented causes are mail failing SPF and DKIM, a lookalike From name or domain, and links or attachments its scanners distrust. The recipient's admin decides whether it stays in the inbox or goes to Spam.

The 30-second check

Start with authentication, because it is the one trigger Google documents as a default. In Google Workspace, the setting "Protect against any unauthenticated emails" requires a message to pass SPF or DKIM, and its default action is "Keep email in inbox and show warning". If your domain does not authenticate cleanly, every recipient on that default gets a banner. The free checker below reads your SPF, DKIM, and DMARC records the way Gmail's filters do.

Check your domain now

Enter your sending domain and the check runs instantly on the next page. Free, no signup.

Why Gmail is blocking your email

Likely causeWhat's happening
Your mail is not authenticated with SPF or DKIMGoogle Workspace ships a setting called "Protect against any unauthenticated emails", which requires messages to be authenticated by any domain with SPF or DKIM. Its default action is "Keep email in inbox and show warning", so unauthenticated mail earns a banner without anything else being wrong. Gmail's own SMTP reference uses the same language at the gateway: `550 5.7.26 This email has been blocked because the sender is unauthenticated.`
Your From name or domain looks like someone the recipient trustsTwo more Workspace settings default to "Keep email in inbox and show warning": "Protect against domain spoofing based on similar domain names", which fires on domains that look visually similar to the recipient's own, and "Protect against spoofing of employee names", which fires when the sender name matches a name in the recipient's directory but the mail is not from their domain. A first name plus a lookalike sending domain will trip both.
A link in the message points somewhere Google distrustsGoogle's link settings cover discovery of harmful links hidden behind shortened URLs, scanning of images referenced by links, and a warning prompt on clicks to untrusted domains. Gmail's SMTP reference carries the matching gateway verdict: `421 4.7.0 This message is suspicious due to the nature of the content or the links within.` A shortener, a redirect chain, or a tracking domain with a bad history is enough.
The attachment is one Gmail treats as high riskGoogle documents three attachment protections that also default to warn rather than block: encrypted attachments from untrusted senders, which cannot be scanned; attachments carrying scripts; and attachment types that are uncommon for the recipient's domain. A password-protected ZIP sent to a recipient who never receives them is the common legitimate case.
The sending domain or IP has a weak reputationGoogle tells senders to keep spam rates in Postmaster Tools below 0.10% and to avoid ever reaching 0.30% or higher, and warns that a high spam rate leads to increased spam classification. Its SMTP reference includes `550 5.7.1 This message is likely suspicious due to the very low reputation of the sending domain`, which is the same judgement expressed as a rejection instead of a banner.
The account really was compromised, or looks like it wasGoogle documents a separate banner, "This message could be a scam", shown above mail that looks like a scam but comes from an address in the recipient's own contacts. Reporting it marks the message as "sent from a compromised account". If your team's mail suddenly draws warnings from people who have corresponded with you for years, check for a compromised mailbox before you touch DNS.

Use the provider's own sender surface to confirm the pattern

Gmail publishes its own sender data separately from your DNS. Use it to confirm the provider-side symptom after you have checked the public authentication records below.

Google Postmaster Tools Authentication dashboard with SPF, DKIM, and DMARC pass-rate charts.
Source: Microsoft Learn, “Google Postmaster Tools in Customer Insights, checked 2026-07-29. Public documentation image of the Google Postmaster Tools interface, reused unchanged with attribution.

Check the public signals before changing settings

Check your DMARC record gives you a fast public-DNS baseline. It does not replace the provider's private reputation or placement data, but it tells you whether an authentication problem is visible before you edit a sending platform.

Palisade DMARC checker result showing a published DMARC policy, report destination, and record tags for a non-sensitive test domain.
Source: Palisade, “DMARC checker, checked 2026-07-29. First-party public tool result for a non-sensitive test domain; it validates what public DNS exposes.

How to fix it, step by step

  1. Run the DMARC check on your sending domain

    Use the free checker above (or at /tools/dmarc). It shows your SPF, DKIM, and DMARC records and whether alignment can succeed. This is the first step because unauthenticated mail is the one banner trigger Google publishes as a default, and it is the only one you can verify yourself in seconds.

  2. Authenticate every service that sends as your domain

    Add each platform to your SPF record and turn on DKIM signing with your own domain, then confirm both at /tools/spf and /tools/dkim. Google requires personal-Gmail mail to carry a DKIM key of 1024 bits or longer, and requires the From domain to align with either the SPF domain or the DKIM domain for senders above 5,000 messages a day.

  3. Read the headers of a message that got the banner

    Ask one warned recipient to forward the original message and paste the headers into /tools/email-header-analyzer. spf=, dkim=, and dmarc= in Authentication-Results tell you whether cause one applies. If all three pass, the banner is coming from the link, attachment, or lookalike checks instead, and the rest of these steps matter more than DNS.

  4. Audit the links you actually ship

    Run your click-tracking domain and any shortened or redirected URLs through /tools/url-reputation and /tools/phishing-link-checker. If a domain of yours has been classified by Safe Browsing, the Security Issues report in Search Console names the pages and offers a review, and Google publishes a form for reporting an incorrect classification.

  5. Stop sending the attachment shapes Google flags

    Encrypted archives, files containing scripts, and file types the recipient's domain rarely receives all default to a warning. Publish the document behind a link on a domain you own, or send a plain PDF, rather than asking recipients to open a password-protected archive.

  6. Watch spam rate and reputation in Postmaster Tools

    Verify your domain at postmaster.google.com. Google says the dashboards cover spam rate, reputation, message authentication, and delivery errors, all calculated and updated daily, and that data applies only to mail sent to personal Gmail accounts. Hold spam rate under 0.10% and treat 0.30% as the line you never approach.

Related free tools: SPF checker · DKIM checker · URL reputation checker · Phishing link checker · Email header analyzer

If you send in volume: Gmail's published rules

Gmail's sender requirements took effect on 1 February 2024. Every sender must set up SPF or DKIM, publish valid forward and reverse DNS for sending IPs, use a TLS connection, format messages to RFC 5322, and keep spam rates reported in Postmaster Tools below 0.30%. Senders above 5,000 messages a day to Gmail accounts must additionally pass both SPF and DKIM, publish DMARC at a policy that may be set to none, align the From domain with either the SPF or the DKIM domain, and support one-click unsubscribe on marketing and subscribed messages. Google counts the 5,000 across a whole primary domain including its subdomains, and says bulk sender status has no expiration date. Google's FAQ also notes that from November 2025 it is ramping up enforcement on non-compliant traffic, with disruptions including temporary and permanent rejections. Per Google's Email sender guidelines and its sender guidelines FAQ, checked 2026-09-02.

Check your standing with Gmail

Bounce codes you may be seeing

Blocks in this cluster surface as specific SMTP codes. Match yours below; the linked guides cover each code's verbatim provider messages and full fix.

The real root cause: unenforced authentication

The "this message seems dangerous" banner is a verdict about identity, not about writing. Gmail is telling the recipient it cannot establish who sent the message, and Google's own defaults say so plainly: the setting that requires SPF or DKIM ships with the action "Keep email in inbox and show warning", and the setting for mail pretending to come from the recipient's own domain does too. Once your mail authenticates and the From domain aligns with the passing domain, those two checks stop firing, the lookalike checks have a real identity to compare against, and the remaining triggers narrow to things you can inspect: a link, an attachment, a reputation number. Getting there means SPF and DKIM correct for every service that sends as you, DMARC aligned with the From header, and the policy walked from p=none through quarantine to p=reject so that nobody else can send mail wearing your domain and spend its reputation for you. Monitoring tells you which senders are failing; enforcement is what stops the impersonation that keeps the warning justified.

DMARC software that does the work

Palisade's AI agent takes domains all the way to enforcement: hosted SPF, DKIM, DMARC, and MTA-STS records on paid plans, DMARC reports monitored continuously, and every policy step drafted for your approval on the way to p=reject. The Free plan covers one domain and up to 1,000 emails per month, and the agent names every problem it finds there; applying the agent's fixes needs a paid plan, and the full product is open for a 15-day trial.

Get startedBook a demo

1 domain free up to 1,000 emails/month

Fixing this across every client domain

Gmail evaluates each client domain on its own records and its own reputation, so a warning banner on one tenant tells you nothing about the other forty-nine, and a fix on one does not carry across. Palisade turns that into one workflow: hosted and managed SPF, DKIM, DMARC, and MTA-STS records for every client domain, DMARC aggregate reports read for you so failing senders surface before a client's prospects start seeing warnings, and each domain carried to p=reject with your team approving every step. It plugs into ConnectWise, HaloPSA, and Autotask, pricing is per client domain with rates that improve as the portfolio grows, and your own MSP domain runs free as an NFR domain so you can prove the process before the first client conversation.

Questions readers ask

Frequently asked questions

Why do my emails say 'this message seems dangerous' in Gmail?

Gmail attaches that warning when its filters judge your message a phishing risk. Google does not publish the criteria for this banner, but it documents the conditions that default to a warning: mail that passes neither SPF nor DKIM, a sender name or domain resembling someone in the recipient's directory, risky attachments, and links to domains it distrusts.

How do I remove the Gmail dangerous message warning from my emails?

There is no button that removes it. Fix the underlying signal: authenticate the domain with SPF and DKIM, align the From domain with whichever one passes, publish DMARC, drop link shorteners and encrypted attachments, and clear any Safe Browsing classification on domains you own through the Search Console Security Issues report.

Does Google publish what triggers the 'this message seems dangerous' banner?

No. Google publishes the admin settings whose action is "Keep email in inbox and show warning", two separately named banners, and the SMTP strings for the same failures at the gateway, but it does not publish the criteria or scoring behind this specific banner. Any page quoting a threshold for it is guessing.

Can a Google Workspace admin turn the warning banner off?

Only in blunt ways. Google says two spam options stop banners entirely: "Bypass spam filters and hide warnings for messages from senders or domains in selected lists" and "Bypass spam filters and hide warnings for all messages from internal and external senders". Both reduce the recipient's protection, so treat them as a last resort rather than your fix.

Why does the warning appear in the browser but not in my phone's mail app?

Google states that warning banners appear only in Gmail web, and that third-party apps do not display a warning banner. A recipient reading on a mail client will see the message with no visible warning even though Gmail classified it the same way, which is why sender-side reports of this banner are usually inconsistent.

Is 'this message seems dangerous' the same as 'this message could be a scam'?

No. Google documents "This message could be a scam" as the banner shown above mail that looks like a scam but arrives from an address already in the recipient's contacts, with a "Report this suspicious message" action that flags it as sent from a compromised account. Different banner, different trigger, same underlying suspicion about identity.

Will fixing SPF and DKIM stop the Gmail warning immediately?

Not always immediately. Authentication removes the trigger Google documents as a default, but reputation lags. Google says it can take time for improvements in spam rate to reflect positively on spam classification, so expect the banner to fade over days of clean, authenticated sending rather than on the next message.

Does a link shortener cause the Gmail dangerous warning?

It can. Google's link settings explicitly cover discovery of harmful links hidden behind shortened URLs, and its SMTP reference includes a suspicion verdict based on the nature of the content or the links within a message. Send full URLs on a domain you own instead of routing recipients through a shortener.

Sources and last verified

Every Gmail fact on this page is drawn from that provider's own documentation, last checked 2026-09-02. Provider policies change; if a detail looks off, the linked source is authoritative.

Related guides

Email deliverability, fixed: the full guide