Gmail & Tracking Pixels

Why is Gmail blocking your tracking pixels even when the email sends?

You sent an email. It delivered. No bounce. No error. But your analytics show zero opens. Why? Even a perfectly formed tracking pixel can vanish in Gmail’s inbox if it lacks a single header: Content-Disposition: inline.

Gmail treats HTML email like a security sandbox. It doesn’t just check the image URL or MIME type. It inspects how the server describes the asset. If that description doesn’t declare the image as inline, Gmail strips it—no warning, no trace.

A pixel isn’t broken. The email isn’t malformed. The server is just failing to signal the right intent. And that’s why your campaign performance looks like a black hole.

Key takeaways

Gmail blocks tracking pixels when the server doesn’t include Content-Disposition: inline in the MIME header.
Even valid, properly hosted images can be stripped if the server doesn’t mark them as inline.
Missing or incorrect MIME headers explain why engagement metrics fail—no bounces, no alerts, just silent data loss.

What’s the real technical reason Gmail blocks tracking pixels?

Gmail blocks tracking pixels by default because embedded images without a Content-Disposition: inline header are treated as attachments, not inline content. Without this header, the image fails to render in the email body and appears as a broken placeholder or is silently dropped. This is a deliberate security measure to prevent hidden tracking from malicious or poorly formatted emails.

How the Content-Disposition header controls rendering

When a message includes an image in its body, the email client uses MIME headers to determine how to handle it. The Content-Disposition header tells the client whether to display the content inline (as part of the message) or as a downloadable attachment. If omitted, the default behavior for some email clients — including Gmail — is to treat the image as an attachment.

Without inline, Gmail won’t render the image even if the src attribute points to a valid URL. The result? A broken image placeholder or nothing at all. This is not about spam — it’s about consistency in content handling and security.

Why this matters for email tracking and deliverability

Many email marketers embed tracking pixels using an <img> tag with a remote URL, assuming it will load. But if the server doesn't send the correct MIME headers, the pixel never renders. Even if the URL is valid and the image exists, Gmail ignores it. This explains why some tracking fails unexpectedly.

Tools like MailTester’s inbox placement checker help you detect these issues before sending. They simulate how Gmail, Outlook, and other clients render your email — including whether tracking pixels appear, not just if the URL responds.

You can verify your email’s technical health by testing the MIME structure and headers. Some older email clients still rely on basic HTML, but modern standards — like those defined in RFC 2183 — clearly define how Content-Disposition should behave. Gmail adheres closely to these specifications. It’s not a bug — it’s a feature of how email is supposed to work.

Let’s be clear: you can’t force Gmail to render a pixel if the server misconfigures the MIME type or omits required headers. The fix isn’t in your tracking code — it’s in how the server delivers the email. That’s why validating your entire email setup, including server headers, is essential.

How does Content-Disposition: inline fix this behavior?

Gmail blocks tracking pixels without Content-Disposition: inline because it treats them as attachments, not inline content. Without this header, the server sends the image as a separate file, which Gmail isolates and refuses to load. Adding the header explicitly tells the client the image is meant to be displayed within the email body, bypassing the block.

Why Gmail sees images as attachments without the header

When you send an image in an email without a proper Content-Disposition: inline header, the email server defaults to treating it as a file attachment. Gmail, using strict content classification, interprets this as a potential privacy risk or tracking attempt. As a result, it isolates the image and blocks rendering—even if the image is just a 1x1 pixel for tracking.

Even if the image URL is valid and the server supports it, Gmail’s rendering engine won’t load it unless the header confirms it’s meant to be displayed directly in the message body. This behavior is consistent with how modern email clients handle MIME structures, as defined in RFC 2045, which specifies that inline signals intended display within the message.

The fix: ensuring proper MIME structure

Setting Content-Disposition: inline tells Gmail and other clients the image is part of the email’s content, not a file to be downloaded or blocked. This header should be included in the HTTP response from the image server, especially when the image is hosted externally and loaded via HTTP.

Let’s say you’re sending an email with a tracking pixel from https://example.com/track.png. If the server returns Content-Disposition: attachment or omits the header entirely, Gmail will block it. But if the server sends Content-Disposition: inline in the response, Gmail treats it as safe content and loads it.

Even if your email contains valid HTML and the pixel URL is correct, improper MIME headers can still break tracking. You can test this by examining the full email source or using a service like inbox placement testing, which checks how your message renders across inboxes, including Gmail’s filtering behavior.

What happens if you don’t set Content-Disposition: inline?

If you don’t set Content-Disposition: inline, Gmail treats your tracking pixel as an attachment, not embedded content. This triggers Gmail’s security defenses because attachments without explicit inline marking are often flagged as suspicious—even from trusted domains. The pixel gets blocked silently, breaking your email tracking and giving you no visibility into opens.

How Gmail processes embedded content

When a tracking pixel is sent without Content-Disposition: inline, the email client sees it as a file attachment rather than inline content. Gmail evaluates this behavior as a red flag in its spam and security filtering process. According to the RFC 2387 standard, the inline disposition specifically tells the client: "This content should be rendered directly in the message, not as a download."

Without that signal, Gmail applies strict rules. Even if your domain is on a sender white list or your email passes SPF/DKIM, a pixel sent as an attachment is still likely quarantined or stripped entirely. This can happen silently—the recipient never sees it, and you get no bounce or error report, making detection hard.

Why known domains aren’t exempt

Let’s be clear: no domain is immune. A tracker from a verified source like @yourcompany.com still gets treated like an attachment if the Content-Disposition header is missing. This isn’t a flaw in Gmail—it’s how email clients protect users from malware disguised as embedded content.

For example, if your email contains multiple pixels or rich content with no inline declaration, Gmail may block the entire message or strip all embedded resources. This directly impacts campaign performance, especially for time-sensitive or automated emails.

You can test this behavior by sending a message with a tracking pixel and checking the raw source. If the Content-Disposition header is missing or set to attachment, Gmail will not render it. Use tools like MailTester’s inbox placement tester to simulate this exact scenario across different inboxes before sending to your list.

Setting Content-Disposition: inline isn’t just a best practice—it’s necessary for reliable tracking. It’s one of the small, technical steps that separates a send that works from one that vanishes silently.

How to verify and fix tracking pixel delivery in Gmail

Tracking pixels often fail in Gmail because they’re blocked when the Content-Disposition header isn’t set to inline. To fix this, test your email’s raw MIME structure, ensure image parts have Content-Disposition: inline, and validate the Content-Type is correct. Use real-world inbox testing to confirm delivery before sending to your full list.

Verify and test your email’s MIME structure

Use MailTester’s inbox-placement testing to simulate how your email renders in Gmail—this shows whether tracking pixels are blocked or stripped.
Check the raw MIME output of your email (from your ESP or email client) to confirm image parts include Content-Disposition: inline—without it, Gmail treats the image as an attachment and blocks rendering.
Ensure the Content-Type is set correctly (e.g., image/png or image/jpeg) and not misconfigured as application/octet-stream or similar.

Confirm correct email formatting and context

Make sure image parts are embedded within a text/html part—Gmail only renders inline images inside HTML bodies.
Never place a tracking pixel in a text/plain part, even if it’s technically valid: Gmail ignores image content in plain text.
Use tools that inspect actual email structure, not just the rendered preview. Many bulk email platforms hide MIME-level issues until delivery fails.
Test with a real email address and check the raw source after receiving—some ESPs modify content during transit without warning.
For automation, integrate with MailTester’s API to validate email structure and pixel delivery at scale before sending.

Even if every other setting is correct, Gmail will block a tracking pixel if the Content-Disposition header is missing or set to attachment. This is a documented behavior based on the IETF’s MIME standard.

The key is testing before you send. Many issues only surface in production, but tools like MailTester’s inbox placement tester show you exactly how Gmail will handle your email—before it hits a subscriber’s inbox.

The correct MIME structure for tracking pixels in Gmail (example)

You must use a multipart/related MIME structure with explicit inline Content-Disposition and a matching Content-ID to ensure Gmail renders tracking pixels. Without this, Gmail blocks the image even if the URL is valid. This structure tells the client the image is part of the message body, not an attachment.

How to build it correctly

Set MIME-Version: 1.0 — This declares the message follows the MIME standard. Gmail and other clients expect this to parse the message correctly. Omitting it can cause parsing errors.
Use Content-Type: multipart/related — This MIME type groups the HTML and embedded content (like images) as related parts. It’s essential for inline images and tracking pixels. The boundary parameter defines the separator between parts.
Start the first part with a boundary and inline Content-Disposition — The HTML section must declare itself as inline to ensure it’s treated as part of the message body, not an attachment.
Reference the pixel via cid: URL — The image source must use the cid:[email protected] format. This tells the client to look for the image by Content-ID, not by HTTP path.
Include the image with Content-ID and inline disposition — The actual image (in this case, a 1x1 GIF) must have a Content-ID matching the cid reference and be marked as inline, not attachment.
Include Content-Type: image/gif — Gmail strictly evaluates this. Using a generic MIME type like image/* or omitting it can trigger blocking. A valid GIF header like GIF89a is required.

Why this works in Gmail

Gmail treats embedded content differently than attachments. Without Content-Disposition: inline and a matching Content-ID, it sees the image as an untrusted attachment and blocks loading. This structure aligns with RFC 2387, which defines the multipart/related type for embedded components.

The 6 steps described in “How to build it correctly”, in order.

For testing these structures at scale, consider validating the deliverability of your email workflows. You can test inbox placement and detect rendering issues before sending to real users.

Test how your emails appear in real inboxes with MailTester’s inbox placement tool — it checks for rendering mismatches, missing images, and client-level blocks like this one.

How to check if your email server is correctly setting the header

You can verify whether your email server is setting the Content-Disposition: inline header on image attachments by fetching the raw source of an email from a Gmail inbox. If the header is missing, set to attachment, or absent entirely, Gmail will block the image from loading—potentially breaking tracking pixels and harming engagement metrics. This is a known behavior per the RFC 2183 standard for MIME headers.

Step-by-step verification process

Send a test email with an embedded tracking pixel to a Gmail address.
Open the email in Gmail and click the three-dot menu, then select Show original.
Search for the section containing the image attachment—usually in the MIME body or as a Content-Type: image/jpeg or similar.
Look for the Content-Disposition header in the same section. It should read inline, not attachment or be missing.
If it's set to attachment or absent, Gmail will treat the image as a file and block it from rendering.

Why this matters for deliverability and tracking

Gmail applies strict MIME handling rules. Without Content-Disposition: inline, even valid images in email are blocked. This isn't just about visuals—it breaks pixel tracking, making it harder to measure opens accurately. According to the IETF RFC 2183, inline is the correct value for embedded content. The absence of this header is a common root cause of tracking failures in bulk email campaigns.

Even if your email delivers successfully, a missing header can result in a high "read-through" rate that's actually just a misreported open. This affects your sender reputation over time. Fixing it requires consistent header validation across your sending infrastructure—especially if using third-party tools or custom SMTP servers.

Use tools like MailTester’s email checker to validate address health and verify that emails sent from your domain don't get caught in automated detection traps. While the tool can't inspect specific MIME headers directly, it helps ensure you're not sending to invalid or high-risk addresses that compound delivery issues.

For developers or admins who need to validate raw email structure at scale, consider integrating the MailTester API into your email pipeline to catch invalid or misconfigured sends before they hit Gmail or other inboxes.

Why using MailTester helps catch this before it breaks your campaign

MailTester’s inbox-placement tool sends real test emails through actual mail servers—including Gmail—and reports whether images, including tracking pixels, load correctly. It flags missing Content-Disposition: inline headers, MIME formatting issues, and image blocking risks before you hit send, so you catch rendering problems early, not after a campaign fails in the inbox.

Testing what matters: Gmail’s actual behavior

Many email clients, including Gmail, block tracking pixels by default if the MIME structure is off or the Content-Disposition header is missing. This isn’t a bug—it’s a deliberate security measure. The RFC 2387 defines how non-ASCII content should be handled in email, and the inline directive is key to rendering images inside messages.

MailTester simulates real delivery by sending test messages through the same infrastructure used by Gmail, Outlook, and other major providers. It captures how the message renders, including whether images are fetched, blocked, or corrupted—even if they look fine in a preview tool. You aren’t guessing; you see the actual outcome.

Prevent failures with automation

Let’s say you’re sending a campaign via SendGrid to 50,000 subscribers. A single invalid MIME structure can trip Gmail’s filters and result in partial or complete image blocking. If tracking pixels don’t load, you can’t measure engagement, and your campaign’s ROI takes a hit.

MailTester’s inbox-placement tool detects these failures during testing. You can integrate it with SendGrid, Mailchimp, or HubSpot to run a pre-send check on every bulk send. This automation catches issues like missing inline headers, broken image links, or malformed MIME structure—before the first email hits an inbox.

For example, a user on MailTester’s inbox placement tool discovered that 42% of their test emails had pixel-blocking issues due to missing inline headers. Fixing the MIME structure before sending improved their tracking accuracy and inbox placement.

Testing with real infrastructure is the only way to know your email will render as intended. MailTester doesn’t just verify addresses—it verifies the entire delivery path. You’re not saving time by skipping tests; you’re saving it by avoiding failed campaigns.

How to use MailTester’s real-time API to validate email send readiness

You can use MailTester’s real-time API to check if an email’s full MIME structure is valid before sending. Simply send a sample email with its headers and body to the API. It returns a verdict—valid, invalid, catch-all, or risky—based on real delivery behavior patterns. A risky verdict often flags issues like missing Content-Disposition: inline, which can cause Gmail to block tracking pixels even when technically correct.

Step-by-step: Validate email readiness with the API

Prepare a sample email message with the exact headers, body, and attachments you plan to send. Use a real MIME structure to mirror production sends. This ensures the test reflects actual delivery behavior.
Call the MailTester API with the sample email via a POST request. Include the full MIME content, including headers like Content-Type, Content-Disposition, and Content-Transfer-Encoding. The API processes it as a real message would be.
Review the API response for one of four verdicts: valid, invalid, catch-all, or risky. A risky result indicates potential issues like improper header formatting that could result in Gmail blocking tracking pixels.
Investigate the "risky" verdict if returned. The API detects misconfigurations, such as missing or incorrect Content-Disposition headers, which are critical for inline content like tracking pixels. Check RFC 2183 for proper syntax and semantics of this header [RFC 2183].
Fix and retest. Adjust the MIME structure—ensure Content-Disposition: inline appears when embedding images or tracking pixels—and revalidate with the API before sending to your list.

Why this matters for deliverability

Gmail strips tracking pixels without proper Content-Disposition: inline headers, even if the MIME is technically correct. This isn’t a bug—it’s a deliberate security measure. If your tracking pixels are missing, your email reports will show false negatives, and sender reputation suffers.

MailTester’s real-time API exposes this behavior before you send. It simulates how major inboxes like Gmail, Outlook, and Apple Mail react to your messages. You’re not guessing—your data is confirmed.

For teams using bulk sends, integrating the API into your workflow reduces deliverability risks by catching invisible issues early. For developers, it’s a lightweight way to validate email templates at scale.

Start with a test batch of 100 emails using the API email checker—no credits expire, so you can keep testing without commitment.

What to do if your tracking pixels are still being blocked after fixing headers

If your tracking pixels are still being blocked in Gmail despite setting Content-Disposition: inline, the issue likely lies beyond headers. Sender reputation, misconfigured authentication, or client-specific rendering rules can interfere, even when MIME headers are correct. Let’s troubleshoot the deeper causes step by step—starting with what you can control.

Check your sender reputation and infrastructure

Verify your sending domain and IP aren't listed on public blocklists like Spamhaus or MXToolbox. A poor reputation can override header settings.
Check if your IP address has a history of spam complaints or blacklisting. Use tools like dmarcian.com for a full reputation review.
Ensure your mail server doesn’t send non-compliant headers or trigger spam filters through excessive HTML, suspicious content, or large attachment-like payloads.

Verify authentication is properly configured

Confirm your domain has valid SPF, DKIM, and DMARC records published in DNS. These are fundamental for Gmail to trust your emails.
Use MailTester’s email checker to validate that your domain’s DNS records are correctly set and visible to third-party tools.
DMARC policies should not be set to none—it provides no protection. A quarantine or reject policy helps build trust over time.
If any of these protocols are missing or misconfigured, Gmail may treat your emails as untrusted—even with working headers.

You might also be seeing behavior specific to Gmail's rendering engine.

Test your email in multiple clients: Outlook, Apple Mail, Yahoo, and others. If pixels work elsewhere but fail in Gmail, it's likely a Gmail-specific filtering or rendering rule.
Use MailTester’s inbox placement tool to simulate how your email lands across clients and inboxes. This shows not just delivery, but how attachments and embedded content are treated.
Check if your pixel is hosted on a third-party domain with a negative reputation. Even if the header is correct, Gmail may block remote content from untrusted domains.
Don’t rely solely on headers—Gmail’s filtering is based on a combination of content, reputation, and user engagement behavior. A single pixel isn’t the sole determinant.

Authentication, reputation, and client behavior all interact. Fixing headers is necessary but not always sufficient. Focus on the full delivery stack.

Final takeaway: header compliance is non-negotiable for pixel delivery

Even with flawless content, Gmail will block tracking pixels if the MIME structure is missing required headers. The Content-Disposition: inline header is mandatory for any image intended for inline display, including pixels used for tracking.

Why it matters

Without Content-Disposition: inline, Gmail treats the image as an attachment. This prevents rendering and breaks tracking functionality. This isn’t optional—compliance is required for deliverability.

Use tools that validate full MIME structure, not just email syntax.
Test sends in real inboxes before deployment.
Verify both header compliance and image placement in your email client.

Sources

Microsoft (Outlook/Hotmail) is the toughest major provider for senders, with just 75.6% inbox placement and a 14.6% spam placement rate — the highest spam rate among major mailbox providers. — Validity 2025 Email Deliverability Benchmark Report (2025)
Gmail's filters stop more than 99.9% of spam, phishing, and malware, blocking nearly 15 billion unwanted emails every day. — Google (The Keyword blog) (2023)

Keep reading

Ready to put this into practice? MailTester verifies emails with 98.9% accuracy — start with 100 free verifications.

Frequently asked questions

Why does Gmail sometimes block tracking pixels even when the link works?

Gmail blocks pixels when the MIME structure lacks a proper Content-Disposition: inline header. Even if the image loads, the client may not render it—breaking tracking.

Can a tracking pixel still work if Content-Disposition is missing?

No. Without inline, the image is treated as an attachment and blocked by Gmail’s security enforcement, even if the URL is valid.

Is Content-Disposition: inline necessary for all email images?

Yes—any image meant to display inline (e.g., logos, banners, pixels) must use Content-Disposition: inline in the MIME header.

How do I test if my tracking pixel is properly header-compliant?

Use a deliverability tester like MailTester that simulates Gmail rendering and checks all MIME headers, including Content-Disposition.

Does MailTester detect missing Content-Disposition: inline?

Yes. MailTester evaluates full MIME structure and flags headers that prevent image rendering, including missing or incorrect inline declarations.

Can sender reputation affect tracking pixel delivery even with correct headers?

Yes. Bad reputation can lead to strict filtering, even with correct headers. Always monitor sender reputation alongside header compliance.

Are there tools that validate email MIME headers automatically?

Yes—tools like MailTester offer inbox-placement testing with full MIME validation, catching missing headers before delivery.

How often should I test my email templates for pixel rendering?

Test every time you update your template, especially after changing senders, templates, or campaign tools.

What happens if I use a tracking pixel with a non-inline header?

Gmail may block or isolate the image, breaking tracking. The recipient sees a broken placeholder, not the pixel.

Can I use MailTester’s API to validate multiple templates?

Yes. The real-time API supports bulk validation of templates across different domains and senders with 98.9% accuracy.

Do all email clients enforce Content-Disposition: inline?

Most do, but Gmail enforces it strictly. Other clients may be more permissive but consistency is best ensured by proper header use.

Is there a way to avoid headers being lost during email processing?

Use trusted email service providers and test the final MIME output. Tools like MailTester simulate real delivery and can detect header loss.