There has been an idea floating around the ICANN space for a little while now: in an effort to reduce DNS Abuse, we should shorten the period of time registrants have to verify their domains, or have domains remain inactive until verification is complete. But would this change really have a positive effect that’s worth the investment? Let’s take a look.

Background

We’ll start with a brief refresher on some core concepts.

DNS Abuse

The Registrar Accreditation Agreement (RAA), which governs how ICANN-accredited registrars must operate, defines DNS Abuse as malware, botnets, phishing, pharming, and spam (when spam serves as a delivery mechanism for the other forms of DNS Abuse). We support this definition and advocated for its inclusion in the RAA during the most recent round of contract negotiations.

Registration data verification

The requirements for verifying registration data for gTLDs are also laid out in the RAA.

Verification refers to the accuracy and functionality of the data—the domain owner confirms that the data they provided is correct and demonstrates that they can be reached at either the phone number or email address provided by responding to a message sent there.

When a domain is registered or transferred, or its registration data is updated, the registrant needs to verify the registration data within 15 days; if it’s not verified, the domain will be suspended, so no related services (such as a website or email) work until the verification is complete. Once verified, the same data set can be used for other domains at the same registrar without needing to be re-verified.

The proposed change

With that context in mind, we can consider the proposed change. There are two options being contemplated. Instead of immediately activating the domain and giving registrants 15 days to complete verification—as we do today—the proposal is that we should either:

• Activate the domain immediately but require registrants to complete verification in a much shorter timeframe, or;

• Only activate domains once verification is complete.

The assumption here is that anyone using a domain for DNS Abuse would not have access to the email or phone number provided for the registration—so they wouldn’t be able to verify it—or wouldn’t take the time to do so. At first glance, that can feel intuitive. But is it really the case?

What does the data show?

When domains get verified

We pulled a report for all gTLD domains registered under one of our wholesale brands during March 2026 to see when verification was completed (note that we excluded domains using already-verified data sets). We found:

• Nearly half (48%) were verified on the same day they were registered.

• About 25% were verified over the following 14 days, with spikes on days 1, 5, and 10, corresponding with the reminder emails that we send out.

• About 25% were suspended on day 15 for failing to complete verification in time.

This shows that about a quarter of domains never get verified—or get verified some time after the 15-day window closes—which seems high and could be used to support the argument that these are Abusive domains that should never be activated. It also, however, shows that the same number of legitimate domains—25%—are in use between registration and the time that they get verified. Is it worth penalizing these users because they might become a source of DNS Abuse?

When DNS Abuse occurs

We then pulled a sample of recently-registered domains already found to have been used for DNS Abuse and reviewed each of those to see when it was verified. We found:

• 82% of Abusive domains used registration data that was already verified on a prior domain (and therefore did not require re-verification now).

• 14% of Abusive domains used new registration data and completed the verification right after registration, or were otherwise not eligible for ICANN verification.

• 2% of Abusive domains were suspended due to incomplete verification.

• 2% of Abusive domains were flagged at the time of registration by our payment fraud team.

Reducing the verification timeline would catch a tiny amount of DNS Abuse—based on the sample set, it would catch about 2%. If we were seeing significant rates of DNS Abuse conducted using unverified domains (before they’re suspended), the proposed change might be more compelling. But as we’ve learned over our many years of experience, and as seen in this review, the data do not show that there is a strong case for this change or that it would have a significant or positive effect.

What about the user experience?

What this change would affect, however, is the experience of legitimate registrants, people who just want to get their new project up and running—they’d have to wait to go live, or act very quickly if they want to stay live. Further, the operationalization—how this would work in real life—is also unclear.

While legitimate users who already verify right away won’t be affected by a shorter verification window, all other legitimate users will. Imagine going to the effort of buying a domain, launching the website, and setting up email addresses, only to find it all shut down a few days later because a verification email got lost in the noise of launch day. This is a significant disruption that isn’t justified by the data: very little DNS Abuse—only about 2%—would be caught in this dragnet.

Similarly, if verification were required before even activating a domain, it would mean that all use of the domain—including the website, email, and other services—would be delayed pending that verification. This poses complexities not only for new registrations but also for registration data updates and registrar transfers, where such a requirement is all the more disruptive: would any update result in immediate suspension of all services? This would cause confusion and be prone to error, leading to unhappy customers, increased support requests, and ultimately a less stable DNS.And, again, there’s very little corresponding upside, hardly any reduction in DNS Abuse to make the disruption worthwhile.

What would the Policy work look like?

Policy development work at ICANN requires dedication and expertise from both volunteers and ICANN Staff members, and typically takes years to go from an idea to reality. This is both a feature and a bug—it’s important that decisions affecting how the Internet operates are fully considered and reach consensus within the ICANN Community, but it also means we need to carefully prioritize what work we dedicate our efforts to.

With regards to fighting DNS Abuse, we should focus on policy work that we know will have a significant impact, which simply is not the case with this proposed change. The team dedicated to considering new DNS Abuse mitigation methods considered 31 potential areas of work and prioritized three (associated domain checks, coordination on domain-generating algorithms, and safeguarding APIs). Beyond those, there remain many potential avenues for combatting DNS Abuse which would be much more effective and efficient than adjusting the timeline for registration data verification.

What’s next?

The verification process, as it stands now, works well. It confirms that domain owners provide complete and accurate data, as they are required to do, and that they can be reached at the contact info they provide. Further, the data does not show a strong relationship between when domain verification occurs and whether a domain is used for DNS Abuse—and a 2% reduction in DNS Abuse would hardly balance out the disruption this change would cause and the hours of work that would go into its implementation. 

We should focus our attention on addressing DNS Abuse in effective, efficient, and data-driven ways, including through the current Policy Development Process underway to formalize the Associated Domain Checks process that we already conduct here at Tucows.

Let’s focus on solutions that really make the Internet better.