How to Secure a Domain Name Portfolio

By Bill Hartzer, domain name expert and expert witness·August 10, 2026

Start With an Inventory the Registrar Did Not Give You

Every portfolio review I have been involved in turns up domains nobody can account for: a name registered by a departed employee on a personal card, a country-code domain bought by a regional office, a defensive registration at a registrar nobody has logged into since.

Build the inventory from registration data rather than from a spreadsheet or one registrar's dashboard. For each name record the registrar of record, the account and individual controlling it, the expiry date, the status codes, the nameservers, the DNS host, the registrant contact email, and the person who would notice if it broke.

Query it through RDAP, which since 28 January 2025 is the definitive source for gTLD registration data and returns structured JSON rather than free text; WHOIS is no longer required except for .com, .name and .post, so anything built on port-43 scraping is on borrowed time. Redaction empties the contact fields, but the fields that matter for an inventory are not redacted: registrar of record, IANA ID, creation and expiry dates, status codes and nameservers all remain public.

The two entries that most often reveal a problem are the registrant contact email and the account holder. If either points at a person rather than a role, or at a mailbox on the domain itself, you have found the first thing to fix.

Tier the Portfolio Before You Spend on Controls

Uniform protection across a large portfolio is either unaffordable or so thin it is decorative. Tier by consequence of loss, not traffic.

Critical — names where loss stops revenue, breaks authentication or intercepts mail: the corporate primary, anything carrying MX records, anything issuing certificates, anything embedded in a product.
Operational — names in active use whose loss is disruptive but survivable: campaign sites, regional variants, redirect domains with real traffic.
Defensive — typo variants and unused registrations held so nobody else holds them. Renewal discipline and little else.

The tiering does real work: registry lock is a paid, per-domain, friction-adding service, and applying it to a thousand defensive registrations is neither practical nor sensible. Applying it to the four names in the critical tier usually is. Be honest in the sorting. The name carrying your MX records belongs in the critical tier even if the website behind it is a redirect, because a mail hijack is quieter, more damaging, and discovered much later.

Harden the Accounts First

Everything below the registry layer collapses into the registrar account: the lock toggles, the transfer authorization code, the nameservers, the contact email. Account security is the work with the largest return, and it comes before anything is bought.

Enroll phishing-resistant multi-factor authentication — hardware security keys using FIDO2/WebAuthn, where the credential is cryptographically bound to the real site's origin so a lookalike phishing page cannot obtain a usable assertion. Enroll two keys per person so losing one is not a lockout. Where only authenticator-app codes are supported, use those and understand that real-time relay can still defeat them. CISA's Emergency Directive 19-01 noted plainly that SMS-based multi-factor authentication is not recommended.
Give every person an individual account rather than a shared login, so actions are attributable and one person's access can be revoked without locking out the team. SAC074 makes the same recommendation.
Separate the contact roles — registrant, administrative, technical, billing — as SAC044 recommends, so one compromised mailbox does not receive every category of notification.
Inventory and scope API credentials. Registrar and DNS API keys typically bypass interactive multi-factor authentication entirely, so a key committed to a repository is a full-access credential with the second factor switched off. Scope narrowly, rotate on a schedule, and rotate immediately on any departure.
Fix the recovery path. If the password-reset email lands in an account with weaker protection, that weaker account is your real credential. Escrow recovery codes somewhere that is neither the password manager entry holding the password nor the mailbox receiving the resets.
Extend all of this to the DNS provider and any reseller. A domain held through a reseller inherits the reseller's account security, not yours.

Set the Locks, Then Verify Them Independently

Apply clientTransferProhibited, clientUpdateProhibited and clientDeleteProhibited wherever the registrar exposes them; SAC044 recommends the transfer and update prohibitions specifically. That is the floor for the whole portfolio, defensive tier included, because it costs nothing.

For the critical tier, add registry lock, which sets the server-prefixed equivalents your registrar cannot remove through the ordinary interface. Two details get missed. All three server statuses are required — Verisign states that “server” and “prohibited” must appear for update, delete and transfer. And host objects need locking as well as the domain object where the registry supports it, since locking only the domain can leave a glue-record path open.

Then verify. Read the status codes yourself in RDAP rather than trusting a padlock icon, record the result with a date, and re-check on a schedule. A lock that quietly disappears is one of the earliest available indicators that something has gone wrong inside the account.

Keep the authorized-contact list current, with at least two named individuals, and escrow the security phrase outside the registrar account it protects. The most common way registry lock fails is not an attack. It is that the only person the registry will call left two years ago.

Move the Notification Path Off the Domain

This is the highest ratio of value to effort in the whole program, and the most ignored. SAC044 has said since 2010 that the domain's contact email should be hosted outside the domain being protected and outside the registration account.

The reason is mechanical. Every meaningful signal arrives by email: the transfer notification a registrar must send within 24 hours of receiving notice of a transfer, the authorization code, the expiry reminders, the dispute notices. If those go to a mailbox on the domain under attack, an attacker who repoints your MX records captures the alarm with the asset. If they go to an address inside the compromised account, the attacker simply changes it.

Use a role-based mailbox on a different domain, read by more than one person, protected with hardware keys. With a privacy service, confirm the anonymized forwarder delivers somewhere a human reads — an unmonitored forwarder is how a 20-day window to answer a dispute expires without anyone knowing there was a dispute.

The free expiry alarm runs through this same path: ICANN's Expired Registration Recovery Policy requires renewal reminders roughly one month and one week before expiry, plus a further notice within five days after. Three checkpoints for nothing, provided they reach someone.

Then the DNS and Certificate Layers

Registration controls protect ownership. They do nothing about the records inside your zone or the certificates issued for your name, so a portfolio hardened only at the registration layer is still exploitable through DNS.

CISA's Emergency Directive 19-01, issued in January 2019 against an active campaign targeting federal agencies, describes the attack chain in three steps: compromise credentials for an account that can change DNS records, alter those records to redirect traffic, then obtain valid encryption certificates for the organization's domain names. Its mandated countermeasures map directly onto a portfolio program — audit public DNS records on authoritative and secondary servers with priority on NS records, change passwords on every account that can change DNS, add multi-factor authentication to those accounts, and begin monitoring Certificate Transparency logs.

On top of that: publish CAA records naming the certificate authorities permitted to issue for your names, remembering that a subdomain's CAA set replaces rather than adds to its parent's, and that issuewild is needed separately for wildcards. Sign the zones that warrant it with DNSSEC, deciding who owns re-signing and key rollover before turning it on. Monitor Certificate Transparency logs for the apex and wildcards, because CAA constrains only future issuance by compliant authorities.

Build the Ownership Evidence File Before You Need It

Since 2018, registration data has been redacted by default. ICANN's Registration Data Policy, effective 21 August 2025, requires redaction of registrant name, street, postal code and phone, with registry operators redacting registrant and tech email. Publicly, the record reads “REDACTED FOR PRIVACY” before a theft and after it alike, which distinguishes the rightful holder from a thief not at all.

The burden has shifted to private evidence, and the time to assemble it is now rather than during a recovery. Keep, offline and dated:

Registrar account records showing the domain under your account, dated.
Renewal invoices and payment records across the holding period.
The original purchase or escrow record for names acquired rather than registered.
Periodic RDAP snapshots — registrar of record and creation date stay public and establish continuity even under redaction.
DNS zone exports, so you can prove what the configuration was before it changed, plus correspondence establishing who administered the name.

If any name is held through a proxy service rather than a privacy service, the provider is the registrant of record. Get in writing how disclosure requests, ownership disputes and exit are handled — that is a dependency on a third party at the moment speed matters most.

The Habits That Actually Lose Domains

Sophisticated attacks are not the leading cause of loss. Process failure is.

Expiry. The most common way a domain is lost and the most preventable. Treat the expiry date as a monitored signal rather than a calendar entry, and do not rely on auto-renew alone if the card on file expires.
Departures. A domain registered to a personal email address leaves with the employee. Fix ownership at the role level before someone resigns.
Transfers left half-finished. Registrar lock is turned off for a legitimate transfer and never turned back on at the gaining registrar. Make re-locking an explicit closing step.
Live authorization codes. The transfer authorization code is a bearer credential. Generate it at the moment of transfer, move it over a channel other than the registrant email address on the domain, and rotate it if it was ever generated and left unused.
Change-of-registrant surprises. Under the current Transfer Policy, a change to the registrant's identifying data triggers a 60-day inter-registrar transfer lock, though registrars may let the holder opt out in advance. Plan restructurings around it, and know whether opt-out is enabled — an attacker who changes the registrant on an opted-out account can move the name immediately.

Where a name has already moved out, this stops being an operations problem. Preserve the evidence, act the same day, and get counsel experienced in domain matters involved early.

Frequently Asked Questions

Where should I start with a portfolio nobody has reviewed in years?

Inventory first, built from RDAP rather than from a registrar dashboard, and then the notification path. Those two steps cost nothing and surface most of the real exposure: names in accounts nobody controls, contact addresses pointing at people who left, and expiry dates closer than anyone thought. Locks and registry lock come after, because a lock on a domain whose account is controlled by a former employee's personal email is not protecting anything. Fix ownership and routing before buying controls.

Should every domain get registry lock?

No, and trying is how programs stall. Registry lock is a paid per-domain registry service that adds deliberate friction: changes require a callback to a named authorized contact during registry business hours. That is correct for names whose loss stops revenue, breaks authentication or intercepts mail, and disproportionate for a thousand defensive typo registrations. Tier the portfolio by consequence of loss, apply registrar-level locks universally because they are free, and reserve registry lock for the critical tier.

How often should I re-check the portfolio?

Continuously for the signals that indicate an attack in progress, and periodically for everything else. Poll registration data on a schedule and diff the structured response — status codes, nameservers, registrar of record, updated date, expiry date — alerting on any change rather than only on known-bad values. Review the full inventory, including account ownership and contact routing, at least annually and after any departure, acquisition or registrar migration. Checking once a year at renewal is not monitoring.

What is the single most overlooked control?

Hosting the registrant contact email outside the domain being protected and outside the registration account. SAC044 recommended it in 2010 and it is still the exception rather than the rule. Every alarm in the system — transfer notifications, authorization code delivery, expiry reminders, dispute notices — travels by email. If that email lands on the domain under attack, an attacker who repoints your MX records captures the alarm with the asset, and you find out when something visibly breaks.

Do defensive registrations need any security at all?

They need renewal discipline and the free locks, and generally nothing more. The realistic failure mode for a defensive registration is not theft but lapse: it expires unnoticed, someone else registers it, and the reason you bought it in the first place becomes a live problem. Keep them in the inventory, keep the expiry dates monitored, keep the client-prefixed locks on, and review the set periodically to drop the ones that no longer defend anything worth defending.

Does WHOIS privacy make a portfolio harder to secure?

It shifts the cost rather than removing it. Privacy reduces harvesting and targeted social engineering against your registrar account, which is a genuine benefit given that account compromise is the most common hijacking vector. What it takes away is public evidence of continuity of ownership — though post-2018 redaction has largely removed that regardless. Keep privacy, keep the underlying registrant data accurate because that is what a registrar will check, and maintain the private evidence file separately.