What is the HTTP Referrer-Policy header and how does it relate to email sending and hosted images?
Published 9 Jun 2025
Updated 4 Oct 2026
11 min read
Summarize with
Updated on 4 Oct 2026: We clarified referrer privacy, hosted-image failures, and practical testing for email requests.
The HTTP Referrer-Policy header tells a browser or similar client how much referrer information to send when it requests another URL. It controls the separate Referer request header, which is the misspelled but standard HTTP header that can disclose where a request came from. The MDN reference is a concise reference for the allowed policy values.
Referrer-Policy is an HTTP control, not an SMTP header or part of DMARC, SPF, or DKIM. It does not authenticate an email message. It becomes relevant after email content triggers web requests for hosted images, tracking pixels, click redirects, preference centers, mirror pages, or landing pages.
Short answer
- Referrer-Policy controls HTTP requests, not raw email sending.
- It matters when a recipient's client requests web-hosted assets or follows links.
- A final image file rarely initiates another request, but image redirects and surrounding pages can apply the policy.
- The main risk is privacy leakage, not a direct change to inbox placement.
What Referrer-Policy controls
A browser sends a Referer header on many navigations and subresource requests. If a campaign landing page loads an analytics script, a permissive policy can expose the page's path and query string to that server. The modern default limits cross-origin disclosure to the origin, but still sends the path and query string on same-origin requests. A subscriber ID or reset token in those components is sensitive data.
Referrer-Policy gives the site owner a way to reduce that exposure. The W3C spec defines the processing model, while browser documentation explains the practical policy choices. Treat the header as a privacy control first and an analytics control second.
An origin is the combination of scheme, hostname, and port. Different subdomains are different origins, even when the same organization owns them. An origin-only referrer excludes the path and query string. Where the table says "full URL", it means the origin, path, and query string; browsers strip the fragment and any URL username or password, as defined in the W3C spec.
Basic HTTP response headerHTTP
HTTP/1.1 200 OK Content-Type: text/html; charset=utf-8 Referrer-Policy: strict-origin-when-cross-origin
|
|
|
|---|---|---|
no-referrer | No Referer header | Sensitive endpoints |
origin | Origin only, including HTTPS-to-HTTP requests | Origin-only attribution; allows downgrade disclosure |
same-origin | Full URL on same-origin requests; omitted cross-origin | Same-origin web views |
strict-origin | Origin only; omitted on HTTPS-to-HTTP requests | Low-detail sharing |
strict-origin-when-cross-origin | Full URL same-origin; origin cross-origin; omitted on HTTPS-to-HTTP requests | Modern browser default |
no-referrer-when-downgrade | Full URL unless the request downgrades from HTTPS to HTTP | Historical default; exposes cross-origin paths and queries |
origin-when-cross-origin | Full URL same-origin; origin cross-origin, including HTTPS-to-HTTP requests | Allows downgrade disclosure |
unsafe-url | Full URL, including HTTPS-to-HTTP requests | Avoid for campaign pages |
The eight Referrer-Policy values and their use on email-related web resources.
How the policy is applied
The HTTP response header sets a policy for requests made by a document. HTML can also set a document policy with <meta name="referrer"> in the document head before resources load, apply a request-specific policy with the referrerpolicy attribute, or suppress referrer data on a link with rel="noreferrer". These HTML controls are most dependable on web versions and landing pages. Email clients can sanitize message markup or fetch assets through proxies.
Document and element policy examplesHTML
<meta name="referrer" content="strict-origin-when-cross-origin"> <img src="https://cdn.example.net/images/header.png" referrerpolicy="no-referrer"> <a href="https://example.org/" rel="noreferrer">Open page</a>
- Use an element-level referrerpolicy value when one image or link needs a different rule.
- Otherwise, the document policy from the response header or meta element governs the request.
- If no valid policy is supplied, modern browsers default to strict-origin-when-cross-origin; privacy settings can restrict disclosure further.
- A redirect response can update the policy for the next request, but cannot restore referrer details already removed earlier in the chain.
A comma-separated HTTP header uses the last recognized policy. For example, Referrer-Policy: no-referrer, strict-origin-when-cross-origin uses the latter policy when supported and the former as a fallback. The HTML referrerpolicy attribute accepts only one value, as documented in the MDN reference.
CSS background images on web versions and landing pages also generate requests. Inline CSS uses the document policy. An external stylesheet uses the browser default unless its own HTTP response sets Referrer-Policy. Include stylesheet responses when reviewing these pages, following the MDN CSS guidance.
Client controls still win
A user agent can reduce or omit the Referer header for privacy. An email privacy proxy or security scanner can make its own request without preserving the recipient's original context. Treat missing referrer data as normal input, not as proof that a request is invalid.
How email opens and clicks trigger HTTP requests
The sending part of email uses SMTP and DNS-based authentication. Referrer-Policy matters when the recipient's mail client, webmail client, browser, privacy proxy, or security scanner requests a URL. Some requests occur before a human opens or clicks the message because remote content is prefetched or links are scanned. Compliant browsers apply the policy, while proxies and scanners can strip or rewrite the referrer context. A setting in an email platform can look like an email setup option while still controlling HTTP behavior.
Email delivery and opening followed by a hosted image request, redirect or CDN, and Referrer-Policy handling.
- Hosted image requests go to an HTTP server, which records the request and returns response headers.
- A tracking pixel is fetched like a small image, often through a tracking endpoint. A no-referrer policy does not stop the pixel loading or remove identifiers from the requested URL.
- A click-tracking URL can redirect to the final site and change the request policy on the way.
- A mirror page is a normal web document that can request its own subresources.
- A campaign landing page should avoid leaking full URLs to third-party assets.
Email authentication
SPF checks whether a sending server is authorized for the envelope sender domain or HELO domain. DKIM verifies a domain signature. DMARC checks whether a passing SPF or DKIM result meets the matching rules for the visible From domain. Mail servers evaluate these during message handling.
- Mail servers and mailbox providers perform the checks.
- The checks use DNS records, signatures, and envelope domains.
- The result is an authentication outcome and any related policy handling.
Referrer policy
Referrer-Policy answers how much page URL context is sent during later HTTP requests. It affects web traffic around the email, not the authentication result of the email itself.
- Browsers, webmail clients, proxies, and scanners make the requests.
- The request can expose a page URL, an origin, or no referrer data.
- The result is more or less referrer data in web logs.
Hosted images and redirects
An image tag in an email points to a URL, and the recipient's client requests that URL. The context that starts the request determines whether it includes a Referer header. Native email clients, webmail clients, privacy proxies, and security scanners do not handle that context consistently.
A plain PNG or JPEG response does not load its own subresources, so a Referrer-Policy header on the final image file has little practical effect by itself. It cannot change the Referer header already received by that image server. Redirects, HTML wrappers, web views, and CDN handoffs matter more. If an image endpoint returns a 302 to a CDN URL, the redirect response can update the policy for the next request. The redirect URL does not automatically become the next request's referrer, so inspect the actual headers rather than assuming it does.
Image endpoint redirect with policyHTTP
HTTP/1.1 302 Found Location: https://cdn.example.net/images/header.png Referrer-Policy: no-referrer Cache-Control: private, max-age=300
Do not treat image headers as email headers
When a platform adds a Referrer-Policy setting under email setup, check which HTTP responses it controls. It can apply to hosted images, link redirects, web versions, or landing pages. The label can live in email setup because the assets belong to email campaigns.
|
|
|
|---|---|---|
Final PNG or JPEG | Does not change the request already received | The server has already received its request context |
Image redirect | Can set the policy for the next request | Referrer disclosure to the CDN |
Click redirect | Can set the policy for the next navigation | Disclosure during the redirect chain |
Web view | Sets the document policy for later requests | Disclosure to page assets and linked destinations |
What each resource response can control, rather than a fixed privacy risk rating.
This also connects to the image hosting hostname. The hostname decides where requests go, who sees logs, how TLS is handled, and which reputation signals surround the resource.
Email HTML pointing to a hosted image URL, followed by a redirect and CDN request log.
Why hosted email images return 403 errors
Hotlink protection can return 403 Forbidden when it requires a Referer value that an email client does not send. The referrer policy controls disclosure; the image host's access rule causes the rejection. A policy label in browser developer tools is not itself an HTTP error.
A Referer value is easy to forge, and legitimate requests omit it. For email images, a rule that requires a website referrer therefore rejects legitimate client or proxy requests and is not reliable authentication.
- Check the failing image request's HTTP status and the rejection reason in server or CDN logs before changing the policy.
- Test the same image without Referer and with an origin-only value. Opening the URL directly does not reproduce the email request context.
- For public campaign graphics, configure the image host to accept legitimate requests without Referer, including privacy proxy requests.
- For private assets, use access controls appropriate to the resource instead of trusting Referer. Adding a policy to the final image response cannot repair an earlier rejection.
Policy choice for email teams
For most email-related web endpoints, use strict-origin-when-cross-origin or no-referrer. The first keeps useful same-origin detail and limits cross-origin disclosure to the origin, with no referrer on HTTPS-to-HTTP requests. The second blocks referrer sharing entirely and fits sensitive redirect or asset paths.
Referrer exposure by policy
Use this as a quick privacy benchmark when choosing a policy for campaign pages, web views, and hosted asset redirects.
Low exposure
no-referrer
No Referer header is sent.
Balanced exposure
strict-origin-when-cross-origin
Same-origin detail stays useful, while cross-origin detail is reduced.
High exposure
unsafe-url
Full campaign URLs can appear in external logs.
Keep personal data and email addresses out of campaign URLs. When a one-time token is necessary for a reset or preference link, use no-referrer, avoid unnecessary third-party resources on that page, and give the token a short lifetime. A stricter Referrer-Policy reduces referrer exposure, but the destination still receives its requested URL and that URL can enter logs, forwards, or support tickets.
Conservative campaign page headerHTTP
HTTP/1.1 200 OK Content-Type: text/html; charset=utf-8 Referrer-Policy: no-referrer
Use HTTPS everywhere for hosted assets and links. A secure policy and secure transport solve different problems. Referrer-Policy controls what context travels with a request, while HTTPS protects the request in transit. The related issue is covered in more detail under HTTPS links and images.
Practical default
- Set strict-origin-when-cross-origin explicitly on general pages so the intended behavior is testable.
- Use no-referrer on sensitive endpoints and remove personal data from query strings.
- Verify the initiating document policy, the first request, every redirect response, and the final request in asset chains.
- Treat the header as web hygiene, then keep authentication and reputation work separate.
Testing and monitoring
Test with a real message, not only with a web server header check. Send a campaign-style email to seed inboxes, open it in webmail and native clients, then inspect image and link requests. Record the actual chain: email HTML, tracking URL, redirect response, final image or landing page, and the referrer visible at each hop. Account for proxy caching, remote-content blocking, and automated fetches; an image request is not proof of a human open.
In browser developer tools, open the Network panel and inspect each relevant request. Compare Referer under Request Headers with Referrer-Policy under Response Headers. Browser logs do not show requests made separately by a mail privacy proxy, so check the image host's server logs for those requests.
Suped's product supports the surrounding email checks. Its email tester inspects a real delivered message, while domain health checks cover authentication and DNS. These checks do not expose every browser request header, so use browser network logs or server logs to verify the Referer value at each HTTP hop.
Email tester
Send a real email to this address. Suped shows a results button when the test is ready.
?/43tests passed
Referrer-Policy does not replace DMARC monitoring. If a domain has spoofing exposure, broken DKIM signing, or unauthorized senders, a web header will not fix it. Suped's DMARC reporting platform supports investigation of sending sources and SPF or DKIM failures. Use browser or server logs to investigate HTTP referrer behavior.
Email tester sample report showing total score, email preview, issue summary, and per-section results
During a review, ask for exact response examples. Which host and path emit the header? Does it appear on the image endpoint, redirect endpoint, web version, landing page, or every relevant response? Accept a platform default only when the team can identify the affected URLs and chosen policy value.
Campaign endpoint review
Identify every campaign-related host, inspect each response and redirect, keep subscriber data out of URLs, use HTTPS, and choose no-referrer or strict-origin-when-cross-origin based on the endpoint's sensitivity. Record the owner and policy value for each endpoint. Keep DMARC, SPF, and DKIM checks separate so the team does not mistake web header hygiene for email authentication.
