ICANN’s New Domain Policies: What’s Changing and How to Prepare

ICANN has quietly been reshaping the rulebook that governs how domains are registered, transferred, protected and even how your contact data is handled. If you manage more than a couple of domains for your business or clients, these changes are not abstract policy talk — they directly affect how fast you can move domains between registrars, how safely you can delegate DNS, and what happens when something goes wrong with abuse or disputes. At dchost.com, we have been tracking these updates closely, because every change in ICANN policy eventually turns into new workflows in our domain panel, our DNS platform and our support playbooks. In this article, we’ll walk through the most important new ICANN domain policies, what they mean in real life (not just in legal language), and the exact steps we recommend to keep your domains secure, compliant and easy to manage over the next few years.

ICANN’s Role and Why Its New Policies Matter

Before diving into the updates, it’s worth clarifying what ICANN actually controls. ICANN (the Internet Corporation for Assigned Names and Numbers) does not sell domains directly. Instead, it sets the contracts and policies that all accredited registries (like .com, .org, many country-code and new gTLD operators) and registrars must follow. Those contracts define how:

• Domains are created, transferred, renewed, expired and deleted.
• Registrant (owner) data is collected, published or hidden.
• Disputes and trademark conflicts are resolved.
• Security, DNS abuse handling and technical standards are enforced.

When ICANN updates a policy, it rarely feels immediate. But within months, registrars and hosting providers like dchost.com must update control panels, APIs, documentation and even our internal support procedures. That’s why you started seeing changes such as transfer codes being called TACs instead of EPP, extra confirmation steps when updating contact details, or more structured abuse complaint workflows. Understanding the intent behind ICANN’s new rules helps you plan your domain strategy instead of just reacting to new forms and emails.

The New Transfer Policy: TAC Codes, Timing and Security

One of the most visible areas of change is the Inter-Registrar Transfer Policy (IRTP) — the rules that govern moving a domain from one registrar to another. ICANN has been modernising this policy to reduce friction for legitimate owners while tightening security against hijacks.

From EPP Codes to TAC: What Actually Changed?

Historically, you used an “EPP auth code” to transfer a domain. In the new policy language, this is now called a Transfer Authorization Code (TAC). It’s more than a rename:

• TACs have stricter lifetime limits. They are expected to be generated on demand and expire quickly, not sit in your panel for years.
• Registrars must protect TACs as sensitive data. That means secure delivery channels and masking them from logs or emails wherever possible.
• The losing registrar’s role is more clearly defined. They must provide the TAC promptly upon authenticated request, rather than quietly slowing the process.

In practice, when you request a transfer out from dchost.com, you’ll see a streamlined way to generate the TAC, copy it securely and initiate the transfer with the gaining registrar. On our side, we treat TACs like passwords: they are generated just-in-time and protected in storage and logs.

Fewer Confirmation Emails, But Stricter Identity Checks

Previous versions of the transfer policy relied heavily on email-based Form of Authorization (FOA) messages sent to the registrant or admin email. That system led to a lot of confusion, bounced messages and failed transfers. The new approach focuses more on:

• Authenticating you inside the registrar account (login, 2FA, IP checks).
• Logging and auditing how and when TACs are requested and used.
• Reducing redundant email confirmations when you are clearly authenticated.

This is good news operationally: fewer lost FOA emails, fewer stalled transfers, and a stronger focus on real security controls instead of hoping email cannot be compromised. At dchost.com we combine ICANN’s rules with our own protections such as registrar lock, DNSSEC support and account-level 2FA. You can dive deeper into these controls in our guide on domain security best practices like registrar lock, DNSSEC, WHOIS privacy and 2FA.

Operational Tips for the New Transfer Landscape

Based on what we see in daily operations, here is how to stay ahead of transfer-related policy changes:

• Standardise contact emails. Use a stable, monitored email (like [email protected]) for all domain contacts, not personal inboxes that may change.
• Enable 2FA on your registrar account. Under the new policy, account authentication is the primary trust anchor.
• Document internal procedures. Agencies and IT teams should define who can request TACs and transfers, and how approvals are recorded.
• Plan transfers outside launch windows. For sites with major releases or campaigns, avoid unnecessary registrar moves during critical weeks.

If you’re planning a portfolio-wide transfer to consolidate domains at dchost.com, we can help build a batch transfer plan that respects these rules while minimising downtime and bureaucratic back-and-forth.

Registration Data, Privacy and the New WHOIS/RDAP Reality

Another area with big changes is how registrant data is collected, stored and displayed. The old public WHOIS model exposed nearly all contact details by default. Post-GDPR, ICANN had to rethink this model and is now rolling out a more granular Registration Data Policy based on RDAP (Registration Data Access Protocol).

From Public WHOIS to Layered Access

The direction of travel is clear: less unnecessary public exposure, more structured access for those who need it. Key points:

• Default redaction for personal data. Many fields (name, address, email, phone) are now hidden from anonymous WHOIS/RDAP queries for natural persons.
• Emphasis on legal basis and purpose. Registrars must be able to justify why they collect each data element and how long they retain it.
• Tiered disclosure systems. Verified requesters such as law enforcement or rights holders may gain more access through defined channels, rather than scraping public WHOIS.

For you as a domain owner, this means slightly more structured consent and privacy options at registration time. For us as your provider, it means more precise data handling policies, audit logs and clear documentation.

Contact Validation and Accuracy Requirements

ICANN has always required registrars to maintain accurate contact data, but enforcement is tightening. Expect:

• More frequent checks that your email address is reachable.
• Occasional verification requests if there are signs of inaccuracy or abuse reports.
• Clearer timelines for suspension when contact data is provably wrong and remains uncorrected.

Ignoring those “please verify your email” messages can ultimately lead to suspension under ICANN policy, not just registrar preference. To avoid last-minute panic, we recommend centralising domain contact management. Our article on domain portfolio management and organising renewals, billing and brand protection walks through practical ways to keep dozens or hundreds of domains under control.

What This Means for Your Compliance and Security

These registration data changes intersect with security and legal obligations:

• For privacy and data protection laws: ICANN-aligned collection and retention rules help you stay compliant with frameworks like GDPR or local equivalents, assuming you also manage your own internal records responsibly.
• For brand and fraud response: You may need to rely more on official disclosure channels and UDRP/URS processes instead of quick WHOIS lookup when dealing with abusive domains.
• For operations: Clean contact data and central management become non-negotiable, especially when renewing or transferring critical domains.

At dchost.com we align our domain registration flows with ICANN’s evolving registration data requirements, and we maintain clear logs of consent, changes and verification steps — so if you ever need to prove who controlled a domain at a given time, the evidence is there.

DNS Abuse, Security Expectations and Hosting Responsibilities

ICANN has also turned up the pressure on DNS abuse mitigation. While ICANN does not police content, it is increasingly explicit that registries and registrars must act fast when domains are used for clear technical abuse such as phishing, malware distribution or botnet command-and-control.

What Counts as DNS Abuse Under ICANN’s Lens?

ICANN documents typically highlight:

• Malware distribution and exploit kits.
• Phishing (credential harvesting, payment fraud).
• Botnets and command-and-control domains.
• Spam when it is directly tied to abuse infrastructure.
• Domain name or DNS manipulation to enable other technical abuse.

The message to contracted parties is: “You must have processes to receive, evaluate and act on credible abuse complaints.” That is why you might see faster suspensions for obviously malicious domains and more detailed abuse handling documentation from registrars.

What This Means for Your Hosting and Email Infrastructure

For legitimate operators, the key risk is collateral damage: misconfigured email servers that look like spam sources, compromised CMS sites used for phishing kits, or DNS records pointing to unsafe services. To avoid being mistaken for abuse:

• Harden your email infrastructure. Proper SPF, DKIM, DMARC and rDNS reduce the chance of your domain being flagged. Our step-by-step guide on improving email deliverability with SPF, DKIM, DMARC and rDNS is a good starting point.
• Secure your servers and applications. Use up-to-date PHP, CMS versions, strong passwords, and application-level firewalls. For VPS users, our article on securing a VPS server against real-world threats shows practical hardening steps.
• Monitor for anomalies. Unexpected outbound mail volumes, strange scripts in web roots or unexplained DNS changes are early warning signs.

At dchost.com, we combine ICANN-mandated abuse handling with proactive security: network-level protections, WAF options, and clear incident response processes. If we receive an abuse report about one of your domains, our goal is to work with you to fix the root cause before any drastic measures like suspension are necessary.

New gTLD Rounds, Closed Generics and Brand Strategy

ICANN’s policy work is also paving the way for the next round of new generic top-level domains (gTLDs). This is less about everyday transfers and more about long-term brand and naming strategy, especially for enterprises and ambitious projects.

The Next gTLD Application Round

ICANN is preparing another application window where organisations can apply for their own TLDs (for example, .brand, .city, .community). The policy work here includes:

• Clarifying application evaluation criteria.
• Setting rules for contention sets (when multiple applicants want the same string).
• Defining rights protection mechanisms to protect trademarks.
• Debating “closed generics” (e.g. a single company owning a generic term like .book exclusively).

If you’re considering your own TLD or want to understand how new gTLDs might reshape your namespace strategy, our deep dive on ICANN’s next gTLD application round and when it makes sense to think about your own extension is a helpful companion to this article.

Practical Impacts Even If You Never Apply for a TLD

Even if you never plan to run a registry, new ICANN policies around gTLDs still matter:

• More options for defensive registration. Each new TLD is another place where someone could potentially register a name similar to your brand.
• More opportunities for targeted naming. Niche TLDs can be useful for campaigns, language variants or geographies.
• More complexity in protection mechanisms. Sunrise periods, trademark claims services and blocking products all stem from ICANN’s rights protection policies.

Our article on defensive domain registration strategies including typosquats, IDNs and brand TLDs goes deeper into concrete tactics for protecting your name across an expanding TLD landscape.

Domain Lifecycle, Expirations and Policy-Driven Deadlines

ICANN’s policies don’t just affect registration and transfer; they also standardise what happens when a domain expires. While exact timings can vary slightly by TLD, common concepts such as Auto-Renew Grace, Redemption Grace and Pending Delete are defined at policy and registry level.

Why ICANN’s Lifecycle Rules Matter Operationally

Recent policy clarifications and contract updates have emphasised:

• Clear communication about upcoming expirations and consequences.
• Consistent windows for recovery after expiry (with or without redemption fees).
• Transparency about what happens to domains that are not renewed (e.g. auction, backorder, deletion).

For businesses, this means you should treat expiry as a policy-driven process, not a mystery. If you miss a renewal, you will typically have a short no-penalty window, then a more expensive redemption period, then final deletion. We’ve explored this in detail in our guide to domain lifecycle and catching expired domains, including grace, redemption and pending delete stages.

Best Practices in Light of ICANN’s Lifecycle Policies

To avoid unwanted surprises:

• Use auto-renew wherever possible. ICANN’s policies assume auto-renew as the default for most TLDs; embrace it rather than relying on manual reminders.
• Consolidate billing and contacts. One central account at dchost.com with aligned billing cycles and contacts is far easier to manage than scattered domains across different providers.
• Define internal SLAs. For mission-critical domains (payment gateways, corporate email, main brand site), write down internal rules: how many days before expiry will you act, who is responsible, what escalation exists.

ICANN’s lifecycle rules give the structure; your internal processes provide the safety net.

How dchost.com Aligns With ICANN’s New Domain Policies

Because ICANN policies are implemented at registrar and registry level, the quality of your provider directly affects how painless or painful these changes feel. At dchost.com, we’ve been steadily updating our systems to match the new requirements while keeping the user experience straightforward.

Security-First Domain Management

To reflect new transfer and registration data policies, we focus on:

• Strong account security: robust authentication, optional 2FA and detailed event logging for domain changes.
• Safe TAC handling: on-demand generation, limited visibility and secure interfaces.
• Integrated DNSSEC and registrar lock: so transfer and DNS tampering attempts are clearly visible and controllable.

These measures are tightly integrated with our hosting, VPS, dedicated server and colocation platforms, so that your DNS, web and email infrastructure all live behind consistent security standards.

Policy-Aware Support and Documentation

When ICANN updates a policy, we update not just the control panel but also our documentation and support scripts. That means when you ask “Why did my transfer behave like this?” or “Why are these contact details required?”, you’ll get an answer anchored in ICANN rules, not guesswork. For a deeper dive into the broader 2025 landscape, we recommend reading our article on ICANN domain policy changes and what they mean for your domains in 2025, which complements this piece with additional timelines and edge cases.

End-to-End Domain and Hosting Strategy

ICANN policies don’t live in isolation. They interact with SEO, branding, security, performance and cost. Because we provide domains, DNS, shared hosting, VPS, dedicated servers and colocation under one roof, we can help you:

• Design domain naming and TLD strategies that align with your hosting architecture.
• Place critical domains on infrastructure with the right redundancy, SLAs and backup policies.
• Integrate SSL/TLS, DNSSEC and email authentication from day one of a new domain’s life.

If you’re starting from a fresh registration, our checklist on what to do in the first 30 days after buying a domain, including DNS, SSL, email and SEO ties all of this together into a practical step-by-step plan.

Action Plan: What You Should Do in the Next 12–24 Months

Putting policy language aside, here is a concrete checklist we recommend for domain owners, agencies and IT teams who want to stay ahead of ICANN’s new domain policies.

1. Clean Up Contact Data and Access Control

• Standardise registrant, admin and technical contacts on stable, monitored email addresses.
• Enable 2FA on your dchost.com account and restrict domain management permissions to the right people.
• Document who is allowed to request TACs and transfers, and how those requests are approved.

2. Consolidate and Classify Your Domain Portfolio

• List all domains you own, where they are registered and what each one powers (primary site, email, landing pages, internal tools).
• Identify mission-critical domains and consider consolidating them at a single, policy-aware provider like dchost.com.
• Classify domains into tiers (critical, important, expendable) and align renewal and monitoring policies accordingly.

3. Strengthen Security Around Domains and DNS

• Enable registrar lock and DNSSEC where supported, especially for high-value domains.
• Audit DNS records regularly to ensure they point to current, secure hosting and email infrastructure.
• Review SSL/TLS, WAF and server hardening on any hosting that sits behind key domains.

4. Prepare for Faster, More Secure Transfers

• Familiarise yourself with TAC-based transfers and new timelines.
• Plan any bulk consolidation transfers well ahead of peak seasons or major releases.
• Keep internal records of who approves transfers and how those approvals are archived.

5. Revisit Brand and TLD Strategy

• Monitor the progress of ICANN’s next gTLD round and consider whether niche or branded TLDs might support your long-term plans.
• Update your defensive registration strategy to cover key new TLDs and obvious typosquats.
• Align TLD choices with international SEO and hreflang strategies where relevant.

Conclusion: Turning ICANN Policy Changes Into an Advantage

ICANN’s new domain policies might look like distant, bureaucratic changes at first glance, but they are steadily reshaping everyday operations: how quickly you can move domains, how safely they are protected against hijack attempts, how private your registration data remains and how seriously abuse signals are treated. The organisations that adapt early — by cleaning up their contact data, centralising domain management, tightening security and planning transfers and renewals deliberately — will turn this wave of change into an advantage rather than a source of friction.

At dchost.com, we follow every ICANN development because it directly affects the reliability of your domains, DNS and hosting stack. Our job is to absorb the complexity, update our systems and processes and then translate everything into clear, practical guidance you can apply without reading policy documents. If you’d like a review of your current domain portfolio, or you’re planning a consolidation or migration to new hosting, our team can help you design a plan that respects ICANN’s latest rules while keeping your business online, secure and ready for what comes next.