ICANN Domain Policies: Effective Dates and Pending Changes

ICANN domain policy changes affect registration data, transfers and abuse handling, but adoption and implementation are different milestones. Status checked: 4 November 2026. This guide, first published in November 2025, has been updated to distinguish rules in force from reforms awaiting implementation. It focuses on generic top-level domains (gTLDs); country-code extensions have their own registration and transfer rules.

Which ICANN Changes Are Already in Force?

ICANN coordinates the DNS and other unique internet identifiers through a multistakeholder system. It does not sell domains itself. Its contracts and consensus policies govern contracted gTLD registries and accredited registrars within their stated scope. A company offering domain registration may also operate as a reseller; distinguish your service provider from the sponsoring registrar responsible under the ICANN agreement.

Those rules live in two main places:

• Contracts – Registry Agreements (RAs) and Registrar Accreditation Agreements (RAAs)
• Consensus Policies – developed by the ICANN community and made binding on contracted gTLD registries and ICANN-accredited registrars where applicable under their agreements

The following dates separate implemented changes from accepted recommendations. The practical sections below link to the primary documents behind each entry:

For each domain, record the sponsoring registrar, applicable extension rules, renewal date and responsible contact. This makes a policy notice actionable: you can identify the affected service and person instead of treating every announcement as an immediate change.

The Big Themes Behind Recent ICANN Domain Policy Changes

Individually, each ICANN update can feel small and highly technical. Put together, you can see four clear themes driving the new policies.

1. Privacy and Data Protection

After GDPR and similar laws, ICANN had to rethink the traditional, fully open WHOIS model. A lot of recent work has gone into defining:

• Which data elements must be collected at registration
• Which fields can be published publicly via RDAP
• How third parties can request non-public registration data
• How long registrars must retain your data

The result is a more standardized, privacy-aware registration data model that still lets law enforcement, trademark holders, and others request access under defined conditions.

2. Security, Abuse, and Stability

Domains can be used for phishing, malware distribution, and botnets. DNS abuse handling is one part of domain security; relevant measures include:

• Detecting and responding to DNS abuse reports
• Verifying contact details for registrants
• Supporting security features like DNSSEC where the TLD allows it

If you want a deeper dive into how DNS-level security hardens your presence, our article Domain Security Best Practices: Registrar Lock, DNSSEC, Whois Privacy and 2FA walks through practical security measures.

3. Simplifying and Modernising Operations

Lookup formats and transfer workflows serve different purposes. RDAP standardization is already in use; the broader Transfer Policy Review has a separate adoption and implementation process:

• Use RDAP for structured registration-data queries.
• Track the accepted TAC and transfer-notification recommendations as a future implementation project.
• Check current lock reasons and expiry dates before planning a registrar move.

These changes matter if you manage portfolios, do frequent registrar moves, or automate domain provisioning across multiple environments.

4. Competition and New gTLDs

The 2026 application round has moved beyond preparation: submissions closed on 12 August and applications were published on 7 October 2026. The later section explains the remaining stages. For the distinction between registering a domain and operating an entire extension, see our guide to ICANN’s new gTLD application round.

From WHOIS to RDAP and the New Registration Data Policy

For many years, WHOIS was the main way to look up who owned a domain. It was flexible but messy: each registry and registrar could output data in slightly different formats, often including full names, addresses, phone numbers, and emails in the clear.

Protocol modernization and personal-data protection are related but separate. ICANN’s RDAP overview says that from 28 January 2025 gTLD registries and registrars generally no longer have to offer WHOIS, with exceptions for .com, .name and .post. This does not mean that every WHOIS service was switched off.

• RDAP: A protocol for structured, machine-readable registration-data queries, with support for locating the authoritative service.
• Registration Data Policy: The policy effective 21 August 2025 defines collection, transfer, publication, disclosure and retention requirements. The protocol itself does not decide who has a right to personal data.

What This Looks Like for Domain Owners

In practice, you will notice:

• Structured results: Replace fragile free-text parsing with RDAP-aware handling, including redaction and optional fields.
• Contact privacy: Redacted data and relay addresses or web forms can support contact without publishing the registrant’s email. This differs from a privacy/proxy service.
• Organization field: When you provide Registrant Organization, the registrar must explain that it is considered the Registered Name Holder and explain the publication choice. Check that the intended legal entity is recorded.
• Contact accuracy: Keep the required registrant details accurate. Old administrative-contact data may be removed under the policy, so do not rely on it as your sole transfer contact.

Keep your domain contacts up to date. An old inbox you no longer check can have very real consequences: missed verification messages, complaints you never see, or support messages that bounce.

Data Retention and Disclosure Requests

Under the Registration Data Policy, ICANN-accredited registrars must:

• Retain the registration data needed for the Transfer Dispute Resolution Policy for at least 15 months after the end of sponsorship or an inter-registrant transfer, subject to the policy’s legal retention framework.
• Publish a process for disclosure requests and assess properly formed requests on their merits; a request does not guarantee access.
• Record disclosure requests, acknowledgements and responses. Where the registrar provides the policy’s registrant-email relay, keep confirmation that relaying occurred without recording sender, recipient, message content or personal data in that relay log.

The policy does not establish a blanket requirement to log every person’s access to every field. Its 12 May 2026 amendment also adds urgent-request rules, but the implementation note makes those obligations conditional on full implementation of a consensus-policy authentication process for requestors. Do not treat the expedited timelines as automatically active for all requests.

• Read your provider’s privacy notice to understand retention and contact handling.
• Use its published disclosure channel for non-public data and provide a specific basis for the request; disclosure can be refused with reasons.

For background on DNS records, which are distinct from domain registration data, see our DNS records guide.

Domain Transfer Rules: Codes, Locks, and Notifications

Domain transfer workflows have relied on authorization codes, often called EPP codes, and email-based Forms of Authorization (FOAs). Potential pain points include leaked long-lived codes, confusing email approvals, and misunderstandings about 60-day locks.

The current Transfer Policy is the version updated for the Registration Data Policy, with implementation required by 21 August 2025. Separately, the Board adopted the broader reform on 7 June 2026. As checked on 4 November 2026, that project remains in ICANN’s implementation queue. Board approval alone does not replace today’s transfer rules.

TAC Recommendations and Current AuthInfo Codes

The accepted Transfer Policy Review recommendations describe a more constrained TAC model. These are the planned rules, not a claim about features already available in your provider’s panel:

• Creation: The registrar of record generates and sets a TAC at the registry on the registrant’s or designated representative’s request.
• Lifetime: Recommendation 9 specifies 336 hours, equivalent to 14 days, from setting the TAC at the registry, enforced by the registry. Defined early reset conditions remain.
• Storage: Recommendation 10 places secure registry storage under RFC 9154. Its guidance discusses a salted one-way hash; this is not a universal requirement for registrars to retain only a hash.
• Today: Current policy still addresses AuthInfo, often called an EPP code. Where self-service is unavailable, it specifies provision of the code and removal of the applicable clientTransferProhibited status within five calendar days, subject to other valid transfer restrictions.

Request a transfer authorization code only when you are ready to transfer, and keep it private. Enable account 2FA and transfer notifications where your registrar offers them.

Transfer Emails and Notifications

The reform removes the gaining FOA requirement and revises the losing-side message as a Transfer Confirmation. Under the current framework, ICANN has already deferred enforcement of the gaining registrar’s FOA requirement, while the current registrar’s transfer-notification obligations remain. Check your provider’s actual flow instead of expecting two identical approval emails.

• Confirm that the requested domain and destination registrar match your plan.
• Keep access to the registrant’s monitored contact channel throughout the move.
• Keep transfer codes out of ordinary tickets and shared documents unless the provider supplies an appropriate secure channel.

If you receive a transfer notice you did not initiate, access your account through a known address and contact the sponsoring registrar promptly. Ask it to stop the transfer where still possible, invalidate any exposed code and investigate the account. Reset compromised credentials and sessions from a trusted device. Toggling a lock alone may not cancel an already pending or completed transfer.

60-Day Locks and Change of Registrant

Under the current policy, several restrictions need to be distinguished. A routine transfer lock, an initial-registration restriction, a recent-transfer restriction and a Change of Registrant lock are not interchangeable:

• Initial registration or recent transfer: The policy permits denial within 60 days of creation and within 60 days, or a shorter determined period, after an inter-registrar transfer. Check the relevant agreement and exceptions.
• Change of Registrant: A material change to registrant name, organization or email normally triggers a 60-day inter-registrar lock. If the registrar offers an opt-out, it must be chosen before the change request; it is not a guaranteed way to remove an existing lock.
• Accepted reform: Recommendations introduce a 720-hour (30-day) model after creation and inter-registrar transfer, and remove the current Change of Registrant transfer restriction. Implementation remains pending; do not schedule a current move on that basis.

Ask for the exact lock reason and end date. If you need both a registrar move and an ownership-data change, agree the order of operations with the registrar. Keep inaccurate contact data corrected; avoiding a lock is not a reason to leave false ownership details on file.

For the operational steps, see our domain-transfer migration guide and our guide to preserving email during a transfer. They cover DNS, MX and email routing that must be planned separately from registrar authorization.

DNS Abuse: Scope and Proportionate Response

The relevant RAA and Base Registry Agreement amendments took effect on 5 April 2024. Their DNS abuse definition covers:

• Malware.
• Botnets.
• Phishing.
• Pharming, typically redirecting users to fraudulent services through DNS hijacking or poisoning.
• Spam when it delivers one of the other four types.

This specific definition does not turn every unwanted message or content dispute into contractual DNS abuse. Other laws and agreement terms may still apply. For DNS abuse, registrar and registry responsibilities differ:

• Registrars must investigate reports and, after obtaining actionable evidence, promptly take reasonable and appropriate action to stop or disrupt the abuse.
• Registries must contribute by referring the domain and evidence to the sponsoring registrar or taking appropriate direct action.
• Responses must consider severity and collateral damage. A compromised page on a legitimate site may call for targeted remediation rather than suspending all web and email services.
• A report is not itself proof, and the advisory does not impose one fixed response deadline for every abuse case.

What This Means for Legitimate Domain Owners

A domain owner can be affected even without intentionally causing harm. Practical examples include:

• A compromised CMS page distributing malware can trigger abuse handling.
• An unattended or invalid contact address can prevent coordination of the fix.
• A spoofed or compromised email campaign requires investigation of its actual activity; high volume or missing authentication alone does not establish the contractual DNS abuse definition.

To reduce this risk, we recommend:

• Keep applications patched, restrict administrative access and protect accounts with MFA where available.
• Use appropriate WAF rules and recoverable backups; preserve relevant incident evidence before cleanup.
• Configure SPF, DKIM and DMARC for legitimate mail without treating authentication as proof that a message is harmless.
• Use DNSSEC with a valid trust chain and validating resolvers where supported; it does not prevent a compromised CMS or account from serving malicious content.

You can explore these angles further in our articles on domain security best practices and our step-by-step guide to SPF, DKIM, DMARC and rDNS.

The 2026 gTLD Round: Applications and Remaining Stages

ICANN’s 7 October 2026 announcement confirms that submissions were accepted from 30 April to 12 August 2026 and applications were published on 7 October. As of 4 November, String Confirmation Day is scheduled for 17 November 2026. Evaluation, objections where applicable, contracting and delegation remain distinct stages; application publication is not approval.

What the Published Rules Mean

The authoritative Applicant Guidebook version is V3, dated 7 October 2026. Relevant distinctions include:

• Eligibility: An application to operate a TLD is for an established eligible legal entity, not an individual buying an ordinary domain. The submission window for this round has closed.
• Operational duties: Applicants and operators face evaluation and contractual requirements. Registry-level DNSSEC and IPv6 obligations do not automatically configure individual customer domains.
• Closed generics: Exclusive-use generic TLDs are not approved without an approved methodology and criteria. A qualifying .Brand is a distinct category, not a blanket exception for anyone asserting a trademark.
• IDNs: Internationalized strings follow script and variant rules; software and email compatibility still require testing.

For an ordinary domain portfolio, monitor relevant applications and rights-protection opportunities without assuming that every applied-for extension will become available or launch on a particular date.

For practical naming decisions, see our ccTLD, gTLD and brand-protection guide. Country-code rules, audience expectations and the project’s actual purpose belong in that decision alongside availability.

Checks for Domain Owners and Agencies

Translate each policy change into an owner, an affected system and an action date. Confirm what your provider handles and what your team must maintain; an announcement alone is not evidence that a particular panel feature has been deployed.

Questions to Resolve With Your Provider

• Registration data: Which contact and organization values are stored, published or redacted, and where are disclosure requests submitted?
• Transfers: How do you request AuthInfo, identify a lock and find its end date? What further changes will follow the reform’s eventual implementation?
• Security: Which MFA, registrar-lock and DNSSEC options are supported for your account and TLD?
• Abuse: Where should evidence go, who coordinates remediation and how will the outcome be confirmed?

A Practical Portfolio Checklist

To stay comfortably ahead of ICANN’s domain policy changes, we recommend you:

1. Keep contact data current: Update changes promptly and add a periodic portfolio audit. Use organization-controlled addresses and a recovery route that works if the domain’s email fails.
2. Protect account access: Enable MFA where offered and store recovery codes securely. MFA reduces risk but cannot prevent every unauthorized session or workflow.
3. Review locks: Keep routine transfer locking enabled outside planned moves; record policy-lock reasons separately.
4. Plan early: Coordinate current 60-day restrictions, any ownership change, renewal dates and the migration window.
5. Manage DNSSEC deliberately: Verify provider support, signatures, parent DS records and the rollover process.
6. Assign ownership: Record the legal entity, authorized contacts and people responsible for DNS, renewals and incident response.

If you are exploring new domains or cleaning up your portfolio, our guide The First 30 Days After Buying a Domain: DNS, SSL, Email and SEO Checklist is a useful companion checklist.

Fitting Policy Changes Into Your Broader Hosting and DNS Strategy

ICANN policies focus on domains, but the ripple effects hit your DNS, hosting, and email setup. A transfer held up by a lock can delay a migration; a verification email stuck in spam can lead to unexpected domain suspension.

Plan Around DNS, Not Just Registrar

A registrar transfer does not inherently change DNS records, nameservers, hosting or email. If the project also changes these services, inventory:

• Nameservers and zone hosting
• MX records, SPF/DKIM/DMARC for email
• A, AAAA, and CNAME records for your website

For a combined registrar and DNS migration:

• Check current transfer restrictions and obtain AuthInfo through the provider’s secure process.
• Lower relevant TTLs only when DNS data is changing, and allow the previous TTL to expire before relying on the shorter value.
• Keep old and new DNS service available as needed, verify MX and authentication records, and coordinate DS/DNSSEC changes. Confirm whether registrar-provided DNS ends when the transfer completes.

Our articles on diagnosing DNS errors like DNS_PROBE_FINISHED_NXDOMAIN and The Friendly Guide to Private Nameservers and Glue Records can help you design a migration plan that respects both DNS mechanics and ICANN transfer requirements.

Think About the Full Domain Lifecycle

The Expired Registration Recovery Policy sets baseline renewal-notice, recovery and fee-disclosure rules. Actual deletion, service interruption and recovery options also depend on the extension and registrar’s terms. Do not assume a universal grace period or a guaranteed opportunity to buy a deleted domain back.

If you have not mapped this lifecycle for your critical domains, start with our explanation of the domain lifecycle and expired domain backorders. Understanding how ICANN’s baseline rules interact with each TLD’s specifics will make your renewal strategy much calmer.

Start With the Domains Your Services Depend On

ICANN domain policy changes can look distant and bureaucratic when you see them as PDF documents or meeting minutes. But the impact shows up in very concrete ways: how your contact data is stored and published, how easily you can move a domain to another registrar, what happens when someone reports abuse, and how many TLD options you have for new projects or brands.

Start by checking ownership data, current lock reasons and renewals for domains used by email, customer access or payments. Then review RDAP integrations and the abuse-reporting route. Follow the official implementation status before changing a process to match an announced reform.

Open your DCHost account through a known address and review the settings available for each domain. Where a lock, contact change or DNSSEC action is unclear, give support the domain and intended operation through the appropriate channel. Agree the next step and responsible party before changing a service on which the business depends.