Is Mailtrap Tracking Your Email? How to Block It

It depends on which Mailtrap you mean, and the two halves of the product sit at opposite ends of the privacy spectrum. Mailtrap email tracking only exists in one of them. Mailtrap Email Testing is a sandbox that swallows development mail so it never reaches a real person, which means it cannot track you, because nothing was ever delivered. Mailtrap Email Sending is a production email service with an invisible open pixel that is switched on by default, plus optional click tracking that rewrites every link in the message. If the email actually arrived in your inbox, you are dealing with the second one.

Key Takeaways

• Mailtrap's own setup documentation states that "By default, Mailtrap tracks email opens for each email sent," which makes open tracking something a sender switches off rather than something they switch on.
• Mailtrap Email Testing is described in Mailtrap's docs as "a fake SMTP server that traps all emails sent from your application," and the same page says plainly that "Emails sent to Sandbox never reach real recipients."
• Mailtrap's click tracking routes every link through a subdomain on the sender's own domain in the form mt-link.yourdomain.com, so the tracker carries no visible Mailtrap branding.
• A DNS lookup on Mailtrap's own tracking host, mt-link.mailtrap.io, returns a CNAME to t.mailtrap.live, which is the infrastructure sitting behind those sender branded links.
• Mailtrap's open webhook delivers the sender a timestamp, your email address, your IP address and your user agent, and the click webhook adds the exact URL you clicked.

What Is the Difference Between Mailtrap Testing and Sending?

One is a bucket that catches mail before it escapes, the other is a genuine email service provider delivering to real people. Confusing the two is why searches for Mailtrap tracking produce contradictory answers.

Email Testing, also called Email Sandbox, exists so a developer can point a staging app at sandbox.smtp.mailtrap.io and never accidentally email ten thousand customers a test invoice. Mailtrap's own overview calls it "a fake SMTP server that traps all emails sent from your application" and states that "Emails sent to Sandbox never reach real recipients." No domain verification, no delivery, no recipient to track.

One narrow exception exists. Mailtrap's automatic forwarding docs explain that a captured test message can be pushed on to a confirmed address, and the address owner has to click a confirmation first. The tell is the sender, because Mailtrap notes that "All forwarded email messages use forward.mailtrap.info in the From: header." That is a colleague's QA mail reaching you, not a marketing beacon.

Email Sending is the other product entirely. Verified domain, DKIM, DMARC, real delivery, analytics. That is where tracking lives.

Does Mailtrap Track Email Opens?

Yes, and unlike most transactional senders, it does so by default. Mailtrap's sending domain setup guide files tracking under an optional step and then says the quiet part out loud: "By default, Mailtrap tracks email opens for each email sent."

The same page describes the mechanism precisely: "Mailtrap tracks email opens via an invisible pixel. It's added to each message sent from your account. When an email is opened, a pixel is loaded, and an 'open' event is recorded." A tracking pixel is a transparent image, typically one pixel square, with a unique identifier baked into its URL. Your mail client fetches it to render the message, and that fetch is the report.

The default matters more than it sounds. Amazon SES requires a sender to build a configuration set and enable the Opens event before anything is recorded, and Postmark ships with link tracking set to None and TrackOpens false. With those two, a developer has to reach for tracking deliberately. With Mailtrap, tracking is the state you inherit the moment your domain verifies. Friction decides defaults far more reliably than intent does.

Does Mailtrap Track Link Clicks?

Only if the sender is on a paid plan and turned it on, but when they do, every link in the message gets rewritten. Mailtrap's documentation is explicit that "Click tracking and custom domain for clicks tracking are available only for paid accounts."

What happens alongside it is the interesting part. Per the same setup guide: "If you enable click tracking, the toggle for Custom Domain for Clicks Tracking will be switched on automatically. That way, all links will be redirected through your domain (mt-link.yourdomain.com)." Turning on click tracking also turns on the disguise, in the same click, with no separate decision.

Senders can carve out exceptions. Mailtrap supports a data-mt-no-track attribute on an anchor tag, which leaves that link untouched in both the HTML and plain text bodies. It exists so app deeplinks do not break in transit, not as a privacy control. Everything else goes through the redirect, and our explainer on how email link wrapping actually works walks through the anatomy of a rewritten URL.

What Is the Mailtrap Tracking Domain?

On paper it is a subdomain of the sender's own domain, and underneath it is Mailtrap infrastructure. Mailtrap requires four CNAME records during domain setup, listed in its documentation as "Domain Verification, DKIM (2), and Custom Tracking Domain," plus one TXT record for DMARC. That fourth CNAME is the tracker.

We resolved Mailtrap's own record to see where the chain terminates. A DNS lookup on mt-link.mailtrap.io returns a CNAME pointing at t.mailtrap.live, answering on 34.96.69.148. The registrable tracking domain behind the whole system is mailtrap.live, and Mailtrap runs its own product on its own mail.

Here is why that matters to you rather than to a sysadmin. When a company you buy from enables Mailtrap click tracking, the links in their email read mt-link.theircompany.com. Not mailtrap.live. Not anything you could recognise as an email service provider. A blocklist built by collecting vendor domains is structurally incapable of catching that, because there is no shared domain to collect. Every customer generates a fresh, respectable looking hostname on a domain you already trust.

Mailtrap is neither the first nor the worst offender here; this is where the whole industry went. It does mean the only durable defence is behavioural: block the request pattern, strip the redirect, recognise a wrapped URL by its shape rather than its hostname. To check a specific message yourself, our guide to how to tell if an email is being tracked covers the manual method.

What Does Mailtrap Tell the Sender About You?

Enough to place you and identify your setup, and the field list is public because Mailtrap documents its webhooks for developers. The webhooks reference shows an open event carrying:

• timestamp. The moment the pixel loaded, which is the moment you looked at the message.
• email. Your address, tied to this specific event.
• ip. Documented as "User IP address," and an IP resolves to a city and an internet provider.
• user_agent. Your mail client, operating system and often your device class.
• message_id and event_id. Identifiers that join this open to the exact message and let the sender count repeats.

The click event repeats all of that and adds one field: url, documented simply as "Clicked URL." The sender learns not just that you read the email but which offer, which article, which button.

Mailtrap's statuses and events glossary is blunter still. Recipient IP is defined as the "IP address of a device or an email server where an email was opened," and "If a message is opened on devices using different IP addresses, multiple Recipient IPs will be recorded." Read the same newsletter on your phone at lunch and your laptop at home, and the sender gets two locations, not one.

What Mailtrap's Tracking Cannot Tell the Sender

Quite a lot, and Mailtrap says so itself rather than pretending otherwise. Its setup guide warns senders that some mailbox providers, browsers and extensions block invisible pixels, that users can refuse to display images, and that in each case "an 'open' event won't be recorded even if an email is opened."

Gmail muddies the numbers in a different direction. Google routes remote images through its own proxy servers, so the IP Mailtrap records is frequently a Google data centre and the user agent belongs to the proxy. Apple goes further: Mail Privacy Protection has preloaded remote content by default since 2021, manufacturing opens for messages nobody read.

Do not mistake any of that for protection. The fetch still happens, the open event still fires, and the timestamp is still yours. Blurring the IP is not the same as refusing the report. Our walkthrough on how to detect email tracking pixels in Gmail shows what the beacon looks like in the raw message source.

Why Email Users Should Care

Mailtrap is developer infrastructure, so the mail it carries is usually the mail you cannot ignore. Password resets, order confirmations, shipping updates, invoices, security alerts, verification codes. Nobody skims a password reset. You open it immediately, from wherever you happen to be standing, often on a phone, often at an odd hour.

That changes what an open signal is worth. A newsletter open tells a marketer their subject line landed. A password reset open, stamped with an IP and a user agent, tells whoever reads the logs roughly where you were at the moment your account needed attention. Same pixel, wildly different sensitivity. And because opens are Mailtrap's default rather than a deliberate choice, plenty of those pixels are firing in transactional mail where nobody ever sat down and decided to measure anything.

Regulators have noticed. Mailtrap now ships Recipient Tracking Opt-Outs, a per recipient switch that stops open and click tracking for one person without unsubscribing them, retroactively covering messages already sent. Its documentation credits France's CNIL recommendation on email tracking pixels, published in the Journal Officiel on 14 April 2026, which gave senders three months to inform recipients and offer an easy way out. That window closed on 14 July 2026. Credit where it is due, very few providers have built a recipient side opt out at all. The catch is that it only works if the sender enables the setting, and you will never know from outside whether they did.

How Do You Block Mailtrap Tracking in Gmail?

Stop the pixel from loading, then handle rewritten links as a separate problem, because no image setting touches them. The reassurance first, since it is what people actually worry about: blocking tracking does not block the email. The receipt still arrives, the reset link still works, the invoice still lands. You are declining to file the report, not declining the message.

1. Turn off automatic image loading. In Gmail, click the gear icon, choose See all settings, stay on the General tab, scroll to Images, select "Ask before displaying external images" and save. No remote image loads without your approval, so no pixel fires, from Mailtrap or anyone else. Per Google's documentation for the setting, the cost lands everywhere: every logo, product photo and signature graphic now sits behind a prompt. Most people undo it within a fortnight.

2. Do not count on Gmail's image proxy. It masks your IP and user agent, which genuinely degrades what Mailtrap collects, but it does not stop the request. Google fetches the pixel on your behalf, Mailtrap logs the open, the webhook fires. Our fuller comparison of ways to block email tracking in Gmail works through each option and its tradeoffs.

3. Strip the pixel instead of hiding every image. An extension running inside Gmail can remove tracking beacons before the message renders, so the request never leaves your machine while normal images still display. Gblock works this way: it blocks known tracking pixel requests, strips known tracking parameters out of links, and pulls a fresh blocklist rather than shipping a frozen one. Being straight about the limits, it is not an anti phishing tool, and no blocklist catches a technique nobody has documented yet.

4. Hover before you click. A rewritten link is an ordinary anchor tag, so image preferences never touch it. Read the status bar. A host in the shape of mt-link.something.com is a Mailtrap wrapper on the sender's own domain, and following it logs your IP, user agent and the destination you chose. Where the real URL is visible inside the wrapper, you can go there directly instead.

Which Blocker Fits Your Setup?

Several tools solve parts of this and none solves all of it. Here is the honest version, with a fuller breakdown in our roundup of email tracker blocker extensions.

The differences that bite with Mailtrap specifically are blocklist freshness and whether the tool touches links at all. Because Mailtrap turns on a sender branded tracking domain the moment click tracking is enabled, a static list of vendor hostnames ages badly here. Half the tools above only handle pixels, which is precisely the half that Gmail's proxy already muddies.

The Bottom Line

If your email came from a Mailtrap sandbox, nothing is watching you, because nothing was ever delivered. If it came from Mailtrap Email Sending, assume the open pixel is live, because that is the default, and assume the links are wrapped if the sender pays for a plan that allows it. You cannot tell either from the outside, and the tracking domain is designed to look like the sender's own. Block the pixel and the question stops mattering: your receipt still arrives, your reset link still works, and the row with your IP address in it never gets written.

Sources: Mailtrap, Sending Domain Setup, Mailtrap, Email Sandbox Overview, Mailtrap, Webhooks, Mailtrap, Statuses and Events, Mailtrap, Recipient Tracking Opt-Outs, Mailtrap, Excluding Links from Tracking, Mailtrap, Automatic Forwarding, CNIL, FAQ on the email pixel recommendation, Google, Display images in Gmail, and Apple, Mail Privacy Protection.