What problems can occur when enabling HSTS without proper planning and communication with marketing teams?
Published 30 Jul 2025
Updated 20 Oct 2026
13 min read
Summarize with
Updated on 20 Oct 2026: We clarified HSTS subdomain coverage and strengthened marketing teams' testing and rollback steps.
Enabling HSTS without planning can break email click links, open tracking pixels, unsubscribe pages, preference centers, landing pages, form submissions, and analytics redirects when an affected host has incomplete HTTPS support. A common failure is simple: IT enables HSTS with subdomain coverage, but marketing and the email service provider (ESP) still have branded tracking hosts that lack working HTTPS or a certificate covering the branded hostname.
HSTS itself is not the problem. It is a useful browser security control. The problem is treating it like a web server header only. Marketing email turns domains into a chain of redirects, CNAMEs, tracking hosts, hosted unsubscribe pages, CDN assets, and vendor-managed certificates. If those pieces are not inventoried and tested before the header goes live, users hit certificate errors and marketing teams lose trust in their campaign data. These failures affect the post-click experience and measurement. HSTS does not determine SMTP delivery or inbox placement.
How HSTS changes marketing URLs
HTTP Strict Transport Security tells a browser to use HTTPS for a host after it receives a valid Strict-Transport-Security response header over HTTPS. A header sent over HTTP is ignored. The federal HSTS guidance explains this protection against connection downgrades. Once the browser remembers the policy, a future HTTP request for a covered host is upgraded before it leaves the browser.
That browser behavior creates the marketing risk. An email can contain a tracked link that begins as HTTP. Before HSTS, the user clicks it, the browser contacts the ESP's tracking endpoint, and the endpoint redirects the user to the destination page. When the browser has an applicable cached or preloaded HSTS policy, it upgrades the branded tracking host to HTTPS first. If the ESP has not installed a trusted, unexpired certificate that matches the branded hostname and supplies a valid chain, the browser stops at a TLS error before the redirect completes. HSTS prevents the user from bypassing that certificate warning.
Email click flow showing HSTS upgrading a tracking link to HTTPS before the TLS check and redirect.
The risky HSTS settings
The most dangerous rollout is a long cache duration combined with subdomain coverage before every delegated marketing host has working HTTPS.
- Long max-age: Each valid HTTPS response carrying the header refreshes the expiry. Removing the header leaves existing cached policies active.
- includeSubDomains: One decision can affect click, open, CDN, forms, and campaign hosts.
- Preload: The directive alone does not add a domain to browser lists. Accepted submissions take effect through browser releases and can affect first visits; removal is also delayed.
HSTS header examples
Strict-Transport-Security: max-age=300 Strict-Transport-Security: max-age=86400 Strict-Transport-Security: max-age=31536000; includeSubDomains Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
These are example stages, not mandatory durations or interchangeable headers. A five-minute max-age limits a new dynamic policy to five minutes after the last received header. A one-day value is a possible later pilot. Test includeSubDomains with a short max-age only after every affected web host has working HTTPS. Extending cache duration and requesting preload are separate decisions that need approval from marketing, web, security, and vendor owners.
Which marketing subdomains inherit HSTS?
Scope follows the hostname in the URL, including any parent policy the browser has learned. A header on the main website does not automatically cover every marketing hostname.
- A policy on example.com without includeSubDomains covers example.com only.
- A policy on example.com with includeSubDomains also covers links.example.com and every deeper subdomain, including future hosts.
- A policy on www.example.com covers that host and, with includeSubDomains, its descendants. It does not cover the sibling links.example.com.
- A vendor-managed CNAME does not exempt the branded hostname from a parent policy. HTTPS still needs a certificate matching the hostname in the URL.
A subdomain cannot opt out of an active parent includeSubDomains policy. Confirm the policy-setting host before approving the rollout; the federal HSTS guidance explains why base-domain coverage includes delegated subdomains.
Email link failures and missing tracking data
The first visible symptom is often a browser warning after someone clicks an email link. That makes HSTS feel like a campaign issue, even though the root cause is usually a domain security change made outside the email workflow. The second symptom is quieter: reporting numbers change because clicks or conversion tags stop firing cleanly. Open tracking is affected only if the mail client or image proxy applies an HTTPS upgrade and that HTTPS path fails; browser HSTS behavior does not establish how every email client fetches pixels.
|
|
|
|---|---|---|
Click tracking | Branded host | Enable HTTPS |
Open tracking | Image pixel | Verify HTTPS in the actual mail-client or proxy path |
Unsubscribe | Hosted page | Fix HTTPS and verify the unsubscribe completes |
Forms | Submit endpoint | Verify HTTPS on the actual form submission endpoint |
Analytics | Redirect chain | Test every redirect hop and confirm conversion attribution |
Common HSTS marketing breakages and the usual remediation path.
- Certificate errors: The tracking hostname points to a vendor endpoint, but the certificate is expired, untrusted, missing an intermediate, or does not cover the branded hostname.
- Broken redirects: A link wrapper, link shortener, or old redirect service accepts HTTP but has incomplete HTTPS handling.
- Lost metrics: Open pixels, click redirects, and attribution tags fail before the user reaches the destination.
- Unsubscribe failures: Broken unsubscribe or preference center pages prevent subscribers from completing their request. Verify the action succeeds, rather than checking only that the page loads.
- Blame loops: Marketing blames the agency or ESP, IT blames templates, and the real issue is a changed browser policy.
Older campaigns are easy to miss. A team can update current templates and still leave lifecycle messages, sales sequences, invoices, webinar reminders, and passwordless login emails using older HTTP tracking settings. Check triggered and transactional mail as carefully as campaign mail because those messages run continuously and failures are less obvious in campaign dashboards. Test links in already delivered messages too, because changing current templates does not repair the URLs those messages contain.
Where HSTS rollout communication fails
HSTS rollouts fail when the change owner sees only the web application and not the domain. Marketing sees the domain differently. A single brand domain can have DNS records delegated to the ESP, event platform, CDN, form provider, analytics system, and agency-managed landing page stack. The header is small, but the ownership map is not.
IT-only rollout
- Scope: Main website and web server configuration.
- Testing: Homepage, login pages, and core application routes.
- Risk: Delegated marketing hosts are missed.
Coordinated rollout
- Scope: Website, marketing links, vendor CNAMEs, and old templates.
- Testing: Real emails, redirects, unsubscribe pages, forms, and tracking pixels.
- Risk: Remaining gaps are visible before the long max-age is used.
The practical fix is a short owner list and a change notice that says exactly which hostnames are covered, when the header changes, which campaigns need testing, and who can pause the rollout. Marketing needs to hear about HSTS before users see certificate errors.
How to roll out HSTS safely
A safe rollout starts with an inventory. List every hostname under the domain that marketing uses or influences, then confirm that HTTPS works with the exact hostname users will request. Do not test only the final landing page. Test the tracking host, redirect host, image host, form endpoint, and preference center host.
The next step is vendor coordination. If a branded click domain points to an ESP, the ESP must provision HTTPS for that branded host before HSTS enforcement. If the vendor requires a certificate validation record, add it before the HSTS header is extended to subdomains. Confirm hostname coverage, trust, expiry, and the complete certificate chain at every edge location. If old email templates still use HTTP URLs, update them before the switch. Name the certificate renewal owner and confirm automated renewal before extending max-age, so the tracking domain keeps working after launch.
HSTS rollout stages
These example cache durations limit new dynamic policies. Increase scope and duration separately after real marketing flows pass.
Test
max-age=300
Start on the chosen host after its HTTPS path works.
Pilot
max-age=86400
Example later pilot; test subdomain coverage with a short cache first.
Long term
1 year
Extend only after affected hosts and certificate renewal owners are confirmed.
Preload
preload
Optional separate submission after all web subdomains support HTTPS.
- Inventory hosts: Export DNS and collect marketing-owned domains, subdomains, CNAMEs, and old campaign templates.
- Verify HTTPS: Check every hostname directly, including branded click, open, forms, and hosted preference pages.
- Coordinate vendors: Ask the ESP and other providers to enable certificates before the HSTS header is expanded.
- Pilot first: Start with a short max-age and send real internal test emails through production tracking.
- Monitor impact: Record baseline click-through and conversion rates, then compare them with post-change results alongside TLS errors, form submissions, unsubscribe completions, and support tickets. Pause expansion if real links fail.
For a broader view of DMARC, SPF, DKIM, and domain health before a security change, run a domain health check. It will not prove every HSTS path by itself, but it helps catch related authentication and DNS issues before teams stack more security changes onto the same domain.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
After the domain check, send test messages through the same production ESP paths that subscribers use. Preview tools alone are not enough because a preview can skip the final link wrapping or use a different redirect route. The test click must traverse the real branded tracking domain, certificate, redirect, and destination page. Test desktop and mobile browser paths after visiting the policy-setting parent over HTTPS to cache its header, then repeat in a fresh profile to check first-visit behavior. Preload rules still apply in fresh profiles. Confirm that campaign parameters survive redirects and that the form or unsubscribe action completes.
Plan rollback before enforcement
An HSTS rollback is slower than an ordinary header rollback because browsers cache the policy. Removing the header does not erase policy that users already received. A browser that reaches the policy-setting host over valid HTTPS can process max-age=0 and remove that host's dynamic policy, but separately cached subdomain policies remain until each expires or is cleared by that host. A child host's max-age=0 does not override a still-active parent includeSubDomains policy. Preloaded policy requires a separate removal process and updated browser releases.
Dynamic HSTS removal header
Strict-Transport-Security: max-age=0
- Restore valid TLS first: Fix the certificate or HTTPS endpoint because HSTS users cannot bypass the error to reach an HTTP fallback.
- Stop extending the policy: Serve max-age=0 over valid HTTPS on every host whose dynamic policy you need to remove, including any parent imposing includeSubDomains. Browsers must revisit each policy-setting host to receive the change.
- Handle preload separately: Request removal and keep HTTPS working while the change reaches browser releases.
- Pause affected sends: Stop campaigns that would distribute a broken tracking or unsubscribe hostname.
- Record the evidence: Save the header, certificate result, affected hosts, campaign IDs, and first observed failure time.
The incident owner should tell marketing whether existing messages can recover after the HTTPS fix or whether a replacement send is required. Link URLs inside delivered email cannot be edited, so restoring the original branded host is usually the fastest way to recover old and active messages. A working tracking endpoint can redirect an old link to a new destination, but that cannot rescue a request blocked before the TLS handshake completes.
Do not confuse HSTS with MTA-STS
HSTS is for web browsers and HTTPS. MTA-STS lets a receiving domain publish TLS requirements that supporting sending mail servers apply when delivering to its MX hosts. They protect different connections and fail in different ways. Suped's Hosted MTA-STS product hosts the email TLS policy through two CNAME records without a separate web server. TLS-RPT collection uses an additional optional DNS record. That is separate from browser HSTS on marketing domains.
Hosted MTA-STS/TLS-RPT configuration dialog showing policy mode, MX hosts, CNAME records, TLS reporting, and verification
During an email security rollout, Suped's DMARC reporting helps teams identify authentication failures, while its TLS-RPT reporting shows SMTP TLS successes and failures. Browser HSTS failures require separate click-path testing.
When email TLS policy is changing at the same time as web HSTS, verify MTA-STS separately. Mixing the two checks leads to false confidence: a clean MTA-STS setup does not mean marketing click links work, and a working HTTPS website does not mean inbound SMTP TLS policy is correct. An MTA-STS enforce policy with an incorrect MX list or invalid mail-server certificate can delay inbound delivery and eventually cause failure for supporting senders.
Separate the controls
- HSTS: Browser policy for HTTPS on web hosts and marketing links.
- MTA-STS: SMTP policy for how other mail servers deliver messages to you.
- DMARC: Authentication policy for domain-based email identity and spoofing protection.
What to tell marketing before the switch
Marketing does not need every detail of the browser cache model. Marketing needs to know which links, hosts, and reporting numbers can change. Keep the message concrete: the date of the change, the hostnames affected, the test plan, the vendor owner, the rollback contact, and the campaign freeze window if one is needed.
Minimum communication checklist
- Hostnames: Name the exact marketing, tracking, form, and landing page hosts in scope.
- Timing: Avoid launches during major sends, sales periods, or automated campaign migrations.
- Testing: Require real test emails and clicks through production tracking domains.
- Ownership: Assign one owner for DNS, one for ESP settings, and one for campaign validation.
Name who approves progression beyond the pilot and who stops it when a test fails. Use working unsubscribe actions and successful form submissions as acceptance criteria, alongside the click-through and conversion-rate baseline. Keep the change window separate from a major campaign launch so the teams can investigate a failure without an active send adding more broken links.
Change notice template
Change: Enable HSTS for example.com Scheduled window: YYYY-MM-DD HH:MM local time Policy-setting host: example.com Initial header: Strict-Transport-Security: max-age=300 Initial scope: example.com only Subdomain coverage: off until all affected web hosts pass HTTPS tests Preload: no submission planned Required test: send real email and click all tracked links Test profiles: parent policy cached, then fresh browser profile Pass criteria: clicks, forms, and unsubscribe actions succeed Monitoring: compare click-through and conversion rates with baseline Rollback owner: security@example.com Marketing owner: lifecycle@example.com Vendor owner: esp-support ticket 12345
The notice does not need to be long. It needs to prevent surprise. If marketing knows a short HSTS pilot is happening, they can pause high-value sends, test the ESP backend, and avoid losing a day to support tickets that look like campaign defects.
Views from the trenches
Best practices
Inventory every marketing subdomain before HSTS, including click, open, form, and CDN hosts.
Confirm the ESP has a matching certificate before any branded tracking host is forced to HTTPS.
Use a short max-age first, then extend it only after campaign links and forms pass testing.
Common pitfalls
Enabling includeSubDomains before checking delegated hosts makes one header affect every team.
Assuming all email links already use HTTPS leaves older templates and redirects untested.
Treating HSTS like a web-only change hides the impact on email metrics and attribution.
Expert tips
Keep rollback expectations clear, because browser HSTS cache can outlast the DNS fix.
Test real campaign messages, since link wrapping can differ from preview and builder modes.
Document owners for each CNAME so IT knows who must approve certificate changes first.
Marketer view
Marketer from Email Geeks says HSTS itself is not the issue; missing prep work is what breaks customer-facing links.
2022-10-28 - Email Geeks
Marketer view
Marketer from Email Geeks says HTTPS is still less universal in email tracking than many teams assume.
2022-10-28 - Email Geeks
Frequently asked questions
Yes. If the browser upgrades a branded tracking host to HTTPS and the ESP has not provisioned a valid certificate for that hostname, the user sees a TLS error before the redirect completes.
No. Marketing should ask for staging, testing, and clear ownership. HSTS is useful when every marketing hostname and vendor-managed endpoint has working HTTPS first.
A short value such as 300 seconds limits a new dynamic policy while you test. Confirm every affected HTTPS endpoint before adding includeSubDomains, then test that coverage with a short cache too. A short pilot does not remove an existing preload entry or instantly shorten policies already cached in other browsers.
Not for every browser. Serve max-age=0 over valid HTTPS on the host that set the dynamic policy, and clear any relevant parent policy too. A subdomain cannot override an active parent includeSubDomains policy. Separately cached subdomain policies need their own removal. Preload removal depends on later browser releases, so restore valid HTTPS first.
No. Suped's DMARC reports show email authentication results, not browser HSTS or click-path failures. Test branded links in browsers and monitor the tracking endpoint separately.
No. HSTS enforces HTTPS for web browsers. MTA-STS tells sending mail servers how to use TLS when delivering mail to your inbound mail servers.
