Your Domain Name Is a Business Asset: Domain Locks, WHOIS Privacy, and the Security Settings You Shouldn’t Ignore

If your website disappeared tomorrow, you would have a problem.

If someone took control of your domain name, you could have a much bigger one.

A domain is easy to think of as nothing more than an address.

yourbusiness.com

You register it, point it at a website, renew it every year, and mostly forget that it exists.

But that domain can sit at the center of your company's online identity.

Your website may depend on it.

Your email may depend on it.

Customer portals may depend on it.

Remote services may depend on it.

Search results, advertisements, printed materials, invoices, business cards, QR codes, and years of customer recognition may all point back to it.

That makes a business domain more than a technical setting.

It is a business asset.

And like any important asset, it deserves more protection than a password somebody created six years ago and hasn't thought about since.

Let's talk about what actually protects a domain, what some of the terminology means, and which settings business owners should care about.

One of the first security settings you'll commonly see is some variation of:

Domain Lock

Registrar Lock

Transfer Lock

or a domain status such as:

clientTransferProhibited

They generally refer to a mechanism designed to prevent the domain from being transferred to another registrar while the lock is enabled.

ICANN describes registrar locking as a protection against unauthorized changes and transfers. A locked domain may display a status such as clientTransferProhibited.

Think of it like putting the transmission in park.

The domain still works.

Your website still works.

Your email still works.

Your DNS still works.

You're simply making it harder for the domain to be moved somewhere else without first intentionally unlocking it.

For most domains that are not actively being transferred, there is very little reason to leave the transfer lock disabled.

If you're not moving the domain, lock it.

Simple.

A Domain Lock Is Not an Impenetrable Force Field

It is important to understand what the lock does not mean.

A registrar lock is another layer of protection. It is not a guarantee that nothing bad can ever happen to your domain.

If somebody compromises the account at your registrar and gains sufficient control, they may potentially be able to change settings, disable protections, access transfer functions, or otherwise interfere with the domain.

That is why domain security needs multiple layers.

The lock helps.

Your registrar account security matters too.

Your email security matters.

Multi-factor authentication matters.

Your transfer credentials matter.

Your contact information matters.

One checkbox should never be your entire security strategy.

This causes a lot of confusion.

There is the normal lock you can typically enable and disable through your registrar, and there are also situations where domain transfer restrictions apply because of registration or transfer rules.

For many generic top-level domains, a registrar may deny a transfer during the first 60 days following initial registration or within 60 days after a previous registrar transfer. A change of registrant can also trigger a 60-day inter-registrar transfer lock under the current ICANN Transfer Policy, although registrars may offer an opt-out before certain changes are made.

That means:

“My domain is locked” does not always mean somebody clicked the lock button.

If you recently registered it, transferred it, or changed certain registrant information, there may be additional transfer restrictions in place.

This becomes particularly important when you're planning several domain changes at once.

For example, if you know you want to move a domain to another registrar and also need to change ownership information, the order in which you perform those operations can matter.

Do not make major registrant changes immediately before a planned transfer without understanding the consequences.

For decades, people learned to use a WHOIS lookup to find information about a domain.

WHOIS might show things such as:

• The registrar
• Registration dates
• Expiration information
• Domain status
• Nameservers
• Registrant information
• Administrative contacts
• Technical contacts

That is why you'll still hear phrases like:

“Check the WHOIS.”

“Is WHOIS privacy enabled?”

“Who owns it according to WHOIS?”

Those phrases haven't disappeared.

But the technology has changed.

For generic top-level domains, RDAP — the Registration Data Access Protocol — became the definitive source for registration information on January 28, 2025, replacing traditional WHOIS as the required standard for gTLD registration-data services.

RDAP serves a similar purpose while providing a more modern, standardized method of accessing registration information, including better support for structured responses, internationalization, secure access, and differentiated access to registration data.

So when someone says “WHOIS information” today, they may really be referring more generally to public domain registration data.

And because people still search Google for terms like WHOIS lookup and WHOIS privacy, those terms aren't disappearing from everyday language anytime soon.

Years ago, registering a domain could mean publishing a surprisingly large amount of personal information.

Depending on the domain and registrar, public records could expose things such as:

• Your name
• Mailing address
• Email address
• Telephone number
• Organization
• Administrative contact information
• Technical contact information

That created obvious privacy problems.

It also created a fantastic resource for spammers, scammers, marketers, data harvesters, and anyone else interested in scraping contact information.

Privacy laws and changes to domain-registration policies substantially changed that environment.

Today, much of the personal registration data that was once routinely public may be redacted or otherwise withheld from public registration-data results. ICANN's current Registration Data Policy specifies which registration elements must remain public and which personal data may require redaction.

So if you look up a domain and see:

REDACTED FOR PRIVACY

or simply don't see a person's home address and phone number anymore, that's normal.

It does not mean nobody owns the domain.

It means the underlying registrar may hold information that is not being publicly displayed.

This distinction is important.

Privacy is about what information is publicly exposed.

Ownership and control are about who actually holds and manages the registration.

Those are not necessarily the same concept.

ICANN distinguishes between privacy services and proxy services.

With a privacy service, the customer may remain the registered domain holder while alternative contact information is published instead of the customer's personal information.

With a proxy service, the proxy provider may actually appear as the registrant of record and provide its own contact details instead.

That distinction can matter.

For the average small-business owner, the important takeaway is simpler:

Do not assume that hiding public registration information means you no longer need accurate information inside your registrar account.

You absolutely do.

This is one of those shortcuts that can create a nightmare later.

Someone doesn't want their address appearing online, so they enter:

John Smith
123 Main Street
Nowhere, USA
555-555-5555

Problem solved, right?

No.

Your registrar needs accurate information associated with the registration.

Privacy protection is meant to reduce what gets publicly exposed—not give you a reason to fill the account with garbage.

Accurate domain information can become extremely important when you're trying to:

• Recover an account
• Resolve an ownership dispute
• Approve an important change
• Receive renewal notifications
• Transfer a domain
• Respond to a registrar verification request
• Prove that you are authorized to manage the domain

ICANN specifically recommends keeping domain contact information current so registrants continue receiving important notices and can establish their relationship to the registration when necessary.

Use real information.

Protect it appropriately.

Those are two separate things.

Here's something many businesses overlook.

What email address is attached to your registrar account?

Now ask another question:

How secure is that email account?

Password reset links often go to email.

Security notifications go to email.

Domain renewal warnings go to email.

Account verification messages go to email.

Transfer notifications may go to email.

If somebody compromises the email account associated with your domain registrar, they may have opened a path toward compromising other services too.

This creates an especially ugly circular dependency if you're careless.

Imagine your domain is:

example.com

And the only recovery email for the registrar controlling example.com is:

admin@example.com

Now imagine the domain is compromised and email delivery for example.com stops working.

Your recovery mechanism depended entirely on the thing you are trying to recover.

For important domains, consider maintaining a secure external recovery method that does not depend exclusively on the domain itself.

And whichever account you use:

Protect it with multi-factor authentication.

A strong password is good.

A strong password plus another authentication factor is better.

If your registrar provides multi-factor authentication or two-factor authentication, use it.

Ideally, use an authenticator application, hardware security key, passkey, or another strong authentication method when supported.

SMS authentication is still better than having no second factor at all, but stronger methods can provide additional resistance against attacks involving phone-number takeover or interception.

The important point is:

Your registrar account deserves the same level of protection as your banking and primary email accounts.

Possibly more than you realize.

A compromised social-media account is irritating.

A compromised domain can potentially redirect your website, interfere with email delivery, impersonate your business, or disrupt services that rely on that name.

Domain transfers commonly use an authorization credential often called an:

• EPP code
• Auth code
• AuthInfo code
• Transfer code
• Authorization code

The exact terminology varies.

Its purpose is essentially to demonstrate authorization when moving a domain between registrars.

ICANN describes the AuthInfo code as a unique code used during the registrar-transfer process to help prevent unauthorized transfers.

That means the transfer code should not be treated like harmless account information.

Do not:

• Email it around unnecessarily
• Put it in a public ticket
• Paste it into a shared document
• Store it in an unsecured notes file
• Send it through an untrusted messaging platform
• Give it to somebody simply because they claim to be your web developer

If someone does not need the transfer authorization code, they should not have it.

And when you are not actively transferring the domain, keep the domain locked.

Owning the domain is only part of the story.

The Domain Name System, or DNS, tells the internet where services associated with your domain live.

That can include:

• Your website
• Email servers
• Verification records
• Subdomains
• Customer portals
• APIs
• Remote services
• Security policies

If somebody gains unauthorized control over your DNS, they may not need to steal the registration itself to cause serious problems.

They could potentially change where your website points.

They could interfere with email.

They could redirect subdomains.

They could modify verification records.

They could disrupt services.

That's why the credentials used to manage DNS deserve the same careful treatment as the domain registrar account itself.

And this is also where DNSSEC enters the conversation.

DNS was created in a very different internet.

The original system was not designed with strong cryptographic validation of DNS responses in mind.

DNSSEC — Domain Name System Security Extensions — adds cryptographic signatures to DNS data so validating systems can verify that the information they received is authentic and has not been altered in transit.

That can help defend against certain types of DNS spoofing and cache-poisoning attacks.

DNSSEC does not encrypt your website traffic.

That is not its job.

HTTPS and TLS protect communications between clients and services such as websites.

DNSSEC helps establish authenticity within DNS.

They solve different problems.

DNSSEC also has to be configured correctly across the authoritative DNS provider and domain-registration chain.

A broken DNSSEC configuration can make a perfectly healthy website appear completely unreachable to validating clients.

So this is not a setting to randomly toggle without understanding how your DNS is configured.

When properly supported and managed, however, DNSSEC can provide another valuable layer of domain security.

Domain security isn't exclusively about hackers.

Sometimes the biggest threat to a domain is:

Someone forgot to renew it.

The employee responsible for it left.

The billing card expired.

Renewal notices went to an old email address.

Nobody knew which registrar held the domain.

The domain was registered ten years ago under somebody's personal account.

Everybody assumed someone else was handling it.

Then one morning:

The website stops working.

Email stops working.

And somebody finally asks:

“Who has the login for the domain?”

That is a conversation you never want to have during an outage.

Enable automatic renewal for important domains when appropriate.

Keep the payment method current.

Keep contact information current.

Make sure renewal notices are going somewhere that is actually monitored.

And know when your domains expire before expiration becomes an emergency.

For an important business domain, ownership and renewal information should not exist solely inside one employee's head.

You would be surprised how many businesses don't.

The owner thinks the web developer owns it.

The web developer thinks the old marketing company owns it.

The marketing company registered it through some reseller eight years ago.

The person who originally created the account hasn't worked there since 2021.

Nobody knows the password.

Nobody knows what email address is attached.

And now the business wants to make a DNS change.

This is how a five-minute task becomes a three-day investigation.

Every business should know:

Which registrar holds the domain?

Which account controls it?

Who has administrative access?

Which email addresses are attached to the account?

When does the domain expire?

Is automatic renewal enabled?

Is the domain locked?

Is MFA enabled?

Who controls the authoritative DNS?

Is DNSSEC enabled, and if so, where is it managed?

You don't need to memorize all of that.

You need to know where the information is securely documented.

This is worth repeating because the two ideas are frequently marketed together.

Privacy can reduce public exposure of your information.

That's good.

But privacy doesn't prevent someone from guessing your password.

It doesn't stop phishing.

It doesn't secure your email account.

It doesn't enable MFA.

It doesn't automatically prevent a registrar transfer.

It doesn't protect DNS.

It doesn't renew an expired domain.

It doesn't make an insecure registrar account secure.

Privacy is one layer.

Security is the combination of all the layers.

If your business owns one domain or one hundred, start here:

Keep the domain locked.

Unless you're intentionally performing a registrar transfer, enable the registrar or transfer lock.

Enable multi-factor authentication.

Protect the registrar account with more than a password.

Secure the email attached to the registrar account.

That mailbox can become part of your account-recovery chain.

Use accurate registration information.

Privacy should protect legitimate information—not replace it with fake information.

Keep private information private where appropriate.

Understand what your registrar publishes and what is redacted or protected.

Keep transfer credentials confidential.

Treat EPP/AuthInfo codes as sensitive credentials.

Enable auto-renew where appropriate.

Do not lose an important domain because somebody forgot what month it renews.

Monitor expiration dates.

Auto-renew is helpful, but monitoring is still necessary.

Keep billing information current.

An expired credit card can defeat a perfectly configured automatic-renewal setting.

Protect DNS access.

DNS can control where many of your domain's services go.

Consider DNSSEC when properly supported.

Use it as another security layer, but make sure it is correctly configured.

Know who has access.

Old employees, developers, contractors, and agencies should not retain domain access indefinitely.

Document ownership and recovery information.

Know where the domain is registered and how authorized people can recover access.

Hosting can be replaced.

A website can be rebuilt.

A server can be restored.

But your primary domain may represent years—or decades—of accumulated recognition.

Customers know it.

Search engines know it.

Email contacts know it.

Advertising points to it.

Printed material contains it.

Software may depend on it.

Changing it because the original domain was lost or compromised is rarely as simple as registering another one.

That is why domain management should not be treated as the $15-or-$20 line item someone ignores until the renewal notice shows up.

The registration itself may be inexpensive.

The identity attached to it can be extremely valuable.

Most businesses do not need an employee staring at domain records all day.

They need the basics handled correctly.

Keep accurate records.

Protect the account.

Use MFA.

Keep the domain locked.

Protect transfer credentials.

Keep DNS secure.

Monitor renewals.

Use privacy appropriately.

Understand who actually controls the domain.

And make sure there is a recovery plan before you need one.

At Spark Rack, we believe domain management should make those protections easier to understand instead of burying customers under registrar jargon.

Because nobody should have to learn what clientTransferProhibited means at 7:30 in the morning because their company's domain suddenly disappeared.

The best time to understand your domain security is while everything is working.

When Did You Last Check Your Domain?

If the answer is:

“I’m not sure.”

That's probably a good reason to check it.

Look at the registrar.

Check the expiration date.

Confirm auto-renew.

Review the contact information.

Make sure the domain is locked.

Check who has account access.

Turn on MFA.

Review DNS and DNSSEC.

Make sure your recovery information still works.

It takes far less time to check those things today than it does to recover a domain after something goes wrong.

Your domain is part of your business.

Protect it like it is.