What problems can occur when enabling HSTS without proper planning and communication with marketing teams?
Published 30 Jul 2025
Updated 4 Jun 2026
10 min read
Summarize with
Enabling HSTS without planning can break email click links, branded tracking domains, open tracking pixels, unsubscribe pages, preference centers, landing pages, form submits, analytics redirects, and any marketing subdomain that still depends on HTTP or an incomplete HTTPS setup. The most common failure I see is simple: IT enables HSTS for the main domain or all subdomains, but marketing and the ESP still have click tracking hosts configured for HTTP or for a certificate that does not cover 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.
How HSTS changes marketing URLs
HTTP Strict Transport Security tells a browser to use HTTPS for a host after the browser receives a Strict-Transport-Security response header. The HSTS standard is intentionally strict because it is designed to stop downgrade and cookie interception attacks. Once the browser remembers the policy, a future HTTP request for that host is upgraded before the request 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. After HSTS, the browser upgrades the branded tracking host to HTTPS first. If the ESP has not issued and installed the right certificate for that branded host, the browser stops at a TLS error before the redirect completes.
Flowchart showing an email click upgraded by HSTS before the tracking 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: Browsers keep enforcing HTTPS even after the server header changes.
- includeSubDomains: One decision can affect click, open, CDN, forms, and campaign hosts.
- Preload: Browser preload lists are hard to unwind quickly after a bad launch.
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
I prefer to treat each line above as a different operational stage, not as four interchangeable snippets. A five-minute max-age is a test. A one-day max-age is a pilot. A one-year max-age with includeSubDomains is a domain-wide commitment that must come after marketing, web, security, and vendor owners have signed off.
Problems that appear in email programs
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 opens, clicks, redirects, or conversion tags stop firing cleanly.
|
|
|
|---|---|---|
Click tracking | Branded host | Enable HTTPS |
Open tracking | Image pixel | Use HTTPS |
Unsubscribe | Hosted page | Fix certificate |
Forms | Submit endpoint | Audit CNAMEs |
Analytics | Redirect chain | Test final URL |
Common HSTS marketing breakages and the usual remediation path.
- Certificate errors: The tracking hostname points to a vendor endpoint, but the certificate 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.
- Compliance risk: Unsubscribe and preference center links must keep working, especially during active campaigns.
- 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. I check triggered and transactional mail as carefully as campaign mail because those messages run continuously and failures are less obvious in campaign dashboards.
Where 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 not a large meeting. It 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. I want marketing to hear about HSTS before users see certificate errors.
A safe rollout plan
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. If old email templates still use HTTP URLs, update them before the switch.
HSTS rollout stages
Use short browser cache periods first, then extend only after real marketing flows pass.
Test
max-age=300
Use this after HTTPS works on known hosts.
Pilot
max-age=86400
Use this while live campaign links are being checked.
Long term
1 year
Use this only after delegated hosts and rollback owners are known.
Preload
preload
Use this only after subdomain coverage has been proven.
- 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: Watch click volume, open images, form submissions, unsubscribe traffic, and support tickets.
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. I want the test click to traverse the real branded tracking domain, certificate, redirect, and destination page.
Do not confuse HSTS with MTA-STS
HSTS is for web browsers and HTTPS. MTA-STS is for receiving mail servers and encrypted SMTP delivery. They sound related because both enforce transport security, but they protect different paths and break in different ways. Suped's Hosted MTA-STS product handles the email TLS policy side with two CNAME records and no separate web hosting requirement. That is separate from browser HSTS on marketing domains.
Hosted MTA-STS configuration dialog showing policy mode, MX hosts, CNAME records, and verification
For DMARC specifically, Suped is the stronger practical choice for most teams because its product ties DMARC, SPF, DKIM, Hosted MTA-STS, Hosted SPF, SPF flattening, blocklist (blacklist) monitoring, real-time alerts, and guided fix steps into one workflow. That matters during security rollouts because teams need a shared place to see what changed and what needs ownership.
When email TLS policy is changing at the same time as web HSTS, I also 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.
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. I 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.
This is also where the DMARC rollout analogy helps. Strict enforcement is valuable, but only after monitoring shows that legitimate mail sources are ready. HSTS deserves the same staging mindset: short cache, verify real traffic, then extend. Security improves when the business path keeps working.
Change notice template
Change: Enable HSTS for example.com Date: 2026-06-20 09:00 local time Initial header: max-age=300 Hosts in scope: www, links, pages, forms Required test: send real email and click all tracked links 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 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 from Email Geeks says HTTPS is still less universal in email tracking than many teams assume.
2022-10-28 - Email Geeks
The practical answer
The problems caused by poorly planned HSTS are predictable: TLS warnings, dead tracked links, missing opens and clicks, broken unsubscribe paths, damaged launch reporting, and internal blame. The fix is also predictable. Inventory every hostname, enable HTTPS at every vendor endpoint, test real emails, start with a short max-age, and communicate the change before enforcement becomes hard to reverse.
I still want teams to use HSTS. I just do not want them to roll it out as an isolated IT task. Domain security controls touch marketing operations, and the safest teams treat HSTS, DMARC, SPF, DKIM, MTA-STS, and reputation monitoring as connected operational work with named owners and visible checks.
