Why is Gmail showing 'This message seems dangerous' warning?
Updated on 23 Oct 2026: We clarified Gmail's safety warnings, added checks for work and school accounts, and corrected authentication and link-troubleshooting advice.
Gmail shows "This message seems dangerous" when its filtering systems decide the delivered message resembles email that recipients or Google have treated as unsafe. The cause can be the From domain, link domain, tracking domain, landing page, attachment, copy, sending pattern, hidden HTML, or sender identity. It is not limited to one DNS record or one bad URL.
Both the domain used in your links and the domain in the From address deserve investigation. The warning can also appear when the message has no visible links, because Gmail still evaluates headers, MIME parts, attachments, image sources, Reply-To, Return-Path, and reputation signals. Preserve the exact received email because Gmail evaluates the whole message. Use Suped's email tester to inspect a comparison copy, then compare its headers, authentication results, URLs, redirects, and HTML assets with the original Gmail sample. A separate test does not reproduce Gmail's private filtering decision.
The warning is a message-level decision
A passing SPF, DKIM, and DMARC result helps, but it does not guarantee Gmail will trust the message. Gmail also looks at link safety, domain history, recipient behavior, message similarity, sender display names, and whether the email resembles campaigns that users reported.
- From domain: Check authentication failures, impersonation, and sender reputation; a new domain alone does not identify the cause.
- Link domain: A tracking host or redirect can expose an unsafe destination, including a compromised landing page.
- Message content: Urgent language, credential prompts, odd formatting, hidden content, and suspicious attachments raise risk.
- Sender identity: Abnormal characters, misleading display names, and Reply-To mismatches can make normal mail look spoofed.
- Recipient feedback: Similar messages marked as scams can affect later mail with the same pattern.
What the Gmail warning usually means
The banner means Gmail has identified a safety risk in the message. It often appears above the message body with advice to avoid links, downloads, replies, or personal information. Spam placement and a dangerous-message banner are different outcomes; messages in Spam still require caution. The decision uses technical authentication, domain and URL reputation, sender identity, message content, and recipient signals.
Gmail opened email showing the This message seems dangerous warning above the message body.
Use the warning as a starting point for diagnosis. A message can pass authentication and still receive the banner because a landing page has unsafe content, a redirect host has a bad history, the sender address uses lookalike characters, or the template resembles email that users have reported. Gmail does not publish a score or a sender-side switch that removes the warning. Read the full banner text: references to suspicious links or reports of similar phishing messages help prioritize the investigation.
|
|
|
|---|---|---|
Sender | Untrusted domain | Headers and history |
Authentication | Failed checks | SPF, DKIM, DMARC |
Identity | Spoofed display | From and Reply-To |
Links | Risky redirects | Every URL |
Website | Unsafe landing page | Site and certificate |
Content | Scam-like copy | Plain-text clone |
Common causes of the Gmail dangerous-message banner
What to do when you receive the warning
Do not click a link, download an attachment, reply, or enter personal information while the message is unverified. Confirm the sender through a known phone number, saved contact, or the organization's website opened independently. Do not use contact details or links inside the warned message for verification.
- Inspect the sender: Compare the full email address with the display name and check for substituted or abnormal characters.
- Verify independently: Contact the sender through a channel you already trust, especially if the message requests money, credentials, or account changes.
- Give accurate feedback: In Gmail on a computer, open More beside Reply and select "Report phishing" for a deceptive message. After independent verification of a false positive, select "Report not phishing" or use "Looks safe" if the banner offers it.
- Contact the sender: Send the exact warning text and message time through a separate channel so the sender can investigate the original source.
Do not ask recipients to bypass the warning
A sender should not tell recipients to click "Looks safe" before they verify the message independently. Recipient feedback can correct a false positive, but it does not replace fixing authentication, identity, link, website, or reputation problems. Follow Google's phishing reporting instructions to submit accurate feedback.
If you entered a password after following the email, open the account website independently, change that password, and review unfamiliar account access. If you opened a suspicious attachment on a work device, contact your IT team.
How to isolate the cause
The fastest diagnostic path is to change one thing at a time. If you rewrite the email, change the domain, swap the tracking link, and move to another sending IP in one test, you learn very little. Keep the Gmail sample intact, then create controlled variants.
Start with domain configuration because it is easy to verify. A domain health check can identify DNS configuration issues. Verify DKIM using the selector in the message and check forward and reverse DNS for the actual sending IP. Then move to links, hidden content, headers, and copy.
Flowchart for diagnosing a Gmail This message seems dangerous warning.
- Capture: In Gmail on a computer, open More beside Reply, then Show original. Save the full headers, raw source, exact banner wording, subject, template ID, sending IP, and send time.
- Authenticate: Check SPF, DKIM, and DMARC results in the Gmail headers for the exact message.
- Inventory: List every visible link, tracking link, image URL, view-online link, unsubscribe link, attachment, and hidden HTML part.
- Reduce: Send a plain-text clone with no links, then add links, HTML assets, and attachments back in stages.
- Compare: If the banner returns after one URL, asset, or attachment, investigate that host, file, and redirect path.
Email tester
Send a real email to this address. Suped shows a results button when the test is ready.
?/43tests passed
Keep the From address, sending service, recipient, subject, and copy stable while changing one component per test. Repeat any failing variant before treating the changed component as the cause.
Authentication problems that increase risk
Authentication is the first technical check to fix. SPF checks the envelope sender domain, usually shown in Return-Path, and DKIM uses the signing domain in d=. DMARC passes when at least one passing check authenticates a domain that matches the visible From domain under DMARC. Default relaxed matching permits the same organizational domain; strict matching requires an exact domain match. A DMARC aggregate-report address improves operational visibility, but its absence does not make an otherwise valid message fail DMARC.
For mail sent to personal Gmail accounts, all senders need SPF or DKIM, valid forward and reverse DNS, TLS, RFC 5322-compliant formatting, and a Gmail-reported spam rate below 0.3%. Aim below 0.1%. Gmail generally treats a primary domain that sends close to 5,000 messages or more to personal Gmail accounts in 24 hours as a bulk sender, and that status does not expire. Bulk senders need SPF, DKIM, and DMARC, with the From domain matching the authenticated SPF or DKIM domain under DMARC. Their marketing and subscribed messages also need RFC 8058 one-click unsubscribe headers and a visible unsubscribe link. Honor unsubscribe requests within 48 hours. These Gmail sender requirements support delivery but do not override message-safety checks.
Illustrative DMARC monitoring record for _dmarc.example.comdns
v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com
Replace the example domain and reporting address with your own before publishing. This p=none record requests monitoring without DMARC enforcement; changing policy alone does not remove a Gmail warning.
Healthy setup
- SPF: The sending IP is authorized for the envelope sender domain.
- DKIM: A valid signature signs the message with a domain tied to the brand.
- DMARC: SPF or DKIM authenticates a domain that matches the visible From domain under DMARC.
- Infrastructure: Forward DNS, reverse DNS, TLS, and headers are consistent.
Risky setup
- SPF: The record exceeds lookup limits or leaves an active sender out.
- DKIM: The public key is missing or invalid, or the signing domain cannot support DMARC for the visible From domain.
- DMARC: Neither the SPF domain nor the DKIM domain matches the visible From domain.
- Infrastructure: PTR records, TLS, or required headers are missing or inconsistent.
A monitoring workflow matters because these records drift. New sending sources get added, infrastructure changes, and old DKIM public keys get removed or rotated. Suped's DMARC monitoring turns aggregate reports into source-level pass and failure data. Compare those patterns with the original Gmail headers to investigate authentication problems. Aggregate reports do not contain Gmail's per-message banner verdict.
Display names, headers, and no-link warnings
Some Gmail dangerous-message banners concern sender identity. Gmail can warn when the sender address uses abnormal characters or the display name mimics a brand or person. Check unexpected Reply-To and Return-Path differences against the sending service's documented setup; different addresses are common in legitimate mail. An empty or no-link email still carries sender identity and authentication signals.
- Display name: Use a plain, consistent sender name. Do not add subject text, urgency, recipient names, verification-style symbols, or lookalike characters.
- Header match: Compare From, Reply-To, Return-Path, DKIM d= domain, envelope sender, and sending IP in the original source.
- Automated mail: Check that web forms use your authenticated From address and put the visitor's address in Reply-To.
- Hidden parts: Check MIME parts, HTML comments, tracking pixels, calendar parts, attachments, and old signature code.
If the warning persists on a minimal plain-text test without links or attachments, focus next on sender identity, DMARC results, DKIM signatures, complaint history, domain reputation, and sending infrastructure. For automated messages, check the form sender or app sender separately from the normal employee mailbox. For an @gmail.com sender address, Google manages domain authentication; inspect account security and connected apps. If the banner mentions a compromised account, the sender should review account activity before resending.
When warnings affect only work or school Gmail accounts
Google Workspace administrators can apply additional protections to incoming mail. Google's documented Gmail safety settings include an inbox-warning action for suspected impersonation or unauthenticated messages. This gives another diagnostic lead when warnings appear only at one organization.
- Ask the recipient's administrator to review Apps > Google Workspace > Gmail > Safety and the settings applied to the affected user.
- Check protections for lookalike company domains, employee-name impersonation, and mail that passes neither SPF nor DKIM.
- Check attachment protections for encrypted files, scripts from untrusted senders, or file types uncommon at that organization.
- Compare fresh tests at personal Gmail and the affected organization; differences help narrow the investigation but do not prove a specific rule triggered.
A normal spam allowlist does not override every advanced protection. Have the administrator verify the message and investigate the applicable rule before considering a narrowly scoped exception.
Link, image, and website issues
If authentication passes, check every URL. Gmail does not only care about the visible link text. It can evaluate the actual href, redirect chain, public URL shortener, tracking domain, image host, view-online URL, unsubscribe URL, hidden HTML, and landing page content. Link text that promises one destination but opens another also creates risk.
Investigate unsafe destinations and redirects
A clean From domain can still receive the warning when a URL leads to an unsafe redirect or compromised landing page. Check default view-online and unsubscribe links because they are easy to miss. Fix broken URLs, expired certificates, and HTTP image assets as maintenance issues; none establishes the cause of this banner by itself. Normal formatting or a hidden preheader alone also does not establish the cause.
|
|
|
|---|---|---|
Tracking | Bad redirects | Remove unsafe redirects and secure destinations |
Images | Untrusted hosted content | Review host and file; use HTTPS |
Landing page | Compromise | Clean the site |
Unsubscribe | Unexpected destination | Verify the intended unsubscribe endpoint |
View page | Bad certificate | Renew the certificate |
Hidden HTML | Deceptive hidden links | Remove deceptive code |
URL checks for message safety and website maintenance
The practical test is simple: remove all links and send the same message body. If the warning disappears, re-add one URL group at a time. Start with the call-to-action link, then tracking, images, unsubscribe, and view-online. When the warning returns, inspect that URL group, every redirect, and the destination domain. Remove required unsubscribe elements only in internal diagnostic tests; restore the visible unsubscribe link and one-click headers before production sends.
Reputation and sending behavior
Gmail also reacts to reputation. Sudden volume changes and recipient complaints can damage sender reputation. A public blocklist (blacklist) listing helps identify abuse or infrastructure problems; it does not disclose Gmail's reason for displaying the banner.
Risk levels to check before retesting Gmail
These bands are practical triage levels, not Gmail's internal scoring.
Low risk
Retest
Required authentication passes, destinations are verified, and sending volume is stable.
Medium risk
Investigate
One link host or DNS record has a recent change that needs review.
High risk
Pause
The site is compromised, DMARC fails for legitimate direct mail, or complaints spiked.
Use Suped's blocklist monitoring to watch the domains and IPs that carry your mail and links. A blocklist or blacklist records domains or IP addresses flagged for suspected abuse; investigate the reason for a listing alongside the Gmail sample.
Send only to people who requested the mail, keep the sending rate steady, and increase volume gradually with engaged recipients. Review complaint rate after any change to the sending domain, infrastructure, or template. If the warning appeared after a sudden change, compare it with this deeper guide on low sender reputation. Reputation recovery has no fixed timetable because Gmail needs repeated evidence of wanted mail and stable sending behavior.
How Suped helps with the fix
Suped's DMARC reporting and email authentication platform provides sending-source detection, aggregate-report parsing, hosted record management, and alerts. Compare source-level authentication data with the original Gmail headers and use blocklist monitoring to investigate public reputation signals. Track configuration changes across domains while correcting the underlying issue.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
The goal is to identify why Gmail distrusted the exact message, fix that signal, and keep authentication and reputation data visible before the next production send.
- Issue detection: Suped identifies failed sources and gives practical steps to fix each one.
- Alerts: Alerts show when failures, new sources, or reputation changes need attention.
- Hosted records: Hosted DMARC and Hosted SPF help maintain records as approved sending sources change.
- Multi-domain view: Teams managing many brands can review domains without separate spreadsheets.
Views from the trenches
Best practices
Test one variable at a time: links, copy, authentication, then sender volume changes.
Keep tracking, image, unsubscribe, and view-online URLs on secure branded domains you control.
Record the first failing Gmail sample with headers, source IP, template, and send time.
Common pitfalls
Clearing SPF, DKIM, and DMARC once, then ignoring new senders added later is risky.
Assuming the From domain caused the banner before checking every redirect URL wastes time.
Assuming HTTP images or an expired certificate proves the banner's cause skips testing.
Expert tips
Start with a plain-text clone and add sections back until the Gmail banner returns.
Check expired certificates on branded tracking and image hosts before editing copy.
Watch for old landing pages that still host files or redirects no one owns anymore.
Expert view
Expert from Email Geeks says the cause can be the From domain, a linked domain, or a compromised website behind a redirect.
2020-03-25 - Email Geeks
Marketer view
Marketer from Email Geeks says site checks can report harmful software without naming the exact URL, so teams need to inspect each link and redirect.
2020-03-25 - Email Geeks
These 2020 community observations are troubleshooting leads, not a published description of Gmail's current filtering rules.
Retest after fixing the cause
Retest with fresh messages after each correction and save the new headers and banner result. Repeat the corrected template with a small set of consenting Gmail recipients before resuming normal sending.
If the message still gets flagged with no links, focus on sender trust: DMARC results, DKIM signatures, complaint history, volume changes, display names, Reply-To, hidden MIME parts, and content patterns. For a broader prevention checklist, use the guide on how to avoid Gmail warnings before the next production send.
