HSTS preload: should you submit your domain? (decision flow + the risks)

HSTS in 60 seconds — what it does, what preload adds

HSTS is a one-way ratchet. Once you send the Strict-Transport-Security header, any browser that receives it will refuse to make plain HTTP connections to your domain for the duration of your max-age. That's the point. You're not asking browsers to prefer HTTPS — you're instructing them to hard-fail on anything that isn't.

The header looks like this:

Strict-Transport-Security: max-age=63072000; includeSubDomains; preload

Without HSTS, every first visit to your site is a potential SSL stripping target. The user types example.com, the browser makes an HTTP request, and an attacker sitting in the middle can intercept that before the redirect to HTTPS ever happens. HSTS eliminates that window — but only after the first visit. That gap is called the TOFU problem: Trust On First Use.

Preload closes the TOFU gap entirely. Instead of waiting for a browser to receive your header once, your domain gets hardcoded into a list that ships inside Chrome, Firefox, Safari, and Edge. Before the browser makes any network request at all, it already knows your domain demands HTTPS. There's no first visit over HTTP. Ever.

That distinction matters. HSTS without preload is strong. HSTS with preload is categorical. The tradeoff is that getting off the preload list is slow and painful, which we'll get to.

If you're still getting up to speed on security headers more broadly, the security headers guide for small business covers the full stack before you start optimizing individual policies.

---

The four header requirements before you can submit

Google maintains the Chrome preload list and enforces specific technical requirements through hstspreload.org. These aren't suggestions — the submission tool will reject you if any of them fail.

1. Serve a valid HTTPS response on your root domain. Your apex domain (example.com) must respond over HTTPS without certificate errors. Expired certs, self-signed certs, hostname mismatches — any of these block submission. Cloudflare's Universal SSL handles this automatically for most setups. If you're managing your own certificates, make sure auto-renewal is airtight before you commit to preload.

2. Redirect HTTP to HTTPS. http://example.com must redirect to https://example.com. A 301 is standard. The redirect itself can't set the HSTS header — only the HTTPS response should carry it.

3. The max-age must be at least one year. Specifically, max-age must be at least 31536000 seconds. Most practitioners set it to 63072000 (two years) to give themselves breathing room during future audits. Don't set it lower just to reduce risk — if you're submitting to preload, you're committing to long-term HTTPS infrastructure anyway.

4. The includeSubDomains directive is mandatory. This is where most domains hit trouble. includeSubDomains means every subdomain — mail.example.com, dev.example.com, legacy-app.example.com, that old Jenkins instance someone set up in 2019 — must serve valid HTTPS. No exceptions. The preload list entry applies to the entire domain tree.

The preload directive must also be present in the header, though that's trivially easy to add once the other four conditions are met.

Before you touch any of this, run your domain through the Surface Tools header scanner to get a full picture of what your current headers look like and whether your TLS configuration is solid enough to commit to.

---

The reversibility problem (and why preload feels permanent)

Here's the part of the HSTS preload requirements conversation that most blog posts skip over.

You can submit a removal request at hstspreload.org. Google will process it. Your domain will eventually come off the list. But "eventually" means the updated list has to ship in a new browser release, and then that release has to propagate to enough users that you can consider yourself actually removed. That process takes six to twelve weeks at minimum, often longer in enterprise environments where Chrome auto-updates are managed by IT policy.

During that window, users on older browser versions — or any browser that cached the preload list before your removal — will still hard-fail on HTTP. If your HTTPS infrastructure breaks while you're waiting for removal to propagate, those users get an error page, not your site.

This isn't theoretical. Organizations that go through M&A, domain migrations, or infrastructure consolidation hit this constantly. A subsidiary domain gets preloaded, the parent company acquires them, and now there's a hard constraint on the new infrastructure because someone submitted to preload three years ago.

The practical consequence: treat preload submission as a permanent architectural decision, not a header tweak. If your org regularly spins up subdomains for short-term projects, runs staging environments without HTTPS, or doesn't have centralized certificate management, preload will create incidents.

The includeSubDomains requirement compounds this. You're not just committing your root domain to HTTPS-only — you're committing every subdomain you'll ever create, including ones that don't exist yet. If a developer creates internal-tool.example.com on HTTP six months from now, browsers that have your preload entry will refuse to load it. That's a support ticket at minimum, a production outage at worst.

---

When preload is worth it (decision flowchart)

Work through this in order. If you answer no to any question before the final one, stop and fix that condition first.

Does your root domain serve valid HTTPS with a trusted cert? → No: Fix your TLS setup first. Come back after.

Do all existing subdomains serve valid HTTPS? → No: Audit every subdomain. Either migrate them to HTTPS or retire them. Tools like Surface Tools can help enumerate exposed subdomains and their TLS state.

Do you have a process for ensuring new subdomains are HTTPS from creation? → No: Build that process first. DNS automation, cert provisioning workflows, documentation. CrowdStrike Falcon, NinjaOne, and similar RMM/management platforms can enforce this at the infrastructure level if you're managing endpoints centrally.

Is your HTTPS infrastructure stable enough to survive a 6–12 month commitment without major changes? → No: Wait. If you're mid-migration or planning a platform change, preload is a constraint you don't want yet.

Do you operate a high-value domain where TOFU attacks are a realistic threat model? → Yes: Preload is worth it. Financial services, healthcare portals, any domain handling authentication or sensitive data — these are good candidates.

→ No: HSTS without preload, combined with a long max-age and includeSubDomains, gives you most of the protection for a fraction of the commitment.

The honest answer for most small and mid-market businesses: HSTS without preload is sufficient. Preload is the right call for high-value targets that have already solved subdomain HTTPS hygiene and have stable infrastructure.

---

Submitting to hstspreload.org — the actual steps

The actual submission process is straightforward once your header is correct.

Step 1: Set the header correctly. Your HTTPS response must include:

Strict-Transport-Security: max-age=63072000; includeSubDomains; preload

Deploy this and let it propagate. If you're on Cloudflare, you can set this in Transform Rules. On Microsoft 365 / Exchange Online with custom domains, you'll need to handle HSTS at the reverse proxy or CDN layer — Microsoft's infrastructure doesn't expose raw header configuration for custom domains at the MX level.

Step 2: Validate at hstspreload.org. Enter your domain. The tool checks all four requirements and returns pass/fail with specific error messages. Common failures: missing includeSubDomains, max-age below threshold, subdomain serving HTTP.

Step 3: Submit. Once all checks pass, hit submit. You'll get a confirmation and your domain enters a queue.

Step 4: Wait. Initial inclusion typically takes a few weeks. The site shows status as "pending." Once Chrome ships the updated list, status changes to "preloaded." Firefox, Safari, and Edge consume the same list on their own schedules.

You don't need to do anything after submission — no annual renewal, no re-verification. The entry persists until you request removal.

---

If you need to remove yourself — the 6–12 week reality

Go to hstspreload.org, find the removal form, and submit your domain. That part takes two minutes.

What follows does not.

The Chrome team processes removal requests and the updated list ships with the next Chrome release. Major Chrome releases happen roughly every four weeks. So best case, you're looking at four weeks before the updated binary starts shipping. Then you need adoption — users need to actually update. In consumer environments with auto-update enabled, you might hit 70% adoption in two to three weeks after release. In managed enterprise environments where IT controls Chrome versioning, it can take months.

Firefox maintains its own import schedule from the Chrome list, and it's not synchronized. Same with Safari. You could be off the Chrome list and still on Safari's shipped copy for another release cycle.

The operational implication: if you're removing yourself because something broke — your cert lapsed, a critical subdomain can't support HTTPS, you're in a migration — you need to fix the underlying HTTPS problem in parallel with requesting removal. You cannot wait for removal to propagate and then fix your site. That window is too long.

Set internal DNS overrides or proxy rules to force HTTPS internally during the transition. Communicate clearly with users if there's a public-facing impact. And document why you got into this situation, because organizations that end up needing HSTS rollback usually have a process problem upstream that preload just made visible.

---

Use Surface Tools to validate security headers and TLS findings across your domains before you make any preload decisions. It's a faster way to find the subdomain gaps and misconfigurations that will block submission or create incidents post-commit.