October is Cybersecurity Awareness Month in the United States and European Cybersecurity Month in the EU. The 2026 campaign of the US agency CISA, “Securing the Next 250”, puts avoiding and reporting phishing scams first among its four core steps. In the EU, a Eurobarometer survey published by the European Commission on 30 September 2026 found that three in four employees had come across suspicious emails, messages or links at work in the six months before the survey.
A company’s website, email and customer logins depend on its domain names, and five settings decide whether those names can be hijacked, lost or forged.
Who controls your domains?
Whoever holds the registrar account and the holder record, so check both: the lock on each name, and the contact data behind it.
Is your domain locked against transfers?
It should be. For .com and many country-code extensions, the domain’s public record shows it: the registrar lock appears as the status code clientTransferProhibited, which, as ICANN explains, tells the registry to reject requests to move the domain to another registrar. The codes clientUpdateProhibited and clientDeleteProhibited do the same for changes and deletion.
Some registries publish no lock status, for example nic.at for .at and DENIC for .de. For those, ask your registrar how a transfer is authorised.
A registry lock goes further. Codes that begin with server, such as serverTransferProhibited, are set by the registry, and some registries offer them as a lock service that is lifted only when the registrar asks the registry. Ask your registrar which of your names can have one.
To check, look the domain up with our whois lookup, which shows status codes for up to 20 names at a time, where the registry publishes them. Then check who can lift the lock: ICANN advises holders to enable multi-factor authentication on their registrar account where it is available.
Are the holder and admin contacts accurate?
They should name the company that owns the brand, with addresses and numbers it controls. EU registries have begun to verify this data under the national laws that implement the NIS2 Directive. EURid published a verification policy for .eu in October 2024, and Austria’s NISG 2026 act came into effect on 1 October 2026: .at holders must now give a telephone number as well as an email address, and must cooperate when asked to verify their data.
The Austrian registry warns that missing or late evidence may lead it to delete the domain. Under its NIS2 FAQ, a domain whose data is not verified within 21 days is put on serverHold, which stops its website and email, and is revoked if the data is not corrected within 30 more days.
Since 1 October, nic.at also publishes the phone number and email address of company holders in whois, which companies could hide before, so it recommends a central address and number rather than an employee’s own.
Expiry notices and verification requests go to these contacts. A domain held by a former employee, an agency or a subsidiary is hard to renew, move or defend, and a contact address on a domain that lapses can be taken over by whoever registers it. To check, ask your registrar for the full record of each domain, since public whois often hides holder data, and compare the holder with the company’s legal name.
Who receives the expiry notices for your domains?
The holder’s email address does. For generic extensions, ICANN’s Expired Registration Recovery Policy requires registrars to send at least two reminders, about one month and about one week before expiry, and another within five days after expiry if the name has been neither renewed nor deleted. All of them go to the registrant email address in the contact data.
After expiry, a registrar may offer an auto-renew grace period of 1 to 45 days. Once a generic domain is deleted, the registry must offer a 30-day Redemption Grace Period, during which the holder can restore it through the registrar, possibly for a fee. The DNS is cut before deletion and during redemption, so the website and email stop, including mailboxes on the domain itself. Country-code registries set their own rules.
To check, turn on auto-renew for every name in use, keep a valid payment method on file, send notices to a shared mailbox on another domain, and list the expiry dates of the next twelve months.
Can your domains be forged?
Yes, in the DNS and in email, unless the zone is signed with DNSSEC and every domain publishes SPF and DMARC.
Is DNSSEC switched on, and does it still match?
It should be wherever the registry supports it, with a DS record at the registry that still matches a key in your zone. Without DNSSEC, ICANN explains, a resolver cannot verify that a DNS answer is authentic, and an attacker who poisons its cache can send users to a copy of your site.
Our DNS zone check reads the DS record at the registry and the keys in your zone, and tells you whether they match, without verifying signatures. A missing or different key makes the domain fail for resolvers that validate DNSSEC, so run the check after every change of DNS provider. Not every registry supports DNSSEC: our DNS management page explains how we handle it.
The DNS root had its own date this month. ICANN planned for KSK-2024, the root zone’s new key signing key, to take over signing on 11 October 2026. A resolver that does not trust it (key tag 38696) treats answers signed under the new key as tampered with, so every lookup fails, as ICANN’s FAQ explains. If your company runs its own validating resolvers, check that they hold it, as ICANN’s rollover page asks.
Do all your domains authenticate email, including those that send none?
They should, because a domain that sends no email can be forged as easily as one that does. SPF lists the servers allowed to send its mail, DKIM signs each message, and DMARC tells receivers what to do with mail that fails.
The UK National Cyber Security Centre warns that a defensive registration does not protect a domain by itself, and advises protecting domains that send no email first, because once protected they need no maintenance. It lists four records, to be set in this order:
- SPF with no permitted senders: v=spf1 -all;
- DMARC at _dmarc with a reject policy: v=DMARC1; p=reject, plus a report address to see abuse;
- a null MX record, 0 ., when the domain has an address record but no mail server;
- optionally, a wildcard DKIM record with an empty key, which revokes any cached keys.
For sending domains, the NCSC’s implementation plan starts DMARC with a policy of none, which only collects reports, moves to quarantine once every genuine sender passes, then to reject. The zone check shows the SPF and DMARC records of any domain. DKIM keys sit under a selector that your mail platform sets, so check them there.
What should you do now?
Run the five checks across every domain you hold, then set a trigger for each.
| Setting | How to check | When to check again |
|---|---|---|
| Transfer lock and account access | Whois status codes where the registry publishes them; registrar account users and multi-factor authentication | When someone with account access leaves |
| Contact data | Full record from the registrar, against the company’s legal details | After a reorganisation, and on any registry request |
| Renewal and expiry | Auto-renew, payment method, notice address, expiry dates | A month before each expiry date |
| DNSSEC | Zone check: the DS record matches a key in the zone | After every change of DNS provider |
| SPF, DKIM, DMARC | Zone check; mail platform for DKIM; DMARC reports | When a service that sends email in your name is added or removed |
Domgate registers and manages country-code domains for brand owners and their advisers. It publishes SPF, DKIM and DMARC records and moves the DMARC policy to reject step by step. Its global domain strategy audit lists every name with its holder, contacts and expiry date, then sets rules for renewals and security, including a registry lock where the extension offers one.
