Your Domain Name Is the Master Key

Why this matters

Every "forgot password" link your shop will ever click lands in a mailbox, and that mailbox only works because somebody controls the domain name behind it. Whoever holds the domain can point your email anywhere, read the reset links for your bank, your payment processor, your field software and your business profiles, and lock you out of all of them in an afternoon. Most shops have never looked at who that somebody is. A surprising share find out it is a web designer they stopped paying years ago, or a renewal card that expired last spring.

Four separate things that all get called "the website"

Owners say "our website guy has it" and mean four different jobs, often held by four different parties. Pull them apart, because each one fails differently.

• The registrant. The legal holder of the domain, named in the registration record. This is ownership. If the registrant line says your designer's name or company, they own your domain on paper, whatever you paid them.
• The registrar. The company the domain is registered through, which takes the renewal payment and holds the controls. You log into an account at the registrar to manage the domain. The account holder and the registrant can be different people, which is how designers end up holding shop domains: the shop is listed, but the login is theirs.
• DNS (the domain name system) hosting. The service that answers "where does this domain point?" Its records send web traffic to a server and send mail to a mail provider. Often the registrar does this too, sometimes it is a separate service.
• Web hosting and email hosting. Where the site files live and where the mailboxes live. These can move without touching the domain at all.

The chain that turns a domain into control of your money looks like this:

  registrar account login
          |
          v
  domain (yourshop.com) -> DNS records
                               |
                  MX record ---+--- web record
                      |
                      v
             mail provider -> office@ mailbox
                      |
                      v
       password reset links for: bank, card
       processor, payroll, field software,
       business profiles, social accounts

Read it from the top. Whoever logs into the registrar account can change the MX record (the mail exchanger record, which tells the world where to deliver your mail) in about two minutes. From that moment, new mail to office@ goes to them. They do not need your mailbox password. They request resets, receive them, and walk down the list. Nothing at the bottom of the chain is safer than the login at the top.

What a healthy domain looks like

Five properties, and you can check every one of them yourself in under an hour.

The registrant is the business. The legal entity name, not a person and not a vendor. If the owner registered it personally years ago, move it to the business entity, because a domain held by one person becomes an estate and divorce problem as well as a security one.

The registrar account belongs to the shop. Its login email is a shop address that does NOT live on the same domain. This catches people: if the registrar sends its own password resets to [email protected], and someone has redirected yourshop.com's mail, you cannot get into the account you need to fix the redirect. Use a separate address on a different provider, held by the owner, as the registrar account's contact. Turn on multifactor authentication on the registrar account; see related: Turning On Multifactor Authentication Without Locking Yourself Out.

Registrar lock is on. Often called transfer lock, it sets a status that refuses any request to move the domain to another registrar until you switch it off. It does not stop someone who is already inside your account, which is why the account itself matters more, but it stops the cheaper attack where someone talks a registrar into moving the domain away.

Renewal is automatic, years out, on a card that will not expire first. Set auto-renew, then also prepay several years if your registrar allows it. The card on file is the quiet failure: a card replaced after fraud or expiry, nobody updates the registrar, renewal fails, and the warning emails go to a mailbox nobody reads.

Somebody other than the owner knows all of this exists. The domain belongs on the shop's account list with its registrar, renewal date and recovery contact; see related: The Account Inventory Every Shop Should Keep.

Expiry is a takeover too, just a slower one

A domain that lapses does not vanish the next day, but the clock is shorter than people think. For generic domains like .com, ICANN's Expired Registration Recovery Policy requires the registrar to give the registrant a renewal window after expiry, at least 30 days, and for at least eight consecutive days of it the registrar must interrupt the domain's existing DNS, which stops your website and email so you notice. After that, many domains enter a redemption period during which recovery is still possible but costs a multiple of a normal renewal, and then the name is released and anyone can register it. Country-code domains follow their own registry's rules, which differ. This is current as of 2026; check your registrar's stated grace and redemption terms and ICANN's site, because registrars set the details within the policy.

The danger is in what happens after release. People who buy dropped names watch for ones with existing email traffic. A former shop domain still receives password resets, supplier statements and customer replies for years, and anyone who registers it receives them too.

The designer who registered it in their own name

This is the most common situation in small shops and it is usually not malicious. A designer bought the domain on their own account in 2017 because it was quicker, put their own details in the registration, and has paid the renewal every year as part of a hosting bundle. The shop stopped the bundle, the designer moved on, and nobody noticed that the shop's email now depends on a stranger's account.

Getting it back is a transfer, done in two moves that are easy to confuse.

• Change of registrant makes the business the legal holder. The current registrant (the designer) approves it inside their registrar account. ICANN's Transfer Policy has historically applied a transfer lock of up to 60 days after a registrant change; ICANN has been revising that policy, so check your registrar's current terms before you plan around it.
• Transfer to your own registrar account moves the domain out of their login. They unlock the domain and give you the authorization code (sometimes called the EPP code or auth code), you start the transfer at your registrar, and they or their registrar confirm it. A domain that was registered or transferred in the last 60 days generally cannot be transferred again until that window passes.

Ask for the transfer to happen while the designer is still cooperative, and get both moves done in the same week. A designer who has gone quiet is a different problem; the wider question of agencies holding your logins belongs to see related: The Agency or Web Designer Holds Your Keys.

Worked example: eleven days from expiry, and the login is not yours

A six-person electrical shop gets a renewal notice forwarded by a customer who received it by mistake. The domain expires in 11 days. The owner looks up the registration data and finds the registrant field redacted for privacy, which is normal now, but the registrar is one the shop has never had an account with. The office manager remembers that the original site was built by a freelancer.

Day 0, the owner contacts the freelancer by phone, not by email to the shop's own domain, and asks three things in one call: whose account is it in, will you renew it today so it cannot lapse while we sort this, and will you transfer it to us. The reasoning for the order is that renewal is the one thing that buys time, and a transfer started on an about-to-expire domain can complicate both.

Day 1, the freelancer renews it for one year and agrees to transfer. The shop opens its own registrar account, using a separate owner-held address on another provider as the account contact, with multifactor on, before anything moves. If the shop opens the account with office@ as the contact, it rebuilds the exact weakness it is trying to escape.

Day 3, the registrant change goes through to the business entity. The shop now owns the domain on paper but it still sits in the freelancer's login.

Day 4, the transfer attempt fails. The registrar refuses it because the registrant change triggered a transfer lock. This is the fork the owner did not expect. The two options are to wait out the lock with the domain in someone else's account, or to ask the freelancer's registrar whether the lock can be waived for a registrant change that both parties requested. In this case the registrar's support confirmed the change was requested by its own account holder and lifted it. Another registrar might not.

Day 6, the domain lands in the shop's account. Before anything else, the owner records the existing DNS records, all of them, because a transfer can carry them over or can reset them depending on whether DNS was hosted at the old registrar. If they reset, mail stops. Here the MX records and the records for the shop's email authentication carried over intact; see related: Setting Up Email Authentication So Nobody Can Send As You.

Day 7, the owner turns on registrar lock, auto-renew for the maximum term the registrar allows, and adds the domain to the account list with a note of the renewal date and the recovery contact.

What would have changed the answer: had the freelancer refused, or been unreachable with 11 days left, the owner's only safe move was to stop treating it as a favor. Write down the evidence that the shop paid for the domain (invoices, the original agreement), and talk to an attorney before the expiry date, not after. This is not legal advice: whether a vendor can be compelled to hand over a domain registered in their own name depends on the contract and on state law, and the answer differs between a contract dispute with a former vendor and genuine bad-faith squatting. ICANN's Uniform Domain-Name Dispute-Resolution Policy and the federal Anticybersquatting Consumer Protection Act are aimed at bad-faith registration of someone else's mark; a designer who registered your name at your request and kept it is usually the contract question, not the squatting one. Walk in with the invoices, the agreement, the registration record and the expiry date.

The failure mode is quiet. The owner gets the freelancer to renew, feels relieved, and stops there. Next year the same renewal depends on the same stranger.

Checking it once a year

Do this as part of the annual review; see related: The Annual Security Review SOP.

• Log into the registrar account yourself, not through a vendor. If you cannot, that is the finding.
• Confirm the registrant name is the business entity and the account contact address is not on the domain itself.
• Confirm the lock status shows the transfer-prohibited state and auto-renew is on, and read the expiry date off the screen.
• Confirm the card on file expires after the next renewal date.
• Export or screenshot the DNS records and keep the copy with the account list, so a bad change can be spotted and undone.
• List every person and vendor with access to the registrar or DNS account. Anyone you cannot name a reason for comes off.

If any of these fails, fix it that day. The rest of your security work sits on top of this one login.

References

• ICANN, Expired Registration Recovery Policy and Transfer Policy (current text on icann.org)
• ICANN, Uniform Domain-Name Dispute-Resolution Policy
• Anticybersquatting Consumer Protection Act, 15 U.S.C. 1125(d)
• See related: The Account Inventory Every Shop Should Keep, The Agency or Web Designer Holds Your Keys, Setting Up Email Authentication So Nobody Can Send As You