Domain registration identity verification in the .RU/.РФ zones: what foreign owners need to know

In short. Registrars in the .RU and .РФ zones are progressively introducing identity verification of the domain administrator — the person or company the registry holds responsible for a domain. Verification is increasingly performed through the Russian state identity system rather than a simple email click. If the administrator's data is not confirmed, the registrar may suspend delegation, and the domain stops resolving for the web and for mail.

Disclaimer. Registration rules for the .RU and .РФ zones are set by the Coordination Center for TLD RU/РФ — cctld.ru. Identity requirements, accepted documents and deadlines change over time, and each accredited registrar implements the procedure in its own way. Always check the current version of the rules and the notices from your registrar before acting. This article explains the mechanics and the operational risk; it is not legal advice.

What makes .RU and .РФ different from gTLDs

If your experience is with .com, .net or .io, the mental model you carry over is mostly wrong in one important way. In gTLDs, the accountability model is built around contactability: the registrar must be able to reach the registrant. In the .RU and .РФ zones, the model is moving toward identity: the registry-side rules push registrars to know who the administrator actually is, verified against state records rather than against a mailbox.

Three practical consequences follow from that difference:

• A working mailbox is no longer sufficient. Confirming an email proves someone read a message, not that the named person exists.
• The verification pathway of least resistance is the Russian state identity and authentication system, commonly known to users as the Gosuslugi account. A registrar redirects the administrator to a state login page, the administrator consents to data sharing, and the registrar receives attested identity attributes instead of free-text form input.
• Foreign administrators are not excluded, but they fall outside the automated path and are handled through document-based verification, which is slower and more manual.

Ignore the deadline rumours. Statements like "from date X every domain without state verification will be shut down" circulate widely and are usually a distortion. The rollout is staged, registrars enable checks at different times, and requirements for existing domains typically differ from requirements for new registrations. Act on the notice from your registrar and on the published rules, not on a forwarded message.

The domain administrator: the role the registry actually holds responsible

Russian domain terminology separates roles more sharply than the gTLD word "registrant" suggests, and the distinction decides who has to pass verification.

• Administrator (администратор домена) — the individual or legal entity the domain is registered to in the registry. The administrator decides how the domain is used, renews it, changes nameservers and transfers it to another party. This is the party that must be identified, and the party answering in a dispute.
• Registrar — an organisation accredited to work with the registry. It does not own your domain, but it enforces the rules: it verifies data, sends notices, and suspends delegation when requirements are unmet.
• Website owner, hosting customer, content manager — whoever actually runs the site. This is frequently not the administrator. The classic failure pattern is a site paid for by a company but registered under a developer's or an agency's personal account.

For a foreign business the second failure pattern matters more: the domain was registered years ago by a local partner, a local subsidiary that has since been restructured, or a marketing agency that "handled everything". In all three cases the entity that must complete verification is not you, and you have no way to complete it on their behalf.

How this compares to ICANN WHOIS verification and GDPR redaction

Two mechanisms in the gTLD world look superficially similar and are worth contrasting precisely, because assuming equivalence is how people misjudge the risk.

ICANN registrant contact verification. Under the registrar accreditation framework, a registrar must verify the registrant's email address (or telephone number) after a new registration or a change of contact data. If verification is not completed within the specified window — commonly 15 days — the registrar is required to suspend the domain. That is a real suspension mechanism with real outages behind it, and it is the closest gTLD analogue to what happens in .RU/.РФ. The critical difference: it validates a channel, not a person. Any working mailbox passes it.

GDPR-driven redaction of registration data. Since 2018, public RDDS/WHOIS output for gTLDs redacts personal data of natural persons by default; contact happens through an anonymised address or a web form. People often read this as "WHOIS privacy means nobody knows who I am". That is not what it means: the registrar still holds the data, redaction only removes it from public output.

The .RU and .РФ zones landed on a similar public-output outcome long before GDPR, via a different route. Personal data of individual administrators is not published — the record shows Private Person instead of a name — while organisation names are generally shown. So public exposure is comparable to a redacted gTLD record. What differs is the strength of what sits behind the redaction.

Aspect	gTLDs (.com, .net, .io)	.RU / .РФ
What is verified	Contactability: email or phone reachability	Identity of the administrator, checked against state or corporate records
Typical mechanism	Click a confirmation link sent to the registrant address	State identity system login, electronic signature, or document-based check
Consequence of failure	Registrar suspends the domain until verification completes	Registrar may suspend delegation until data is confirmed
Public WHOIS output for individuals	Redacted for privacy reasons	Shown as Private Person; organisation names generally visible
Legal driver	Registrar accreditation contract, GDPR for redaction	Registry rules set by the Coordination Center; national information law
Foreign holders	Fully supported, no special path	Supported, but outside the automated flow: manual, document-based, slower

What happens if verification is not completed

Two outcomes get conflated, and only one of them is likely here.

• Suspension of delegation. The registry entry survives and the domain is still yours, but nameservers stop being served from the zone. Users see a domain that does not resolve. Mail dies at the same moment. Restore the underlying cause and delegation comes back.
• Cancellation of registration. The name is released and becomes available to anyone. This is normally tied to an expired registration term, not to a single failed verification.

Under-estimating the first one is the common mistake. Losing delegation is not only "the website is down". Mail stops flowing, which also means you cannot receive password resets anywhere else. Integrations that resolve the hostname start failing. DNS-based certificate issuance and renewal break, so you may come back to an expired certificate on top of everything else. And if the outage lasts, search visibility degrades on its own schedule.

Typical situations for foreign owners

Situation	Risk	What to do
Domain registered to a local employee's personal account	The domain leaves with the person; the company cannot complete verification on their behalf and has no formal claim	Start an administrator change to the legal entity while the relationship is intact; document the handover
Domain held by a local agency or system integrator	The agency is the administrator and you are merely a user; changing vendor becomes a negotiation about your own brand	Request an administrator change to your entity; put domain ownership in the contract, not in an email thread
Domain registered to a subsidiary that was restructured, renamed or liquidated	The registered entity no longer exists in the form recorded, so verification cannot succeed as recorded	Confirm the current legal successor with counsel, then perform a documented administrator change before any renewal
Administrator contact email points to a departed employee or a dead mailbox	Verification and renewal notices go nowhere; the first signal you receive is the outage itself	Move the contact to a monitored group address on a different domain, read by at least two people
Foreign individual or company as administrator, no local identity account	The automated path does not apply; document-based verification takes longer than you expect	Start early, keep certified corporate documents ready, and never leave it until the final days of the paid period
Domain acquired with a business or bought from a third party, registry record never updated	Nobody can verify as the recorded administrator; in a dispute the registry record is what counts	Complete a formal administrator change through the registrar before investing in the brand on that name

How to read WHOIS for .RU and .РФ, and how renewal works

The .RU/.РФ WHOIS output is terse but informative. Note that the registry expects the punycode form for internationalised names.

# Status and registry data for a .RU domain
whois -h whois.tcinet.ru example.ru

# .РФ is an IDN zone: convert the name to punycode first
python3 -c "print('пример.рф'.encode('idna').decode())"
# -> xn--e1afmkfd.xn--p1ai
whois -h whois.tcinet.ru xn--e1afmkfd.xn--p1ai

A typical response for a domain held by an individual:

domain:        EXAMPLE.RU
nserver:       ns1.example.ru.
nserver:       ns2.example.ru.
state:         REGISTERED, DELEGATED, VERIFIED
person:        Private Person
registrar:     EXAMPLE-REG-RU
admin-contact: https://<registrar contact form>
created:       2012-03-14T21:00:00Z
paid-till:     2026-03-14T21:00:00Z
free-date:     2026-04-14
source:        TCI

How to read it:

• state is the field that matters. REGISTERED means the record exists; DELEGATED means nameservers are served from the zone and the domain resolves; the verification flag (VERIFIED / UNVERIFIED) reflects whether the administrator's data has been confirmed. If DELEGATED disappears, the domain is alive but non-functional.
• person shows Private Person for individuals; an org line carries the organisation name for legal entities. You cannot learn which individual holds the domain from public output — that lives in the registrar's account panel.
• paid-till is the end of the paid period; free-date is the approximate date after which the name may be released.
• nserver is what the registry actually publishes. A mismatch with your intended configuration is worth investigating immediately.

Field-by-field reading for other zones is covered in the WHOIS lookup guide. To confirm delegation independently of your own resolver:

# Ask the .RU zone servers directly, without recursion
dig NS example.ru @a.dns.ripn.net +norecurse

# What an ordinary resolver sees
dig +short NS example.ru
dig +short A example.ru

# Are the authoritative servers themselves answering
dig +short SOA example.ru @ns1.example.ru

Registration term, auto-renew and transfers

Identity verification is not the most common way to lose a domain — expiry still is. And the two now share a single point of failure: the administrator's mailbox. A stale contact address breaks renewal notices and verification notices simultaneously.

• Registration in .RU/.РФ is normally annual and renews annually. Multi-year prepayment is often available, but the renewal mechanism stays yearly — do not treat a domain as bought outright.
• Auto-renew fails in three predictable ways: the card expires, the account balance is insufficient, or the subscription silently detaches after a payment-method change. Keep it enabled, but never treat it as the control.
• Expiry is staged, not instant. Delegation is dropped first, then a window exists in which only the former administrator can renew, and only then is the name released. The site and mail are already down at step one, so the buffer is not a safety net.
• Changing the administrator is not the same as transferring between registrars. The first changes who owns the record, the second only changes who services it. Confusing them wastes weeks. The domain transfer checklist covers what to verify before and after.

A five-minute independent check, suitable for cron:

#!/usr/bin/env bash
# check-domain.sh example.ru — registry state and days left
set -euo pipefail
DOMAIN="${1:?usage: $0 domain.ru}"

RAW=$(whois -h whois.tcinet.ru "$DOMAIN")
STATE=$(printf '%s\n' "$RAW" | awk -F': +' '/^state:/ {print $2; exit}')
PAID=$(printf '%s\n' "$RAW"  | awk -F': +' '/^paid-till:/ {print $2; exit}')

# GNU date; on macOS install coreutils and use gdate
LEFT=$(( ( $(date -d "$PAID" +%s) - $(date +%s) ) / 86400 ))

printf '%s | state: %s | paid-till: %s | days left: %s\n' \
  "$DOMAIN" "$STATE" "$PAID" "$LEFT"

case "$STATE" in
  *UNVERIFIED*) echo "WARN: administrator data is not confirmed" ;;
esac
case "$STATE" in
  *DELEGATED*) : ;;
  *) echo "CRIT: domain is not delegated — web and mail are down" ;;
esac
[ "$LEFT" -lt 30 ] && echo "WARN: less than 30 days of paid period left"

A cron job is a reasonable floor, but it goes quiet exactly when the host running it goes quiet. Past a handful of domains, use external checks — the approach is described in domain expiry monitoring.

How to check your domain

• Registry data and status — WHOIS lookup: read state, paid-till, nserver and the verification flag. A missing DELEGATED explains an outage on its own.
• Whether a name you want is available — the same WHOIS tool; a taken name returns a record, a free one returns no object. Method and edge cases: how to check domain availability.
• Whether the site is blocked in Russia — blocklist check. A domain can be delegated and healthy yet unreachable for a large share of local users for an unrelated reason. Next steps are in the guide for owners of blocked sites.
• Personal-data obligations on the site itself — Russian personal data compliance check. Administrator identity and user-data handling are separate obligations, but they tend to be reviewed together.
• DNS after any change — DNS record check plus uptime monitoring, so a suspended delegation does not reach you through a customer first.

Frequently asked questions

Can a foreign company still register and hold a .RU domain?

Registrars have long worked with foreign administrators, verifying identity through documents rather than the domestic identity system. Expect a manual, slower process with certified corporate documents and possibly translations. Requirements vary between registrars, so confirm the exact list before you need it; a comparison of registrar approaches is in the domain registrar overview.

Is state identity verification the same as ICANN's email verification?

No. ICANN's mechanism proves that a mailbox is reachable and can be satisfied by anyone holding that mailbox. Identity verification proves who the administrator is against an authoritative record. The operational consequence is similar — a domain can be suspended if the check is not completed — but the bar being cleared is different.

Will my personal details become public in WHOIS?

No. Public WHOIS output for .RU/.РФ hides personal data of individuals and shows Private Person instead of a name; contact is routed through the registrar's form. Organisation names are generally visible, which matches practice in most zones since a company name is public anyway.

What happens to domains registered years ago?

They are generally not switched off in one sweep. The realistic pattern is a confirmation requirement triggered by the next significant action — renewal, contact change, transfer — or by a direct notice. The danger is not the requirement itself but the fact that it arrives at a mailbox you may no longer control.

Our domain is held by a Russian subsidiary. Who passes verification?

The legal entity in the registry record, acting through an employee whose authority can be confirmed. Verify in advance that a current, authorised employee is attached to the organisation profile used for verification. This is the step that most often stalls, because the person who set it up has usually left.

How much warning will we get before delegation is suspended?

Notices normally precede suspension, but the length of that window is not something you control, and it depends on notices actually reaching you. Treat the registry state field as your source of truth and poll it yourself rather than waiting for email.

Checklist

• List every domain the group holds, including parked names, redirect-only names and mail-only names.
• Run WHOIS on each and record state, paid-till and nserver; flag anything without DELEGATED or marked unverified.
• Open each registrar account and compare the recorded administrator against the entity that should actually hold the domain today.
• Replace administrator contact addresses with monitored group mailboxes hosted on a different domain than the one they administer.
• Identify domains held by employees, agencies or restructured entities and start administrator changes now, not at renewal time.
• For entity-held domains, confirm that an authorised, currently employed person is attached to the profile used for verification.
• Enable auto-renew where missing, and add an independent reminder at 60 and 30 days before paid-till.
• Add uptime and DNS monitoring so a suspended delegation is detected in minutes, not by a customer.
• If you are choosing new names, decide the holding entity before registering — see the domain name selection guide.
• Repeat this review quarterly; registry data ages silently.