# How do you protect the domain your email depends on?

URL: https://iblockspam.com/blog/domain-registrar-security-registry-lock
Last updated: 2026-10-10
Published: 2026-10-10
Topic: Setup guides
Author: iBlockSpam Team

> Protect the domain your email depends on: registrar MFA, transfer lock vs registry lock, auto-renew, contact addresses and DNS host security, plus a checklist.

## Short answer

Your email is only as safe as the accounts that control your domain. Turn on MFA at your registrar and DNS host, keep the transfer lock (clientTransferProhibited) on, enable auto-renew, and use a contact email on a different domain. For high-value .com or .net domains, add a registry lock, which requires out-of-band verification before changes.

Every email protection you set up lives in DNS: your MX records, SPF, DKIM keys and DMARC policy. Whoever controls your registrar account or DNS host can change all of them in minutes. This guide covers how to lock down the domain itself: account security, transfer locks, registry lock, renewals and contacts, and what's at stake for your email if it goes wrong.

## Why does domain security matter for email?

Your domain name is the root of trust for your email. ICANN's Security and Stability Advisory Committee (SSAC) put it plainly in [SAC044](https://www.icann.org/en/system/files/files/sac-044-en.pdf): "Altering DNS information is a common objective of a registration account compromise." An attacker may "route the organization's mail or web traffic though monitoring hosts" to capture credentials.

CISA saw exactly this in 2019. Its [Emergency Directive 19-01](https://www.cisa.gov/news-events/directives/ed-19-01-mitigate-dns-infrastructure-tampering) described attackers who obtained DNS account credentials, changed records such as A, MX and NS, and "redirected and intercepted web and mail traffic." Because they controlled DNS, they could also get valid certificates for the victims' domains. CISA closed the directive in January 2026, but the technique hasn't gone away.

## What can an attacker do with your domain?

| What they change | Effect on your email |
|---|---|
| MX records | Inbound mail goes to their server first, or only to them |
| SPF record | Their servers become authorized senders for your domain |
| DKIM selector | They publish their own public key and sign mail as you |
| DMARC record | They switch your policy to `p=none` or redirect your reports |
| Nameservers | All of the above at once, from a DNS host they control |
| Registrant contact | They start a transfer or lock you out of recovery |

The result is mail that passes SPF, DKIM and DMARC as your domain, sent by someone else. No filter can tell the difference, because the domain owner's DNS says it's legitimate. They can also receive password reset emails for any other service that uses your addresses.

Losing the domain through non-renewal is the other route. SAC044 warns that after expiry and the grace periods, "a different party may register the domain name", and the new owner can then run mail for it.

## How do you secure the registrar account?

The registrar account is the master key. SAC044's recommendations for registrants, plus CISA's guidance on MFA, come down to these steps:

1. **Turn on MFA.** CISA's directive required MFA on "all accounts" that can change DNS records, recommended phishing-resistant factors and advised against SMS. A security key or passkey is the target; an authenticator app is the minimum.
2. **Use a unique password** in a password manager, and different credentials for each registrar or DNS account. SAC044 lists "use different credentials for each account."
3. **Use named accounts, not one shared login.** Many registrars support multiple users with their own sign-in. If yours doesn't, store the shared credential in a password manager with access logging.
4. **Limit who has access.** SAC044 suggests partitioning "particularly sensitive or important domain registrations into an account whose credentials are held by more senior personnel."
5. **Remove access when people leave.** SAC044 recommends that offboarding checks "if the employee has domain registration account access."
6. **Turn on every notification.** Registrars can email you about nameserver, contact and status changes. SAC044 calls these notifications "extremely important because they may forewarn registrants of unauthorized registration account access."

### Put contact email on a different domain

This one is easy to miss. If the registrar's contact address is `admin@yourcompany.com` and an attacker changes the DNS for `yourcompany.com`, the registrar's warning emails go nowhere useful. SAC044 says contact email addresses "should be assigned to mail servers named outside that domain and registration account." For a small business, that can be a role mailbox on a separate domain you own at a different registrar, or a well-run mailbox provider, protected with MFA.

## What is the difference between a transfer lock and a registry lock?

Domain locks are status codes defined by the registration protocol (EPP). Registrars set **client** codes; registries set **server** codes ([ICANN](https://www.icann.org/resources/pages/epp-status-codes-2014-06-16-en)).

| | Registrar lock (client codes) | Registry lock (server codes) |
|---|---|---|
| Status codes | `clientTransferProhibited`, `clientUpdateProhibited`, `clientDeleteProhibited` | `serverTransferProhibited`, `serverUpdateProhibited`, `serverDeleteProhibited` |
| Set by | Your registrar, often from a toggle in your account | The registry, at your registrar's request |
| How it's removed | From the registrar account or by request | A manual, verified process between registrar and registry |
| Stops someone who has your registrar login? | No, they can unlock it | Yes, changes need out-of-band verification |
| Cost and availability | Usually free and often on by default | Often a paid add-on; not every registrar or TLD offers it |

### The transfer lock

ICANN says `clientTransferProhibited` "tells your domain's registry to reject requests to transfer the domain from your current registrar to another," which helps prevent "unauthorized transfers resulting from hijacking and/or fraud." Keep it on. SAC044 also encourages setting `clientUpdateProhibited` so contact and DNS details can't change without first unlocking. Our guide to [domain renewal scam emails](https://iblockspam.com/blog/domain-renewal-scam-emails) covers the related fake-registrar tricks.

The limit is important: a transfer lock does nothing if the attacker logs in to your registrar account. They can change nameservers without ever transferring the domain.

### Registry lock and Verisign Registry Lock for .com

A registry lock moves the final check outside your registrar account. For .com, .net, .cc and .name, the registry is Verisign, and its [Registry Lock](https://www.verisign.com/resources/registrar-resources/registry-lock) service is available "through participating domain name registrars." To make a change, "an authorized individual at the registrar must submit a request to Verisign to unlock the domain name." That person "is then contacted by Verisign via phone" and must give "an individual security phrase." Verisign says this "out-of-band" step "helps protect against automation errors and system compromises."

According to Verisign's [status page](https://www.verisign.com/resources/registrar-resources/registry-lock-status), the server codes mean:

- **Server Delete Prohibited**: "Confirms a domain name cannot be deleted or lapsed"
- **Server Transfer Prohibited**: "Prevents unauthorized transfers away from domain name provider"
- **Server Update Prohibited**: "Ensures no modifications are allowed, including name server re-delegations"

Verisign also says "locking the hosts in addition to the domain name is critical in stopping attacks," so ask for both if your nameservers are under your own domain. ICANN notes the trade-off: removing a server status "can take longer than it does for clientTransferProhibited." Plan routine changes, such as a nameserver move, ahead of time.

Is it worth it? For the domain that carries your company email, often yes, especially if it also runs your website and customer logins. For other TLDs, ask your registrar whether that registry offers an equivalent.

## How do you avoid losing the domain at renewal?

1. **Turn on auto-renew** for every domain you use, and register for several years at a time.
2. **Keep the payment card current.** SAC044 suggests using card-expiry notices "to trigger checks by accounting personnel" so renewals aren't declined.
3. **Record each domain's registrar and expiry date** in a shared list, and check it yearly. ICANN's registration data lookup at `lookup.icann.org` shows the real registrar and expiry.
4. **Watch for the domains your DNS depends on.** SAC044 warns about name servers hosted on another domain that someone lets expire. If your nameservers live under a domain you also own, renew that one too.

## How do you secure the DNS host?

Your DNS host may not be your registrar. If records live at Cloudflare, Microsoft, a web host or anywhere else, that account needs the same care: MFA, named users, unique passwords and change notifications. SAC044 says the same practices "can be applied to parties that host DNS, irrespective of whether that party is a registrar or other external agent."

Two more habits help:

- **Keep a copy of your zone.** SAC044 recommends archiving a known-good zone file so you can restore DNS quickly.
- **Monitor records.** Compare your MX, SPF, DKIM and DMARC against what you expect. Check them now with the [MX Lookup](https://iblockspam.com/tools/mx-lookup), [SPF Checker](https://iblockspam.com/tools/spf-checker) and [DMARC Checker](https://iblockspam.com/tools/dmarc-checker).

Signing your zone with DNSSEC protects answers in transit between your DNS host and resolvers, but it doesn't help if someone logs in to the DNS host and changes the records. See [DNSSEC explained for email](https://iblockspam.com/blog/dnssec-explained-for-email).

## Domain security checklist

- [ ] MFA on every registrar and DNS host account, ideally a security key or passkey
- [ ] Unique passwords stored in a password manager
- [ ] Named users, with leavers removed the day they leave
- [ ] Registrar contact email on a different domain, protected with MFA
- [ ] `clientTransferProhibited` on; `clientUpdateProhibited` where your registrar supports it
- [ ] Registry lock considered for your primary email domain
- [ ] Auto-renew on, multi-year registration, payment card current
- [ ] Change notifications on and routed to someone who reads them
- [ ] A saved copy of your DNS zone
- [ ] Regular checks of MX, SPF, DKIM and DMARC
- [ ] Parked and unused domains locked down too; see [protecting parked domains from spoofing](https://iblockspam.com/blog/protect-parked-domains-from-spoofing)
- [ ] No DNS records pointing at services you no longer use; see [subdomain takeover and dangling DNS](https://iblockspam.com/blog/subdomain-takeover-dangling-dns-email)

## What should you do if your domain is hijacked?

1. Contact your registrar's abuse or security team immediately, through a phone number or address you already have, not from an email link.
2. Regain the account: reset the password, remove unknown users and API keys, and reset MFA.
3. Restore DNS from your saved zone, then check MX, SPF, DKIM selectors and DMARC one by one.
4. Rotate DKIM keys. A key the attacker published or saw is no longer trustworthy; see [DKIM key rotation](https://iblockspam.com/blog/dkim-key-rotation).
5. Look for certificates issued for your domain that you didn't request, as CISA's directive advised.
6. Reset passwords for accounts whose reset emails may have been intercepted, and follow your [incident response steps for compromised mail](https://iblockspam.com/blog/signs-email-account-compromised).

## Next steps

- Today: confirm MFA on your registrar and DNS accounts, and check the contact email.
- This week: verify the transfer lock and auto-renew on every domain, and save a copy of your zone.
- Ask your registrar whether it offers registry lock for your primary domain.
- Get notified about changes. iBlockSpam's [domain monitoring](https://iblockspam.com/features/domain-monitoring) alerts you when MX, SPF or DMARC change: weekly on Protect, daily on Protect Plus. Or run the free [Email Health Check](https://iblockspam.com/tools/email-health-check) any time.

Browse more [setup guides](https://iblockspam.com/blog/topic/setup).

## Frequently asked questions

### What is the difference between a registrar lock and a registry lock?

A registrar lock sets client status codes such as clientTransferProhibited, which your registrar can remove when you click a button in your account. A registry lock sets server status codes at the registry itself, and removing it takes a slower verified process. For .com and .net, Verisign calls a registrar's authorized person and asks for a security phrase.

### Can someone steal my domain if the transfer lock is on?

The transfer lock blocks transfers to another registrar, but it doesn't stop someone who logs in to your registrar account. They can turn the lock off or simply change your nameservers or DNS records. That's why MFA on the registrar and DNS accounts matters more than the lock, and why a registry lock adds a check outside the account.

### What happens to my email if my domain is hijacked?

Whoever controls your DNS controls your MX, SPF, DKIM and DMARC records. They can route your inbound mail through their servers, send mail that passes authentication as your domain, and receive password reset emails for your other accounts. CISA has warned that this kind of DNS tampering lets attackers obtain valid certificates for your domain too.

### Should my registrar contact email be on the same domain?

No. ICANN's SSAC recommends that contact email addresses for a domain use mail servers outside that domain and registration account. If an attacker changes your DNS, mail to an address on the same domain stops reaching you, so you miss the registrar's change notices and can't receive password reset messages.

### How do I check whether my domain has a registry lock?

Look up the domain with ICANN's registration data lookup or your registry's WHOIS. A registry lock shows serverDeleteProhibited, serverTransferProhibited and serverUpdateProhibited. Codes starting with client are set by your registrar. Verisign notes that when both are applied, both the client and server versions of each code appear.

## Sources

- [ICANN SSAC SAC044: A Registrant's Guide to Protecting Domain Name Registration Accounts (November 2010)](https://www.icann.org/en/system/files/files/sac-044-en.pdf)
- [ICANN: EPP Status Codes, What Do They Mean, and Why Should I Know?](https://www.icann.org/resources/pages/epp-status-codes-2014-06-16-en)
- [Verisign: Registry Lock](https://www.verisign.com/resources/registrar-resources/registry-lock)
- [Verisign: Registry Lock status](https://www.verisign.com/resources/registrar-resources/registry-lock-status)
- [CISA Emergency Directive 19-01: Mitigate DNS Infrastructure Tampering (January 2019, closed January 2026)](https://www.cisa.gov/news-events/directives/ed-19-01-mitigate-dns-infrastructure-tampering)
- [CISA: More than a Password (multifactor authentication)](https://www.cisa.gov/MFA)

## Free tools for this guide

- [MX Lookup](https://iblockspam.com/tools/mx-lookup): See where your mail is delivered, spot unfiltered backup MX and broken hosts.
- [SPF Checker](https://iblockspam.com/tools/spf-checker): Count real DNS lookups, find PermErrors, loops and risky "all" settings.
- [DMARC Checker](https://iblockspam.com/tools/dmarc-checker): Check your policy, reporting and the safe path from p=none to reject.
- [DKIM Checker](https://iblockspam.com/tools/dkim-checker): Validate DKIM keys by selector, including key type and strength.

---

Source: iBlockSpam, https://iblockspam.com/blog/domain-registrar-security-registry-lock (this is a Markdown copy; the HTML page is canonical). Quote with attribution and a link. Site index for AI assistants: https://iblockspam.com/llms.txt