On April 13, 2013, customers of Regions Bank — the 22nd-largest bank in the United States by assets, serving sixteen states — tried to log into online banking and got a registrar's expiration notice instead. Not a breach. Not a DDoS attack. Regions.com had simply expired, and nobody had renewed it in time.
The outage lasted close to a week. Regions issued a video apology. The domain was eventually renewed for a further ten years, presumably so this specific embarrassment would never recur. It is, as far as anyone can tell, the single most-cited case in the industry of exactly how badly this can go for exactly how boring a reason. For the operations playbook that sits alongside business continuity, see . For the operations playbook that sits alongside business continuity, see XenGrowth's growth engineering practice.
Is Regions Bank an outlier, or does this happen regularly?
It happens often enough that it isn't really news anymore, which is itself the point. Four months after Regions, in August 2013, Yatra.com — then one of India's largest online travel booking platforms — went dark for about two days after failing to renew its own domain in time, redirecting visitors to a generic registrar page reading the domain had expired. Gizbot and DNA India both covered it as it happened. A related pattern shows up across the operational side of any online business — covers a lot of the infrastructure discipline that prevents exactly this kind of unforced error.
Case | What went wrong | Duration | Root cause |
|---|---|---|---|
Regions Bank (April 2013) | Regions.com expired; online banking and main site went offline | Close to one week | Renewal not processed before expiration |
Yatra.com (August 2013) | Domain expired; site redirected to registrar parking page | About two days | Renewal not processed before expiration |
Perl.com (January 2021) | Domain quietly transferred away from rightful owner months earlier, later pointed at malware-linked infrastructure | About nine days to full recovery | Unauthorized transfer, not a renewal failure |
Panix.com (January 2005) | Domain transferred without authorization via a fraudulent request through a reseller | About two days | Fraudulent transfer request, inadequately verified by the registrar |
What does ICANN actually require to prevent this?
More than most registrants realize, on paper. ICANN's Expired Registration Recovery Policy, in force since August 31, 2013, requires every accredited registrar to send registrants multiple notices before and after a domain's expiration date, disclose the renewal fee and any redemption fee in advance, and offer a defined path to renew even after expiration. It exists specifically because businesses were losing domains to simple inattention often enough to need a policy about it — which tells you how routine this failure already was by 2013.
After a domain expires and is deleted, ICANN policy requires a 30-day Redemption Grace Period. During those 30 days the registry must disable DNS resolution entirely — your site and email stop working immediately, notice period or not — and block any attempt to transfer the name elsewhere, while the sponsoring registrar is required to let the original registrant redeem it. Redemption at this stage typically carries a steep fee, separate from ordinary renewal, precisely because it's meant to be the expensive, painful path. After the RGP, a further pending-delete window follows before the name is released back to the public and anyone, including a domain speculator watching expiration lists, can register it. covers the the operations side of this side of this. The XenGrowth resource library covers the the operations side of this side of this.
None of that changes the operational reality: DNS resolution is off from day one, whatever recovery window ICANN guarantees underneath it. A business does not experience 'redeemable within 30 days' as good news. It experiences an outage that starts the moment the domain drops.
How is a hijacking different from a simple lapse?
A lapse is a business forgetting to pay a bill. A hijacking is someone else successfully impersonating you to your registrar, and it doesn't need to involve any technical exploit at all — both the Perl.com and Panix.com cases were social engineering against a registrar's verification process, not a system compromise.
Perl.com had been in continuous, legitimate use since 1997 as a community resource for the Perl programming language. Sometime in late 2020, control of the domain was quietly moved away from its rightful registrant, Tom Christiansen, and bounced between registrars. By January 27, 2021, it was resolving to an IP address with a documented history of hosting malware — a live warning to anyone who typed in a familiar, trusted address. Network Solutions worked with Christiansen on recovery, and the domain was back in his control by February 5, 2021, roughly nine days after the malicious redirect was first widely reported, though the underlying theft had gone unnoticed for considerably longer.
Panix, a working New York ISP, lost panix.com for about two days in January 2005 after a UK-based reseller submitted a fraudulent transfer request — using stolen credit card information to pay for it — to the Australian registrar Melbourne IT, which processed it without adequate verification. Customer email sent during the outage was gone for good. ICANN's own registrar liaison called it one of the more serious policy breaches by an accredited party the organization had seen, and the incident prompted a formal ICANN review of how much registrars could safely delegate verification to resellers. There is a longer treatment of AI agents and marketing automation in . There is a longer treatment of AI agents and marketing automation in XenGrowth on AI agents and marketing automation.
Every case in this post has the same shape: an administrative process, not a firewall, was the point of failure. Registrar verification, renewal notices, payment methods — the boring layer is the layer that actually broke.
What does this actually cost, beyond the outage itself?
Downtime is the visible cost, but it's rarely the largest one. Regions Bank's outage generated national coverage of a major regulated bank being unable to keep online banking running — a reputational hit that outlasted the week the site was actually down. A hijacked domain pointed at malware, as with Perl.com, damages every visitor who trusted the address before the redirect was noticed, not just the owner. Email is often the quieter casualty: Panix customers lost messages sent during their outage permanently, and any business running its own email off the same domain faces the identical exposure — a lapsed or hijacked domain doesn't just take down a website, it takes down every inbox that depends on it.
There's also a slower cost that never makes headlines: search rankings and referral traffic built over years don't necessarily transfer cleanly even after a domain is recovered, and a redirect to a parking page or malware host during the outage is exactly the kind of signal that damages a site's standing with search engines independent of the eventual fix.
Customer trust carries its own slow bill, too. Someone who typed in perl.com during the hijack and got a warning about malware doesn't necessarily come back to check whether the problem was fixed — they just quietly stop typing that address at all. A domain used for years by a bank or a travel agency has an implicit reputation built into it that an outage, however brief, chips at every time it happens. None of the four cases here show that erosion directly, because nobody measures it well, but it's the reason all four made an effort to apologize publicly rather than fix the problem quietly and move on. On AI search, GEO and discovery specifically, is worth reading. On AI search, GEO and discovery specifically, XenGrowth on AI search, GEO and discovery is worth reading.
Cost category | Regions Bank (2013) | Perl.com (2021) | Panix.com (2005) |
|---|---|---|---|
Direct outage | Online banking down close to a week | Domain resolving to a malware-linked host for over a week before recovery began | Domain down roughly two days |
Data loss | Not publicly reported | Not publicly reported beyond the redirect itself | Customer email sent during the outage was lost |
Public response required | A public video apology from the bank | Community alerts across Perl mailing lists and news coverage warning users away from the domain | A public ICANN review of registrar reseller practices |
Underlying failure | Missed renewal | Undetected unauthorized transfer months earlier | Fraudulent transfer request, weakly verified |
Put side by side, the pattern holds regardless of scale. A top-25 US bank and a two-decade-old community website failed for structurally identical reasons: a process meant to catch the problem — a renewal notice, a transfer verification step — didn't catch it in time. Bigger organizations don't get a pass on this; they just get more coverage when it happens to them.
What's the actual takeaway here?
Treat domain renewal like payroll, not like a subscription you can let lapse and catch up on later — the failure mode isn't a late fee, it's an outage that starts the instant the domain drops
Put registrar account access in more than one person's hands, with documentation, so a departure or an incapacitated colleague doesn't become the actual single point of failure
Enable registrar transfer lock and two-factor authentication specifically as a defense against the Perl.com and Panix.com failure mode — a fraudulent transfer request, not an expired card
Keep the registrant contact address monitored and current, since ERRP notices are worthless if they land in an inbox nobody reads
Assume the recovery timeline, even under ICANN's grace-period rules, still means real downtime — 30 days of redeemability is not the same as 30 days of your site staying up
None of the incidents in this post required a sophisticated adversary or an exotic failure. A payment method expired. A notice went unread. A registrar didn't verify a request carefully enough. That's the whole story, four separate times, at four organizations that should have known better — which is exactly why it's worth checking, today, whether your own domain is set up to survive the same boring mistake.
It's also worth resisting the temptation to file these incidents under 'that could never happen to a company as careful as mine.' Regions Bank had a compliance department. Yatra.com was, at the time, one of the largest online travel platforms in its market. Neither of those facts prevented a calendar failure from taking a production system offline for days. The organizations in this post were not unusually careless — they were unusually visible when an ordinary mistake happened to them, which is a distinction worth sitting with rather than dismissing.
Further reading from XenGrowth
Where this work meets go-to-market
Trying to make sure a domain outage never becomes a business outage? publishes operator guides on running the revenue side of a business on infrastructure that doesn't quietly expire underneath it.
Further reading from XenGrowth
Where this work meets go-to-market
writes for the teams who have to run business continuity day to day.
Further reading from XenGrowth
The XenGrowth resource library — what you'll learn: how the commercial side of this work is run, across search, automation and revenue operations.
XenGrowth on AI agents and marketing automation — what you'll learn: how the teams who own AI agents and marketing automation plan and measure it.
XenGrowth on AI search, GEO and discovery — what you'll learn: how the teams who own AI search, GEO and discovery plan and measure it.
Where this work meets go-to-market
XenGrowth's operator guides writes for the teams who have to run business continuity day to day.
Answer honestly about your own domain setup. This is a rough self-assessment based on the failure patterns in this post, not a security audit — it can't see your actual registrar account or renewal history.
