Most people think an email is “just text.” In reality, modern email often behaves like a tiny webpage. It can contain remote images, embedded links, invisible trackers, and formatting tricks that cause your device to make network requests the moment you open a message. Those requests can reveal information you never intended to share—like your IP address, approximate location, device type, and whether you opened the email at all.
That’s why we use viewer sandboxing. In plain English, sandboxing means: we display email content inside a controlled “box” with strict rules, so the email can’t reach out to the internet or interact with your device the way a normal webpage might. You still get a readable email, but the risky parts are isolated or blocked by default.
What “Viewer Sandboxing” Means (No Jargon)
Imagine you receive a message from an unknown sender. You want to read it, but you don’t want it to do anything behind your back. Viewer sandboxing is like putting that message inside a clear display case:
- You can look at the content.
- The content can’t reach outside the case to touch your device.
- The content can’t quietly load resources from the internet without your say-so.
- The content can’t run active code that behaves like an app.
In a typical email client, some of those boundaries exist, but they’re not always strict or consistent across providers. Our goal is to keep the rules simple, predictable, and privacy-first.
Why Email Viewing Can Leak Privacy
The most common privacy leak is the tracking pixel: a tiny remote image (often 1×1) hosted on a server that logs when your email client loads it. If your viewer loads that image automatically, the sender learns that the address is active, the message was opened, and they can often infer details about the viewer.
But it’s not only pixels. Email can also contain:
- Remote images that act like trackers (not just 1×1—sometimes normal images too).
- Link decoration (tracking parameters) that identify you when you click.
- Hidden elements (CSS tricks) that make tracking harder to notice.
- Auto-loading content that triggers network calls without a click.
- Mixed content where the email looks harmless but references third-party resources.
Viewer sandboxing is designed to stop “open email → quietly contact the sender’s server” as the default behavior. Instead, you get a safer read-first experience.
What We Block by Default
Our baseline approach is conservative. If something in an email could create an unnecessary privacy leak, it should not happen automatically. The exact implementation can vary by platform and message type, but the privacy intent is consistent:
1) Remote image loading
Remote images are a major source of tracking. In a sandboxed viewer, images that require fetching from external servers are blocked or neutralized by default. This means opening an email does not automatically notify a third party that you viewed it.
2) Active content and risky embeds
Email HTML can sometimes include elements that behave like active components. In a sandbox environment, those are restricted. The point is to avoid any scenario where opening a message can execute behavior rather than simply display content.
3) Automatic external requests
Even when something isn’t obviously “an image,” email can reference external resources. Sandboxing aims to prevent invisible network requests that occur just because the message is on screen. Reading should not equal “pinging the internet.”
4) Surprise navigation and unsafe link behavior
Clicking links is a user choice. Sandboxing helps ensure links don’t hijack the viewer or trigger unexpected behavior. When you choose to open something, it should be clear that you are leaving the email viewer context.
What We Still Allow (So Emails Remain Readable)
Privacy controls should not break the core purpose of email: reading a message. That’s why sandboxing is not “strip everything.” We aim for a balanced approach where safe parts of email display normally:
- Text content remains intact.
- Basic formatting (headings, paragraphs, lists) stays readable.
- Inline structure is preserved so the message makes sense.
- Links still appear as links—you decide whether to open them.
The guiding idea is: your eyes can see the content, but the content doesn’t get to “act” behind your back.
How Sandboxing Helps Against Tracking Pixels
Tracking pixels rely on a simple trick: if the email client fetches a remote image, the sender’s server records the request. The request itself becomes the signal. Sandboxing disrupts that by preventing automatic remote fetching in the viewer.
In practical terms, this means:
- Opening an email does not automatically confirm “this inbox is active.”
- It becomes harder for marketers and spammers to build reliable open-rate profiles.
- You reduce the chance of being targeted for more spam based on engagement signals.
No system can guarantee that every sender technique disappears forever, but blocking automatic remote loads removes one of the most common and effective tracking methods.
What About Links? Your Click Still Matters
Sandboxing focuses on what happens when you view an email. Clicking a link is a different action. If you click a link in any email—disposable or not—you may still share information with the destination site.
That’s not a failure of sandboxing; it’s the reality of the web. What sandboxing does is ensure you’re not leaking data before you decide to click.
For extra safety, treat links in unknown emails as untrusted. If a message claims urgency, threatens consequences, or asks you to log in immediately, it’s worth pausing and verifying through a separate, trusted path.
Metadata Minimization: Less Data Exposed During Viewing
Privacy isn’t only about blocking images. It’s also about reducing unnecessary information exposure during rendering. Many “viewer leaks” happen because content is allowed to behave like a webpage, and webpages tend to reveal a lot of metadata through requests and headers.
Sandboxing reduces these opportunities by limiting what email content is allowed to do. If nothing can auto-fetch externally, there’s less chance of revealing network identifiers as a side effect of simply reading.
Does Sandboxing Affect Deliverability?
No. Sandboxing affects how you view messages, not whether you can receive them. Email delivery happens before the viewer renders anything. The sandbox is applied at display time to isolate what’s shown on your screen.
If an email contains mostly text, you’ll see almost everything normally. If an email is heavily image-based, you may see placeholders where remote images would have loaded automatically. That is a tradeoff—one that favors privacy.
Plain-English Examples
Example A: Newsletter with tracking
A newsletter arrives with a hidden tracking pixel and multiple remote images. In a non-sandboxed viewer, those images may load immediately, confirming you opened it. In a sandboxed viewer, the message remains readable, but the remote loads are blocked, reducing tracking signals.
Example B: Verification code email
A service sends a verification code. These emails are typically text-first. Sandboxing won’t get in the way. You read the code, copy it, and move on—without background requests.
Example C: Suspicious “account alert”
A message claims your account will be locked unless you click a link. Sandboxing prevents passive tracking on open, but the real risk is the link. The safer approach is to open the service directly in a separate tab or app rather than clicking from the email.
What Sandboxing Is Not
It’s important to set accurate expectations. Viewer sandboxing is a powerful privacy layer, but it does not magically solve every privacy problem on the internet.
- It does not make you anonymous if you voluntarily click through to a site that tracks you.
- It does not stop tracking that happens outside the email viewer (browser cookies, fingerprinting, etc.).
- It does not turn malicious links into safe links; it simply prevents passive leakage while reading.
Think of sandboxing as “safe reading mode,” not as a complete privacy suite. It closes an entire class of silent leaks that many users never realize are happening.
Our Default Stance: Receive-Only, Read Safely
The philosophy behind sandboxing is simple: an inbox should be a place where you can receive messages without your identity being automatically exposed. When the act of viewing a message triggers network requests, the inbox becomes a sensor that reports back to third parties. We aim to reverse that default.
Receive-only workflows pair naturally with sandboxed viewing. You’re not using the inbox to build a long-term identity or send outbound messages. You’re using it to receive what you need, keep your primary address private, and move on.
Tips for Getting the Most Privacy from Any Inbox
- Use a fresh address per site when possible to reduce cross-service linkage.
- Be cautious with link clicks in emails that create urgency or ask for credentials.
- Prefer text-based verification flows over “image-only” messages when available.
- Assume marketers track and treat unexpected “you subscribed” emails as suspicious.
Sandboxing helps on view, but good habits help everywhere else.
Conclusion
Viewer sandboxing is our way of making email safer to read. It isolates message content so it can’t quietly fetch remote assets, can’t run risky behavior, and can’t leak data simply because you opened an email.
The result is straightforward: you get the information you came for—verification codes, confirmations, receipts, messages—without turning your inbox into a tracking beacon. That’s what “privacy-first viewing” should feel like in everyday use.