How Email Image-Based Attacks Work: Preview Pane Risks

The assumption that you are safe from email attacks as long as you do not click anything is now outdated. Modern email clients load remote images automatically when you open or even preview a message. That image request reveals your IP address, confirms your email is valid, and can execute code in specific client configurations. No clicks required.

This matters for anyone responsible for email security. Here is how these attacks work, what the real risk is, and what your organization can do about it.

What happens when an email client loads an image

When an email contains an external image and your client displays it, the client sends a request to a remote server. That request is not harmless. It typically includes your IP address (revealing your approximate location and ISP), your email client and version, the time you opened the message, and the specific message ID you are reading.

This is how targeted phishing campaigns verify their targets. In one documented pattern, attackers sent HTML emails containing a single-pixel tracking image. When recipients opened the message in Outlook or Apple Mail, the image loaded from the attacker's server and confirmed three things: the email address was valid, the recipient worked at the target organization, and the specific workstation configuration based on IP routing.

In older or misconfigured clients, the attack surface is wider. HTML-formatted email images have been used to exfiltrate data via CSS, execute JavaScript in email rendering contexts, and confirm engagement without any user interaction.

The zero-click attack chain

The standard attack chain looks like this:

Attacker sends an HTML email with a remote image reference pointing to their controlled server

The email lands in the recipient inbox

The recipient opens or hovers over the email, triggering the preview pane

The email client loads the remote image automatically

The attacker receives the IP address, client fingerprint, and open confirmation

This information is immediately useful. An attacker who knows which employees opened a spoofed email impersonating IT support has a short list of targets for follow-up spearphishing. The preview confirmation tells them who is worth pursuing.

This is where DMARC monitoring becomes directly relevant to image-based attacks. If attackers are impersonating your domain to send these image-laden phishing emails, DMARC reports will show authentication failures for those messages. A spike in DMARC failures from unexpected IP addresses is often the first operational signal that a spoofing campaign is in progress, sometimes before any user reports the phishing email. DMARCFlow surfaces these patterns in aggregate so your team can respond faster than waiting for user reports alone.

Why preview panes make this worse

Preview panes are designed for convenience. They also automatically load emails, which means image requests fire even when the recipient has not consciously opened the message.

In Microsoft Outlook, the preview pane renders emails the same way a full open does. In Apple Mail, hovering over a message triggers similar behavior. In web-based clients like Gmail, lazy loading may delay some image requests, but the remote request still fires when the message is displayed.

The practical consequence: an attacker knows the moment an email lands in an inbox, and knows when that inbox is being actively checked, without the recipient taking any action.

What email clients do to protect against this

Modern email clients have implemented several protective measures:

Image proxying: Gmail, Outlook.com, and some other providers route image requests through their own proxies, which prevents the sender from seeing your real IP address

Sandboxing: Most clients now render images in sandboxed environments that limit what the image can do

Blocking by default: Some clients block remote images until the user explicitly chooses to load them

These protections are real but incomplete. Image proxying only works when the email provider has implemented it. Sandbox escapes are documented in CVEs for multiple email clients. And blocking remote images entirely breaks many legitimate marketing emails and newsletter images that organizations actually want to see.

The role of sender authentication

Image-based phishing campaigns rely on the ability to send email that appears to come from a trusted domain. If attackers could not impersonate your domain, these campaigns would lose much of their effectiveness against your users and customers.

This is why SPF, DKIM, and DMARC matter for this threat category specifically. When your domain has a strong DMARC policy (p=reject), attackers cannot send email that appears to come from your domain without that email failing authentication. That means they cannot as easily impersonate your IT department, finance team, or executives in image-laden phishing campaigns.

MTA-STS adds another layer by ensuring that email in transit between mail servers is encrypted and authenticated. Without MTA-STS, an attacker positioned on the network path between sender and receiver could potentially intercept and modify email content including image references during delivery. With MTA-STS enforcing TLS, that attack vector closes.

BIMI, when implemented, adds a visible logo authentication cue that helps recipients verify that emails claiming to come from your domain actually come from servers authorized to send on your behalf.

How to detect image-based phishing using DMARC reports

If attackers are sending spoofed emails impersonating your domain in phishing campaigns, DMARC reports will show authentication failures for those emails. Monitoring who is failing authentication when they claim to be your domain is one of the earliest signals that someone is running a spoofing campaign.

The pattern to watch for: a sudden increase in DMARC failures from IP addresses that are not in your sending infrastructure, particularly when those failures involve HTML email formats with image references. DMARCFlow tracks these patterns across your aggregate reports and flags anomalies so your team can investigate before a campaign fully launches.

How to reduce your email image attack surface

For IT administrators:

Configure email clients to block remote images by default for external senders

Enable DMARC with a reject policy on all domains that send email

Publish MTA-STS records to enforce TLS in transit

Review DMARC reports weekly for unexpected authentication failures

Implement BIMI to add sender authentication cues

For end users:

Set email clients to never load remote images from external senders

Report suspicious emails that reach the inbox despite filtering

Be cautious about unexpected emails that contain only images or very little text

For security teams:

Monitor DMARC reports for patterns that indicate spoofing campaigns

Track which domains are most frequently impersonated in failed authentication events

Correlate DMARC failure spikes with known phishing campaigns or threat intelligence

FAQ

Can opening an email preview pane compromise my computer?

In most modern email clients, simply opening an email in preview mode is unlikely to result in code execution due to sandboxing. However, it will confirm your email address and IP address to the attacker, and in older or misconfigured clients, image rendering vulnerabilities have been exploited. The practical risk for most organizations is phishing confirmation and information disclosure, not direct system compromise.

How do I stop email clients from loading remote images?

Most email clients have a setting to block remote images. In Outlook, go to File > Options > Trust Center and configure automatic picture download settings. In Apple Mail, go to Mail > Preferences > Viewing and deselect "Load remote content in messages." In Gmail, use the experimental proxy setting or install a browser extension that blocks remote image loading.

How does DMARC help protect against email spoofing used in image-based attacks?

DMARC ensures that any email claiming to come from your domain has valid authentication from an authorized mail server. If an attacker tries to send a spoofed email that loads a tracking image from your domain, DMARC will cause that email to fail authentication. A strong p=reject policy prevents the email from reaching recipients at all, and DMARC reports notify you when these attempts occur.

---

The practical takeaway is straightforward: blocking remote image auto-loading is a reasonable first step, but it is not a complete solution. Email authentication protocols like DMARC, MTA-STS, and BIMI address the upstream problem by making domain spoofing harder and easier to detect. DMARCFlow fits into this picture as the monitoring layer that tells you when someone is impersonating your domain in the first place.