Domain Security Checklist: Registrar, DNS, Lookalikes

Start with the inventory

Every item below compares something found against something owned, so the comparison is worth no more than the list of what you own. Most organisations discover partway through their first review that the list does not exist, or exists in three places that disagree. Record it once, name an owner for each entry, and keep it where the people doing reviews can reach it.

• Every registered name, including country and campaign variants, because a review cannot tell yours from a stranger's without it.
• Which names send or receive mail, because those are the ones invoice fraud borrows and the ones that need mail records.
• Redirects and short links, because they tend to be bought by whoever needed one that afternoon and forgotten by everyone else.
• Defensive registrations, because they are the category most often mistaken for a threat by a later reviewer.
• For each name: who renews it, who can change its DNS, which registrar holds it, and when it expires.

Registrar account and registration

A lookalike is an outside problem. Losing control of a real domain is an inside one, and it is worse: an authentic name that changes hands carries every piece of trust you spent years building. Most of these items take minutes at the registrar, and the two locks are the ones that stop a transfer.

1. Turn on multi-factor authentication for every registrar login, because a registrar password is the credential that moves a domain.
2. Give each person their own login and review the list quarterly, because a shared account cannot be revoked when somebody leaves.
3. Set the registrar lock on every name (the clientTransferProhibited, clientDeleteProhibited and clientUpdateProhibited statuses), because ICANN's status reference says these help prevent unauthorised transfers, deletions and updates.
4. Ask for registry lock on the names that matter most, because it adds a manual step at the registry: Verisign's service for .com and .net requires an authorised person at the registrar to give a security phrase by phone before the name is unlocked.
5. Check the registry lock is really applied by reading the record: the word server and the word prohibited must appear on all three statuses, update, delete and transfer.
6. Make the billing and admin contact a role address, not a person, because renewals fail when the person leaves and the reminders go to a dead mailbox.
7. Put the recovery mailbox on a domain that cannot be lost with the account, because a reset link sent to the domain being stolen is sent to the thief.
8. Set expiry alerts on your own calendar and confirm auto-renewal, because lapse is a far more common cause of loss than attack. ICANN's expiry policy requires only two reminders, about a month and a week before expiry, so do not rely on them.
9. Know the 60-day rule: after a change of registrant, ICANN's transfer policy has the registrar impose a 60-day transfer lock unless the holder opted out beforehand, so plan ownership changes well before any move between registrars.
10. Treat the transfer authorisation code as a secret, because whoever holds it and can lift the lock can move the name.
11. Keep contact data accurate and let the registrar's privacy service or policy redaction hide personal details, because the Registration Data Policy requires personal data elements to be redacted in public lookups while the registrar's abuse contact stays published.
12. Log every change to nameservers and contacts, with who and when, because a hijack is first visible as a change nobody recognises.

DNS, email and certificates

These items stop somebody using your real name against you without ever touching the registrar account. They also cover the parked and defensive names, which are the ones most often left with no records at all.

1. Enable DNSSEC and publish the DS record at the registrar, because it provides origin authentication of DNS data so a resolver can detect forged answers.
2. Put nameserver changes under change control, because a nameserver swap redirects everything at once and the registrar record is where it happens.
3. Run DNS on more than one provider for names that must not go dark, because a single provider outage takes mail and web down together.
4. Publish SPF on every name that sends mail, and v=spf1 -all on every name that does not, because RFC 7208 provides for exactly that declaration on names never expected to originate mail.
5. Add a null MX (a single MX record with priority 0 and the name a single dot) on names that receive no mail, because RFC 7505 defines that as the way a domain announces it accepts none.
6. Sign outgoing mail with DKIM, because it separates the identity of the signer from the claimed author, and a receiver can check the signature.
7. Publish DMARC on the primary name and on every parked and defensive name, and move it from none to quarantine to reject as the reports allow, because only an enforcing policy stops a spoofed message being delivered.
8. Read the DMARC aggregate reports, because they tell you who is sending as you, which is the signal that finds abuse of your real name rather than a lookalike.
9. Publish a CAA record naming the authorities allowed to issue for your names, because RFC 8659 lets a domain holder restrict which CAs may issue certificates for it.
10. Watch certificate transparency logs for your own names, because every publicly trusted certificate is logged as it is issued and a certificate you did not request is an early warning.
11. Track TLS certificate expiry, because the CA/Browser Forum has adopted a schedule reducing maximum validity from 398 days to 47 days between March 2026 and March 2029, and manual renewal will not keep up.

Names you do not own

The second half of the checklist is the outside problem: names that resemble yours, registered by somebody else. The strategy guide in the learn section covers the reasoning about what to register and what to watch; this is the operating list.

1. Write the scope list: the primary domain, product names, abbreviations customers use, the endings customers assume, and the words that make a name look official, because a review that generates candidates for every string the company has ever used produces a queue nobody works.
2. Generate the variations and resolve them, because a list of names that could exist is not a list of names that do.
3. Check every finding against the inventory first, because a large share of first-run findings are the organisation's own defensive registrations.
4. Sort by the evidence in the records, not by how similar a name looks, using the priority table below.
5. Preserve the records for anything elevated on the day you find it, with timestamps, because the registrant can change all of it in minutes.
6. Run the check on a schedule and keep the report history, because the value is in what changed between one run and the next, and raise the frequency around launches and campaigns.
7. Publish one route for employees and customers to report impersonation, ask for the message with headers, never ask anyone to revisit a link, and acknowledge every report.
8. Respond in proportion: registrar and hosting abuse contacts for evidenced conduct, browser and mail blocklists for a live page, and a dispute only where you hold a mark and the facts support it. The reporting and takedown guides in the learn section carry the addresses and a template.
9. Record the ownership check, the evidence, who you told and what came back, and re-check afterwards, because a suspended name can be restored or re-registered once it drops.

Prioritise by evidence, not by resemblance

Sorting by how similar a name looks puts the wrong row first. Sort by what the records show, and keep an explicit category for the cases where the records showed nothing. This site's checker applies the same ordering from registry RDAP, DNS over HTTPS, certificate transparency logs and passive urlscan.io search, never connecting to a suspect site, and the rules behind each label are published on the methodology page.

What this checklist will not do

It will not find every impersonating domain. Generation covers the patterns it publishes, resolution covers the candidates it reaches, and a name registered an hour after a run is invisible until the next one. It will not tell you what a site contains, because the evidence comes from registry records, DNS, certificate logs and passive scan history, all of which can be read without touching the other party's server. That is a deliberate limit, and it is the reason the evidence holds up. And it will not make a finding mean more than it does: similarity is never proof of intent, and a priority label is a review order, not an accusation.

A checklist reduces how much depends on somebody noticing. It does not remove the need for someone to look.

Common questions

What should a domain security checklist include?

Two halves. For the names you own: registrar account hardening, registrar and registry locks, role contacts, expiry alerts, DNSSEC, SPF, DKIM and DMARC on every name including parked ones, CAA, certificate monitoring and TLS expiry. For the names you do not own: a scope list, a scheduled lookalike review, evidence-based priority, one reporting route and a written response.

What is the difference between registrar lock and registry lock?

Registrar lock is a set of client statuses your registrar applies that block transfer, deletion and update until you lift them in your account. Registry lock is applied at the registry and needs a manual, out-of-band step to lift: for .com and .net, Verisign phones an authorised person at the registrar for a security phrase.

Should parked domains have SPF and DMARC records?

Yes. A parked name with no records can be used to send mail in your name. Publish v=spf1 -all, a null MX, and a DMARC record with a reject policy on every name that sends nothing, which is exactly what RFC 7208 and RFC 7505 provide for.

Do I need DNSSEC?

It is the control that lets resolvers detect forged DNS answers for your name, and it costs nothing beyond publishing the DS record at the registrar and keeping keys rolled. Enable it, and put the DS record under the same change control as your nameservers.

How often should I check for lookalike domains?

Often enough that a name appearing in a public record is noticed before customers do. A quarterly run suits a one-off assessment; an operating brand wants a daily re-check with certificate log monitoring, raised around launches and campaigns.