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 25 May 2026
7 min read
Summarize with
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 the clearest short reference for the allowed policy values.
It is not an SMTP header, it is not part of DMARC, SPF, or DKIM, and it does not authenticate an email message. It enters email work because emails load web resources: hosted images, tracking pixels, click tracking redirects, preference centers, mirror pages, and landing pages. Those are HTTP requests, so web security headers start to matter.
Short answer
- Scope: Referrer-Policy controls HTTP requests, not raw email sending.
- Email: It matters when a recipient's client requests web-hosted assets or follows links.
- Images: A final image file rarely uses the policy itself, but image redirects and surrounding pages can.
- Risk: The main issue is privacy leakage, not direct inbox placement.
What the header actually controls
A browser sends a Referer header on many navigations and subresource requests. If a user is on a campaign landing page and the page loads an analytics script, that script request can include the landing page URL as the referrer. If that landing page URL contains a campaign id, subscriber id, or reset token, the next server can receive data that should have stayed private.
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. I treat the header as a privacy control first and an analytics control second.
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 | Nothing | Strong privacy |
origin | Scheme and host | Clean attribution |
strict-origin | Origin, HTTPS only | Good default |
strict-origin-when-cross-origin | Full same-site, origin cross-site | Browser default |
unsafe-url | Full URL | Avoid |
Common Referrer-Policy values used around email landing pages and hosted assets.
Where it enters email sending
The sending part of email uses SMTP and DNS-based authentication. Referrer-Policy starts after the message is opened or clicked, when the recipient's mail client, webmail client, browser, privacy proxy, or security scanner requests a URL. That difference matters because a setting in an email platform can look like an email setup option while still controlling HTTP behavior.
Flow from email open to hosted image request, redirect, CDN, and Referrer-Policy handling.
- Hosted images: The image URL is an HTTP resource, so its server can return response headers.
- Tracking pixels: The open pixel is fetched like a tiny image, often through a tracking endpoint.
- Click redirects: The first click URL can redirect to the final site and set a policy on the way.
- Mirror pages: A web version of the email is a normal page that can load many subresources.
- Landing pages: Campaign pages should avoid leaking full URLs to third-party assets.
Email authentication
DMARC, SPF, and DKIM answer whether a message is authorized to use a domain. They are evaluated during mail handling before the user interacts with links or images.
- System: Mail servers and mailbox providers.
- Data: DNS records, signatures, and envelope domains.
- Result: Authentication pass, fail, or 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.
- System: Browsers, webmail, proxies, and scanners.
- Data: Page URLs, origins, and redirect paths.
- Result: More or less referrer data in web logs.
Hosted images and redirects
Hosted images are where the question gets subtle. An image tag in an email points to a URL. The recipient's client requests that URL. The request to fetch the image can include a Referer header in browser-like contexts, but native email clients and privacy proxies handle this inconsistently.
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. The useful cases are redirects, HTML wrappers, web views, and CDN handoffs. If an image endpoint first returns a 302 to a CDN URL, the response header can affect how much referrer data follows to the next request.
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 be for hosted images, link redirects, web versions, or landing pages. The label can live in email setup because the assets belong to email campaigns.
|
|
|
|---|---|---|
Final image | Low | Log noise |
Image redirect | Medium | CDN leakage |
Click redirect | High | Full URL leakage |
Web view | High | Third-party assets |
How Referrer-Policy usually relates to common email-adjacent resources.
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.
Infographic showing email HTML, an image URL, a redirect, and a CDN log.
Policy choice for email teams
For most email-related web endpoints, I prefer strict-origin-when-cross-origin or no-referrer. The first keeps useful same-site detail and limits cross-site leakage to the origin. The second blocks referrer sharing entirely and is the simplest choice for 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 full URL leaves the current site.
Balanced exposure
strict-origin-when-cross-origin
Same-site detail stays useful, cross-site detail is reduced.
High exposure
unsafe-url
Full campaign URLs can appear in external logs.
Avoid putting personal data, email addresses, subscriber ids, or one-time tokens in URLs. A stricter Referrer-Policy reduces exposure, but it does not repair a URL design that leaks secrets into logs, screenshots, forwards, analytics systems, and support tickets.
Conservative campaign page headerHTTP
HTTP/1.1 200 OK Content-Type: text/html; charset=utf-8 Referrer-Policy: no-referrer Content-Security-Policy: upgrade-insecure-requests
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
- General pages: Use strict-origin-when-cross-origin unless analytics needs prove otherwise.
- Sensitive URLs: Use no-referrer and remove personal data from query strings.
- Asset redirects: Verify what the first response, redirect response, and final response return.
- Deliverability: Treat this as web hygiene, then keep authentication and reputation work separate.
Testing and monitoring
I test this 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 the image and link requests. The goal is to see the actual chain: email HTML, tracking URL, redirect response, final image or landing page, and the referrer visible at each hop.
Suped's product helps with the surrounding checks because the email tester can inspect a real message while domain checks cover authentication and DNS. For most teams, Suped is the best overall practical DMARC platform for this workflow because it turns authentication findings into fix steps instead of leaving raw reports for someone to decode. Use the email tester to send a message and review the delivered result, then use domain health checks to confirm the domain's broader setup.
Email tester
Send a real email to this address. Suped opens the report when the test is ready.
?/43tests passed
Preparing test address...
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 brings DMARC, SPF, DKIM, hosted SPF, hosted DMARC, hosted MTA-STS, issue detection, real-time alerts, and blocklist (blacklist) monitoring into one workflow so the web hygiene checks do not distract from authentication basics.
Email tester sample report showing total score, email preview, issue summary, and per-section results
When I review a change like this, I ask for the exact response examples. Which host emits the header? Which path emits it? Is it on the image endpoint, the redirect endpoint, the web version, the landing page, or all of them? A platform default is acceptable only when the team can explain the affected URLs and the chosen policy value.
Views from the trenches
Best practices
Ask vendors which HTTP hosts and paths receive the policy before changing campaign settings.
Test the final image URL and every redirect response because each hop can change logging.
Keep personal data out of campaign URLs, even when using a restrictive referrer policy.
Common pitfalls
Teams often confuse web response headers with SMTP headers and review the wrong logs.
Image files get checked alone, while redirects and web versions create the real exposure.
Analytics teams sometimes choose unsafe-url to preserve reports and expose full URLs.
Expert tips
Start with strict-origin-when-cross-origin, then tighten sensitive endpoints to no-referrer.
Document which endpoint owns the setting so future email changes do not alter web privacy.
Pair the header review with HTTPS checks, because transport and referrer policy differ.
Expert from Email Geeks says the header belongs to HTTP behavior, so email teams should look at landing pages and asset hosting before blaming SMTP.
2024-01-24 - Email Geeks
Marketer from Email Geeks says platform settings can appear under email setup even when they control hosted assets connected to campaigns.
2024-01-24 - Email Geeks
What to do next
Referrer-Policy is a web privacy header that becomes relevant to email when email content uses web resources. It does not authenticate the message and it does not decide inbox placement. It controls how much URL context gets passed during later HTTP requests around opens, clicks, hosted images, redirects, mirror pages, and landing pages.
The safest workflow is simple: identify every campaign-related host, inspect each response and redirect, avoid full subscriber data in URLs, use HTTPS, and choose no-referrer or strict-origin-when-cross-origin based on the sensitivity of the endpoint. Then keep DMARC, SPF, DKIM, MTA-STS, and reputation monitoring in a separate checklist so the team does not mistake web header hygiene for email authentication.
