Retiring a Domain Without Breaking It

A year after the rebrand, the renewal invoice for the old domain lands in your inbox. The redirect still works, nobody really visits anymore, and dropping the name seems like a no-brainer. But that old domain still has a few jobs nobody told you about.

Browsers may still enforce its HSTS policy. DNS records may still point at services you cancelled. Old email addresses may still unlock accounts. The redirect covers none of that.

Here's what to check before you switch anything off, in which order, and why the registration goes last.

Whether the redirect itself is still needed is covered in post-migration monitoring. For the mechanics of the redirect, start with URL redirects explained.

Key Takeaways

• Stopping the redirect and releasing the registration are separate decisions. Retire each service with a named owner and an inventory of what still depends on it.
• HTTPS goes last. If you plan to switch it off one day, cached HSTS policies and any preload entry set the pace, so start the wind-down early.
• Remove the DNS record before you cancel the service. Keep the old resource under your control until the record's TTL has run out, then let it go.
• Mail has two end dates. When legitimate sending stops, publish restrictive SPF and DMARC records and retire the old DKIM keys. Publish a null MX only when the domain no longer needs to receive anything.
• Ninety quiet days start a review. Check the inventory, the slower usage cycles and client confirmations first, and decide on the registration separately.

What retiring a domain actually means

A retired domain still has an owner. It keeps its registration, a redirect, a few protective records and someone who reviews it on a set date.

1. The HSTS policy that outlives the site

Browsers that saw the old domain's HSTS header keep enforcing it until the policy runs out or gets replaced. Their clock starts at the last header they received, not at your announcement.

The mechanism is in redirecting a domain that used HSTS. For a retirement, two facts matter. A browser that holds the policy sends the visitor to HTTPS before any request leaves the machine, and a certificate error under HSTS can't be clicked through.

Getting rid of the policy

A name that keeps redirecting over HTTPS can keep its policy. The wind-down only matters if you intend to switch HTTPS off one day. Then start early, because three things make it slower than it looks. A lower max-age only reaches browsers that come back and receive it. Each new header resets that browser's expiry to the time of receipt plus the new max-age. Keep sending the same positive value, and returning browsers keep renewing the policy. And a subdomain can't clear a parent policy sent with includeSubDomains. Only the parent can.

From your side, the only way to clear a policy early is a header with max-age=0, and browsers only honor it over a working HTTPS connection. So HTTPS goes last. Keep a valid certificate until every policy you ever sent has expired. Count each max-age from the last day you sent it, and take the latest date. If the domain is preloaded, send the header without the preload directive and request removal. That may take 6 to 12 weeks to reach most Chrome users, and longer for other browsers. The domain keeps serving HTTPS with a valid HSTS header while it waits.

2. Dangling DNS: the record that outlives the service

A DNS record that points at a cancelled service stays in your zone until someone removes it.

help.old-product.com was a CNAME to a helpdesk vendor, status.old-product.com pointed at a status page service, the app lived on a cloud host. Each record says: for this name, go to that provider. When the resource is deleted, the record keeps saying it.

Microsoft calls this a dangling DNS entry and names the outcome: subdomain takeover. If the name can be claimed again at that provider, whoever claims it answers for your subdomain. They control what the name serves, so they can get a valid certificate for it and read any cookie the parent domain scoped to its subdomains. Some providers verify domain ownership first. Not all do. CNAME records are the usual way in, and OWASP lists NS, MX and A records as exploitable too.

The fix is an order of operations. Remove the record, wait out its TTL, then cancel the service, in that order. Resolvers can keep handing out the old answer until the TTL runs out, so traffic can keep arriving at the old resource. Keep it under your control until the window has passed, then release it. Then walk the zone: every CNAME, every NS delegation, every MX, every A record on a cloud address you no longer hold. That includes the record for the redirect service itself.

A wildcard redirect on the retired domain catches the subdomains you forgot, with two conditions. A wildcard only answers for names that don't exist in the zone, so it only helps once every leftover record at that name is gone, not just the CNAME. And a wildcard certificate covers one level. A certificate for *.old-product.com answers for help.old-product.com, not for eu.help.old-product.com. It also needs DNS validation. On redirect.pizza that means a wildcard A or CNAME record plus an NS record that delegates _acme-challenge, so redirect.pizza can publish the TXT record the check looks for.

3. Mail: the domain keeps receiving, and anyone can send as it

Mail routing doesn't know the product is gone. Neither do the address books of everyone who ever had a contact on the old domain.

Two problems, two end dates. Inbound first. Mail may still arrive at old addresses as long as something answers for the name. Deleting the MX records doesn't stop it: without an MX, senders fall back to the A or AAAA record. Move the addresses you still need. When the domain no longer needs to receive anything, publish a null MX record. That's one MX with preference 0 and a single dot as the hostname, written as 0 ., and no other MX beside it. Senders learn on the first attempt that the domain accepts no mail.

Outbound has its own end date: the day legitimate sending stops. The UK National Cyber Security Centre publishes the records for exactly this case. An SPF record of v=spf1 -all and a DMARC record with p=reject. Optionally, a wildcard DKIM record with an empty public key, the revoked-key form from RFC 6376. A wildcard never overrides a record that exists, so delete the old selectors too. These records don't stop anyone from sending a forged mail. They give receivers what they need to recognize and refuse it, and the decision stays with the receiver. None of it stops a lookalike domain.

Then there are the accounts registered with an address on the old domain. Password resets go to the mailbox, and the mailbox goes wherever the MX points. Move those accounts to addresses on a domain you'll keep, before the mail is switched off.

4. Expiry: whoever registers it next inherits what still points at it

A retired domain that lapses isn't gone. Sooner or later it becomes registrable again, with your history attached.

The buyer gets whatever still points at the name: the inbound links, the muscle-memory traffic, the mail sent from that day on. PyPI documented the attack in 2025, after the ctx package was hijacked that way in 2022. An attacker registers the expired domain, sets up a mail server and requests password resets for accounts tied to it. Accounts that rely on that mailbox alone for recovery are at risk of takeover. PyPI now checks those domains daily and unverifies an address once its domain enters the redemption period. Between early June and mid-August 2025, it unverified more than 1,800 addresses.

Google's advice for a site move is to keep the redirects for as long as possible, generally at least 1 year. The registration has to outlast the redirect, the HSTS policy, the mail records and every account reset. The renewal fee is the cheapest security control on this list. For a typical .com, that's less than a large pizza.

Everyone watches the hit counter on an old domain. Nobody keeps the list of vendor logins, SaaS trials and support portals that still send their password resets to an address on it. The counter drops to zero, somebody lets the registration go, and a stranger with a mail server starts receiving the resets. My rule: keep paying for the name until that list is empty, not until the counter is.

Michel Bardelmeijer, Tech Lead at redirect.pizza

5. Machines don't read a redirect the way browsers do

The visitors you can't see are the ones on api.old-product.com. Integrations, webhooks, SDKs, mobile apps that never updated, cron jobs at customers you lost touch with. A browser follows a 301 without asking. A script may not. curl doesn't follow a redirect unless you tell it to with -L. Libraries that do follow will often turn a POST into a GET on a 301, which is why 307 and 308 exist. The differences are in the status codes article.

So on an API hostname a redirect can be a breaking change. Treat it as one until your clients prove otherwise.

Announce a date, migrate every client you can reach, and keep the old hostname answering until the last one has moved. Where a redirect is the only option, return a 308 instead of a 301, so a client that does follow keeps its method and body. Two more things have to hold. The client has to follow at all, and authentication has to keep working at the destination.

What happens to credentials on a cross-host redirect is the client's choice, not the status code's. curl drops the Authorization header unless told otherwise, and several libraries do the same. Test with the clients you actually have.

The order of operations

Four phases, in dependency order. The redirect sits in the middle, and an HSTS wind-down, if you need one, starts before it. The registration comes last.

Prepare

• Inventory what points at the name: DNS zone, certificates, mail addresses and the accounts behind them, API hostnames, print.
• Name an owner and a review rhythm per hostname and per attached service.
• Decide whether HTTPS on the old name will ever be switched off. If yes, start the HSTS wind-down now: lower max-age, and if the domain is preloaded, drop the preload directive and request removal.
• Set the registration to auto-renew.

Move

• Put the redirect in place with a certificate on every hostname, and a wildcard for the subdomains that have no record of their own.
• Migrate the mail addresses you keep and the accounts behind them.
• Announce the date to API clients and migrate every one you can reach. Where a redirect has to stand in, use a 308 and test it with real clients.

Shut down the old services

• For every record that points at a service you're cancelling: remove the record, wait out its TTL, then cancel. Never the other way around.
• When legitimate sending has stopped: SPF -all, DMARC p=reject, optionally the wildcard DKIM record, and delete the old selectors. When receiving has stopped: the null MX.
• If HTTPS is going: serve max-age=0 over HTTPS until every policy you ever sent has expired. Wait for the preload removal to ship. Confirm the redirect itself is no longer needed. All three, not one.

Keep and review

• Keep the redirect at least a year, and longer while traffic still arrives.
• Review on every scheduled date: what traffic is left and what kind, and the inventory. Include the usage cycles that run less often than your reviews, and get a confirmation from the owners of the accounts and integrations. Zero hits over 90 days is where the review starts.
• Keep the registration until every dependency is closed and the decisions are written down. Only then is the registration itself up for a decision.

Ownership is the part that fails, so write it down. One line per hostname and per attached service: who owns it, what it still does, how often someone looks at it, and what has to be true before it can go. Keep the lines of retired services too, because they're the record of what was decided.

Running the last mile on a redirect service

Three jobs from the list above land on the redirect layer: a certificate that stays valid, a view of the traffic that's left, and a catch-all for the subdomains you missed.

On redirect.pizza every domain you add gets a certificate once its DNS checks out, and it renews automatically. HTTPS on a retired name stays up for as long as the redirect exists.

HSTS can be switched on for the whole team or per hostname, with your own max-age.

A wildcard redirect, available from Pro (Prosciutto e Funghi), catches the subdomains you didn't list, one level deep, once the specific records are gone.

Analytics show hits per period, referrers, and crawler traffic separate from user traffic. From Business (Quattro Stagioni), the raw request log exports to CSV.

That's the traffic side of the review, not the inventory side. Which headers matter on a hostname that only redirects is in which security headers a redirect needs.

Digip puts that traffic data in front of its own clients. It manages around 8,000 domains for business clients, and where a client needs HTTPS redirects, Digip runs them on redirect.pizza. "The analytics give us a clear picture of where the traffic is coming from, country by country, and split between HTTPS and HTTP. That data goes to the client in PDF," says Karan Arora, Head of Domain Portfolio at Digip.

Try redirect.pizza on your own domains

A certificate for every domain, HSTS with a max-age you control, and analytics that show what traffic an old name still gets. No server to keep alive for a name you're winding down.

Get started for free

Frequently Asked Questions

Related Reads

• Redirecting a Domain That Used HSTS
• Security Headers on a Redirect: Two Matter, Four Don't
• Post-Migration Monitoring: What to Track After a Domain Move
• Your Domain Migration SEO Checklist (Don't Skip Step 4)

Keep the old name alive for exactly as long as it needs to be

Every domain you add to redirect.pizza gets a certificate automatically, HSTS per hostname, and analytics that show what traffic the old name still gets.

See automatic HTTPS →