What is the HTTP Referrer-Policy header and how does it relate to email sending and hosted images?
Matthew Whittaker
Co-founder & CTO, Suped
Published 9 Jun 2025
Updated 19 Aug 2025
7 min read
When sending emails, especially those rich in content like images, understanding how browsers interpret and display elements is crucial. One often overlooked but important aspect of web security and privacy that can indirectly affect email display, particularly with hosted images, is the HTTP Referrer-Policy header. This header dictates what information a browser sends about the originating page when it requests external resources.
While emails themselves are not web pages, they often contain elements, such as hosted images or tracking pixels, that are fetched from web servers. When a user's email client (which is essentially a browser engine rendering HTML) requests these external assets, it behaves much like a web browser accessing a page. This is where the Referrer-Policy comes into play, influencing the data transmitted with those image requests.
The policies can prevent sensitive URLs from being inadvertently exposed, which is a significant privacy concern. However, in the context of email, these policies can also impact analytics, hotlinking prevention, and even the successful loading of images if not configured correctly. Let's delve into what this header entails and its implications for email sending and hosted images.
The HTTP Referrer-Policy header is a security mechanism that provides control over the information sent in the Referer header. The Referer header (yes, it's a common misspelling that stuck) indicates the address of the web page that a user was on before navigating to the current page. When an email client displays an HTML email that includes externally hosted images, the browser engine within the client makes an HTTP request to fetch these images. The Referer header in this request will typically contain the URL of the email (or the sender's domain if the email client is proxying requests).
The primary purpose of the Referrer-Policy is to prevent the unintentional leakage of sensitive data through the Referer header, particularly when transitioning between secure (HTTPS) and insecure (HTTP) contexts, or across different origins. For example, if a user clicks a link from a secure page with sensitive information in its URL, the Referer header could expose that sensitive data to the destination server. Mozilla provides a comprehensive overview of the Referrer-Policy header.
There are several values for the Referrer-Policy, each offering a different level of control over what information is sent. Understanding these values is key to implementing an effective policy. The policy is typically set via an HTTP response header or through HTML attributes.
Common referrer policies
No-referrer: No Referer header is sent at all.
No-referrer-when-downgrade: This is often the default browser behavior. The Referer is sent for requests from HTTPS to HTTPS, or HTTP to HTTP. It is not sent from HTTPS to HTTP, which prevents secure URL leakage to insecure destinations.
Origin: Only the origin (scheme, host, and port) is sent in the Referer header, regardless of where the request goes.
Same-origin: A Referer is sent for same-origin requests, but not for cross-origin requests.
Strict-origin-when-cross-origin: The full URL is sent for same-origin requests, only the origin for cross-origin requests, and no Referer from HTTPS to HTTP.
Unsafe-url: The full URL is always sent. This is unsafe and should generally be avoided.
Referrer-Policy and hosted images in emails
The relationship between the Referrer-Policy header and email sending largely centers on hosted images. Unlike web pages, emails don't inherently send a Referer header directly from the email itself when it's opened. However, when an email client fetches an image linked within the email, it makes a standard HTTP request to the image's URL. This request can, and often does, include a Referer header.
For image-hosting services or CDNs, the Referer header can be used for various purposes, such as preventing hotlinking (where other websites directly link to your images, consuming your bandwidth) or for analytics. If your image hosting server has a strict Referrer-Policy (e.g., same-origin), and the email client's domain (or the proxy it uses) is considered a different origin, the image may not load correctly, or the server might return a 403 Forbidden error. This is a common pitfall for marketers using external image hosting.
Modern email clients, especially privacy-focused ones, might also modify or strip the Referer header by default to protect user privacy, regardless of your specified policy. This behavior means you can't always rely on the Referer header for critical image loading or tracking mechanisms within emails.
Impact on email sending and deliverability
While the Referrer-Policy header doesn't directly impact the deliverability of emails (i.e., whether they land in the inbox or spam), it can significantly affect how your emails are displayed and how you collect data from them. If images fail to load due to a restrictive Referrer-Policy, the email's design can break, leading to a poor user experience and potentially reducing engagement.
From a security standpoint, ensuring your image hosting serves content with an appropriate Referrer-Policy can protect sensitive information if your email links contain query parameters or identifiers. It also prevents image hijacking or unauthorized usage of your hosted assets, which could indirectly impact your brand's reputation.
For analytics, if you rely on the Referer header to track where image requests originate, a strict policy might limit the data you receive. For example, if you use no-referrer, you won't get any referral data. This is particularly relevant for tracking pixels within emails, which are often tiny images used to confirm email opens. Without the Referer data, contextual information about the email might be lost.
Implementing referrer-policy for email assets
When setting up your email marketing campaigns, consider the Referrer-Policy for any domains hosting your email assets, such as images, logos, or tracking pixels. The goal is typically to balance privacy with functionality.
Choosing the right policy
For email images, a policy like no-referrer-when-downgrade or strict-origin-when-cross-origin is often a good balance. These policies generally ensure images load correctly while minimizing privacy risks by preventing the full URL from being sent when downgrading protocols or for cross-origin requests.
HTTPS for all assets
Always host your email images and other assets on HTTPS to maintain security and ensure consistent Referer header behavior. Browsers are increasingly defaulting to stricter policies for HTTP requests, which can lead to images not loading if your email is viewed in a secure context but references insecure image URLs.
You can set the Referrer-Policy via the HTTP response header on your image server. For example, in your web server configuration (like .htaccess for Apache or nginx.conf for Nginx), you can add a line like this:
Apache .htaccess exampleapache
Header set Referrer-Policy "no-referrer-when-downgrade"
Alternatively, for individual images, you can use the HTML referrerpolicy attribute on the <img> tag directly, though support can vary across email clients. W3Schools provides a good reference for the HTML referrerpolicy attribute.
Views from the trenches
It’s not often that we email marketers encounter HTTP headers directly, but when dealing with hosted assets, they become relevant. Here's what some folks in the community are saying.
Best practices
Always host email images and assets over HTTPS to ensure consistent referrer behavior and better security.
Choose a Referrer-Policy like 'no-referrer-when-downgrade' or 'strict-origin-when-cross-origin' for your image server to balance privacy and functionality.
Use separate subdomains or CDNs for hosting email images to isolate them from your main website's referrer policies.
Common pitfalls
Using a very restrictive Referrer-Policy (e.g., 'no-referrer' or 'same-origin') on image servers can prevent images from loading in cross-origin email clients.
Relying solely on the Referer header for email open tracking via pixels, as many email clients and privacy settings will strip or modify this header.
Not considering the referrer policy if you're using hotlinking protection on your image server, as it might block legitimate email client requests.
Expert tips
Test your emails with hosted images across various email clients and devices to verify consistent image loading and identify any referrer-related issues.
If your ESP offers Referrer-Policy settings for hosted assets, consult their documentation to understand the default behavior and available customizations.
For advanced analytics, consider alternative tracking methods that don't rely on the Referer header, such as unique image URLs or pixel parameters.
Expert view
Expert from Email Geeks says the Referrer-Policy is crucial for managing sensitive information leakage, especially when dealing with external resources embedded in emails. This policy ensures that personal data embedded in URLs isn't exposed during image requests.
2024-02-15 - Email Geeks
Marketer view
Marketer from Email Geeks says their ESP added a Referrer-Policy option in their email setup, which initially caused confusion. It turned out to be related to how hosted images were fetched and if any referrer information should be sent with those requests.
2024-01-20 - Email Geeks
Final thoughts on referrer-policy
The HTTP Referrer-Policy header might seem like a niche technical detail, but its implications for email sending are significant, especially concerning hosted images and tracking links. Proper configuration ensures your email content displays as intended, maintaining a professional image and delivering a consistent user experience. It's a key part of web security that bleeds into the email world.
By understanding how these policies affect the Referer header when email clients fetch external resources, you can prevent broken images, protect user privacy, and ensure your email campaigns function optimally. Always prioritize security and privacy in your email marketing practices.
