Why does Gmail show a 'Looks safe' banner and hide images?

Gmail shows a “Looks safe” option when it has flagged a message as potentially deceptive but lets the recipient override that warning. Gmail can also hide remote images when it considers the sender or message suspicious. The two controls reduce risk before the recipient loads external content, opens an attachment, or follows a link. Do not click “Looks safe” merely because the display name is familiar. Verify the sender out of band, then investigate the delivered message's identity, links, and authentication.

Quick takeaways

“Looks safe” is a recipient action on a Gmail warning. It is not proof that Gmail authenticated the message or that the sender's account is secure.
Google's documented “This message could be a scam” warning can appear when a suspicious message comes from an address already in the recipient's Gmail contacts.
Gmail may suppress remote images when it considers the sender or message suspicious, even if the recipient normally displays images automatically.
A contact can be impersonated, or a real contact's account can be compromised. Verify unusual requests using a known phone number, website, or separate conversation.
Senders should preserve one affected message and inspect its From, Reply-To, return path, DKIM signatures, authentication results, URLs, attachments, and sending route.
SPF, DKIM, and DMARC can remove identity failures, but authentication alone does not guarantee that Gmail will consider a message safe or show its images.

The recipient decision and the sender investigation have different evidence. Open the full-size Gmail warning investigation path.

Google's current help page for the “This message could be a scam” warning says Gmail shows it when an email looks like a scam but comes from an address in the recipient's contacts. That context explains the unusual combination: Gmail recognizes a relationship while still seeing enough risk to warn the user.

Google tells recipients who believe the message is a scam not to reply or click its links. It provides a reporting action because the known contact's account may have been compromised. If the recipient is confident the message is legitimate, the documented options include Looks safe or Ignore, I trust this message.

The button does not turn the message into cryptographic proof. It records a recipient judgment for that interface and allows Gmail to relax the warning for the message. The recipient still needs to decide whether the sender, request, destination, and attachment make sense.

A familiar display name is weak evidence. Attackers can use a lookalike address, a misleading name, a compromised mailbox, or a reply address different from the visible sender. Treat a payment request, password prompt, urgent document share, or account-recovery instruction as unverified until the person or organization confirms it through a known channel.

Gmail's image control is a separate safety layer

Gmail displays remote images by default for ordinary messages. Google's current image settings documentation says Gmail scans images for suspicious content, proxies image requests to reduce exposure of a recipient's computer or location, prevents image cookies, and checks images for known harmful software.

The same page says Gmail does not show images automatically when it considers a sender or message suspicious. The recipient is asked whether to display them. This can happen even when the account's general Images setting is Always display external images.

That distinction prevents a common misdiagnosis:

Account preference: the recipient chose Ask before displaying external images, so remote images wait for a click across messages.
Message safety decision: Gmail held images for a sender or message it considered suspicious.
Rendering failure: the image URL is broken, private, blocked, or unavailable, so the content cannot load even after permission.

The sender should confirm which condition the recipient actually sees. A screenshot that crops out the wording above the message is not enough.

Recipients should verify before using “Looks safe”

Read the entire warning and inspect the message without interacting with its links or attachments. Google's phishing guidance recommends checking whether the sender name matches the address, whether the message is authenticated, whether hovered link destinations match their labels, and whether the From header looks correct. The guide to what phishing is covers the broader impersonation pattern and safe reporting steps.

Use a clean path to verify the request:

open the organization's site from a bookmark or typed address instead of the email link
call the sender using a number already on file
start a new conversation with the known address rather than replying to the suspicious message
ask an internal security or IT team to inspect the original message
compare the request with an existing ticket, invoice, or workflow

Do not rely on an allowlist entry or contact record as proof. Those controls can affect routing or presentation, but they do not prove that a particular message came from an uncompromised sender.

If the message is deceptive, use Gmail's report action. Google says reporting a suspicious message from a contact helps it protect the sender's account from abuse while allowing future legitimate messages from that contact.

The delivered message is the sender's best evidence

When a legitimate sender receives a screenshot of the warning, request the original message or its complete source. Do not diagnose a forwarded copy because forwarding can change authentication and wrap the original content.

Capture:

UTC receipt time and the Gmail account type, personal or Workspace
the exact warning text and whether images, links, or attachments were restricted
visible From, Sender, and Reply-To fields
return path and every DKIM d= signing domain
Authentication-Results for SPF, DKIM, DMARC, and ARC
every visible and underlying link destination
remote image hosts, redirect chains, and attachment types
message ID, sending IP, and sending platform

Google's message authentication help explains that Gmail's sender details show Mailed by and Signed by for authenticated mail. In the raw headers, receivers expose spf=pass or dkim=pass in Authentication-Results.

The article on phishing messages that pass SPF and DKIM explains why a pass for an unrelated domain is not proof that the visible brand authorized the message.

Authentication failures and identity mismatches need exact repairs

Start with DMARC alignment, not a count of pass tokens. A message passes DMARC when a passing SPF or DKIM identity aligns with the visible From domain. If SPF passes for one provider domain and DKIM passes for another unrelated domain, the message can still fail DMARC for the brand the recipient sees. When Gmail reports an SPF-specific problem, preserve the original headers and follow the Gmail SPF error diagnostic path before changing DNS.

Repair the route that produced the affected message:

authorize the correct MAIL FROM domain for SPF when that domain is yours and the route is meant to use it
publish the current DKIM key supplied by the sending platform and confirm the delivered signature uses the intended d= domain
publish one valid DMARC record and review aggregate reports before moving enforcement
stop unauthorized sources from using the visible domain
separate direct mail from forwarding or mailing-list transformations when reading results

Do not weaken the organization's DMARC policy to remove a Gmail banner. A less protective policy does not make a suspicious message safer, and it can reduce spoofing protection.

The current DMARC standard, RFC 9989, is explicit that a DMARC pass only validates authorized use of the Author Domain. It does not guarantee that delivery to the inbox is safe or desirable.

Passing authentication shifts the investigation to other signals

If the affected message passes aligned authentication, compare its identity, route, and content with a clean message from the same legitimate stream. Change one variable at a time.

Sender identity and account state

Confirm that the From and Reply-To addresses are expected, the display name is not misleading, and the account or API credential has not been compromised. Review new delegates, forwarding rules, API keys, OAuth grants, and unusual sending locations where the platform exposes them.

A genuine compromised account can authenticate successfully. Authentication proves domain authorization, not benign intent.

Links and destinations

Resolve every visible link without submitting credentials or opening an unknown payload. Record the first host, redirect chain, final host, certificate status, and whether the landing page is the expected property. Check for a newly compromised website, an expired domain, a shared tracking host, or a mismatch between link text and destination.

Do not rotate through new tracking domains to escape a warning. That removes historical context and can resemble abusive infrastructure churn.

Attachments and message structure

Compare the attachment type, filename, declared MIME type, and actual file type. Password-protected archives, executable content, unusual macro-enabled documents, and mismatched extensions deserve separate security review.

Inspect the delivered HTML and plain-text part. Hidden elements, malformed markup, deceptive button labels, credential prompts, or content injected after the campaign editor can change the message Gmail evaluates.

Audience and recipient relationship

One recipient warning can be specific to that mailbox's relationship and past actions. Repeated warnings across unrelated Gmail accounts and campaigns point toward a sender-wide pattern.

Review opt-in evidence, complaint trends, sending cadence, sudden volume changes, and whether the message was expected. Google's current sender guidelines combine authentication with low spam rates, valid infrastructure, TLS, standards-compliant formatting, and responsible sending practices.

Hidden images affect presentation and measurement

When Gmail blocks remote images, logos, product art, social icons, and image-based buttons may disappear until the recipient approves them. An open-tracking pixel also cannot request its remote resource, so the sending platform may not record that view.

This is another reason not to make an email depend on images:

put the main meaning and call to action in live text
give informative images useful alt text
use an HTML link or button that remains understandable without a background image
keep image URLs public over HTTPS and stable for the campaign's lifetime
avoid making open activity the sole signal for an automation or success report

Do not assume that changing the image host is the fix. First prove that the warning is tied to the image path rather than sender identity, links, attachments, reputation, recipient settings, or account compromise.

Validation requires clean and affected comparisons

Preserve the original affected message before any recipient clicks Looks safe. Then send a small labeled test through the same production route to permission-based Gmail accounts. Include one previously affected recipient when it is safe and appropriate, plus a comparison account with no prior relationship.

For each copy, record the warning text, image behavior, folder placement, full headers, message ID, authentication results, links, and attachment verdicts. Confirm that the intended route and template actually sent the test.

If the suspected cause is a link or message component, remove only that component in a controlled variant. If the suspected cause is authentication, retest after DNS is visible and verify the delivered identity. If compromise is possible, secure the account or API credential before sending any test.

One clean message does not prove recovery. Monitor several normal sends and watch for recurrence by Gmail account type, campaign, source, domain, and template. Gmail does not publish a fixed timer for removing a message-specific warning.

Palisade supports the sender-identity layer

Palisade cannot see a Gmail recipient's warning, click Looks safe, fetch hidden images, scan private links or attachments, secure a compromised mailbox, change external DNS unattended, or guarantee that Gmail will remove a banner.

Palisade can analyze DMARC aggregate reports for domains you control. That can help an IT team or MSP identify which service sent as the domain, compare SPF and DKIM identities with the visible From domain, and see whether authentication failures or unfamiliar sources coincide with the affected period.

Use the free Email Security Score to inspect the public SPF and DMARC configuration. If the incident exposes a broader need to inventory senders and monitor authentication across several domains or clients, start a Palisade account after preserving the affected message.

Frequently asked questions

Does “Looks safe” mean Gmail verified the sender?

No. It is an option for a recipient who believes a warned message is legitimate. Verify the request through a known channel and inspect the sender address, links, attachments, and authentication. A familiar contact can still be impersonated or compromised.

Why are images hidden when Gmail is set to display them automatically?

Google says Gmail can withhold images when it considers the sender or message suspicious. That per-message safety decision is separate from the account's general image preference. Read the exact banner before changing the setting.

Can a message pass DMARC and still show the warning?

Yes. DMARC validates authorized use of the visible From domain through aligned SPF or DKIM. Gmail can still evaluate sender behavior, account compromise, links, attachments, content, complaints, and recipient context. DMARC pass is not a safety guarantee.

Should a recipient click “Looks safe” to help a legitimate sender?

Only after independently verifying the message. The recipient's safety comes before sender troubleshooting. The sender should fix the underlying identity, account, link, content, or reputation issue and should not ask recipients to override warnings blindly.

Do hidden images mean the image files contain malware?

Not necessarily. Gmail may withhold all remote images because the sender or message appears suspicious. A separate rendering failure can also prevent an image from loading. Check the banner, public image URL, and delivered message before blaming one file.

How long does it take for Gmail to stop showing the warning?

Google does not publish a fixed recovery period for this message-specific warning. Repair the evidenced cause, retest at low volume, and monitor several normal sends. A one-message success is useful, but it does not establish a universal timeline.