What Is an Associated Domain Check? What Must Registrars Do After a Phishing Complaint?

This matters because phishing campaigns often use more than one domain.

If an account contains 300 domains and one is confirmed as part of a phishing campaign, investigating only that one domain may leave related malicious infrastructure untouched.

But there is an equally important safeguard:

Being associated with an abusive domain does not automatically make another domain abusive.

ICANN is currently seeking public comment on this issue through its DNS Abuse Mitigation Policy Development Process 1. The Initial Report contains eight preliminary recommendations and five implementation guidances. Public Comment remains open until September 28, 2026. (icann.org)

For domain owners, abuse reporters and resellers, it is also important to separate two different questions:

What must registrars already do after receiving a phishing complaint?

and

What new obligations could Associated Domain Checks add in the future?

They are not the same thing.

NiceNIC publishes its current abuse-handling process through the NiceNIC Domain Abuse Handling & Transparency page and its formal Abuse Reporting & Handling Policy.

What Is an Associated Domain Check?

An Associated Domain Check, often shortened to ADC, is intended to move DNS Abuse investigations beyond a purely domain-by-domain approach.

Today, imagine that a registrar confirms that example1.com was maliciously registered and is being used for phishing.

The same customer account might also contain:

example2.com example3.com example4.com

Those domains might be unrelated and legitimate.

Or they might form part of the same phishing campaign.

The policy question ICANN is currently considering is whether the registrar should be required to investigate those associated domains rather than waiting for someone to report each one separately.

ICANN describes the purpose of the PDP as creating an obligation for registrars to investigate domains associated with a customer account or registrant when at least one domain is found to be engaged in DNS Abuse. (icann.org)

The original PDP charter identified the current gap clearly: registrars already have obligations to evaluate reported domains, but there is not currently a general contractual requirement to investigate all other active domains associated with the same account after one malicious domain is identified. (gnso.icann.org)

Is an Associated Domain Check Already Required by ICANN?

No, not as a new ICANN Consensus Policy requirement today.

This distinction is important.

Associated Domain Checks are currently part of the DNS Abuse Mitigation PDP 1 Initial Report.

The process is currently:

Initial Report → Public Comment → Review of Public Comments → Further Working Group Work → Potential Final Recommendations

The current Public Comment period closes on:

September 28, 2026 at 23:59 UTC

So it would be inaccurate to say:

“ICANN now requires registrars to check every domain in an account after one phishing report.”

That is not the current rule.

What ICANN is considering is a future obligation requiring registrars to investigate associated domains after the relevant policy trigger has been met. (icann.org)

What Must a Registrar Do After Receiving a Phishing Complaint?

ICANN-accredited registrars already have enforceable obligations under Section 3.18 of the Registrar Accreditation Agreement.

Phishing is explicitly included in ICANN's definition of DNS Abuse. (itp.cdn.icann.org)

After receiving an abuse report involving a sponsored domain, a registrar must generally do four things.

1. Must the Registrar Provide a Way to Report Phishing?

Yes.

An ICANN-accredited registrar must maintain an abuse contact and make an email address or web form for abuse reports readily accessible.

NiceNIC provides a dedicated Report Domain Abuse page for reports involving phishing, malware and other relevant abuse.

2. Must the Registrar Confirm That It Received the Complaint?

Yes.

Under RAA Section 3.18.1, the registrar must provide confirmation that the abuse report was received. (itp.cdn.icann.org)

ICANN’s DNS Abuse Compliance Advisory explains that, at minimum, the confirmation should identify:

• the registrar;
• the reported domain name or names;
• the date the report was submitted. (icann.org)

3. Must the Registrar Investigate the Phishing Complaint?

Yes.

Receiving a complaint does not automatically prove that abuse occurred.

But a registrar cannot simply ignore the report.

RAA Section 3.18.1 requires registrars to take reasonable and prompt steps to investigate and respond appropriately to reports of abuse. (itp.cdn.icann.org)

The investigation may consider the evidence provided by the reporter as well as information reasonably available to the registrar.

4. What Must the Registrar Do If the Phishing Evidence Is Confirmed?

When a registrar has actionable evidence that a domain is being used for DNS Abuse, RAA Section 3.18.2 requires the registrar to promptly take appropriate mitigation actions reasonably necessary to stop or otherwise disrupt the abuse. (itp.cdn.icann.org)

The appropriate response depends on the circumstances.

It is not necessarily the same action for every phishing case.

Does a Phishing Complaint Automatically Mean the Domain Will Be Suspended?

No. A phishing complaint by itself does not automatically require domain suspension.

The registrar first needs to assess the report and available evidence.

There is an important difference between:

an allegation of phishing

and

actionable evidence that the domain is being used for phishing.

Once actionable evidence exists, the registrar must act promptly and appropriately.

But even then, suspension is not automatically the only possible response.

ICANN specifically requires registrars to consider factors including:

• the cause of the abuse;
• severity of harm;
• whether users face imminent risk;
• possible collateral damage;
• whether the domain itself was maliciously registered;
• whether an otherwise legitimate domain was compromised. (icann.org)

In one ICANN compliance example, a newly registered domain impersonating a bank was confirmed to be phishing. Applying clientHold to suspend the domain was considered an appropriate mitigation action.

In another example, phishing appeared on a subdomain of an established legitimate business domain. Suspending the entire domain would also have disrupted legitimate websites and business email, so remediation with the legitimate registrant was considered more proportionate. (icann.org)

The practical rule is:

Complaint does not equal automatic suspension.

But:

Confirmed actionable DNS Abuse does require appropriate mitigation.

What Counts as Actionable Evidence of Phishing?

ICANN describes evidence as actionable when the information reasonably available to the registrar is sufficient to make a reasonable determination that the domain is being used for DNS Abuse. (icann.org)

For a phishing report, useful evidence may include:

• the abusive domain name;
• the complete phishing URL;
• screenshots of the phishing page;
• the legitimate company or service being impersonated;
• the phishing email or SMS where relevant;
• full email headers where relevant;
• timestamps;
• information showing how the malicious content can be reproduced;
• other technical or contextual evidence supporting the allegation.

For example, saying:

“example.com is phishing”

provides very little information.

Providing:

the full URL + screenshot + target brand + phishing message + timestamp

gives the registrar substantially more information to investigate.

NiceNIC publishes the evidence commonly useful for different abuse categories on its Domain Abuse Reporting page.

How Quickly Must a Registrar Respond to a Phishing Complaint?

There is not a universal ICANN rule saying every ordinary phishing complaint must be fully resolved within 24 hours.

This is a common misunderstanding.

For general abuse reports, RAA Section 3.18.1 requires:

reasonable and prompt investigation and response.

When actionable evidence of DNS Abuse exists, Section 3.18.2 requires:

prompt appropriate mitigation. (itp.cdn.icann.org)

The exact time can depend on the circumstances.

A clear phishing campaign creating imminent harm may justify faster intervention than a technically complex case involving a compromised legitimate domain.

ICANN's own compliance examples describe different investigation and mitigation periods depending on the facts of the case. (icann.org)

The separate 24-hour requirement applies to well-founded reports of Illegal Activity sent through a registrar's dedicated channel for law enforcement, consumer protection agencies and certain government authorities. (itp.cdn.icann.org)

That should not be confused with a universal 24-hour deadline for every ordinary abuse complaint.

What Is the Difference Between Checking a Related Domain and Suspending It?

This distinction is central to the current Associated Domain Check debate.

Checking a domain does not mean suspending it.

An investigation may look for indicators that multiple domains are connected to the same malicious activity.

But association alone should not automatically be treated as proof of abuse.

For example, two domains might share:

• a customer account;
• registrant information;
• infrastructure;
• nameservers;
• payment information;
• other account-level signals.

Some of those relationships may be meaningful.

Others may have innocent explanations.

Public comments submitted to ICANN have already raised concerns about over-association and false positives, noting that shared registration information or other indicators do not necessarily establish common control or malicious activity. (icann.org)

A useful distinction is therefore:

Association can justify investigation.

It should not automatically equal:

Association proves abuse.

If One Domain Is Used for Phishing, Will the Registrar Check My Other Domains?

Under today’s general ICANN contractual framework, not necessarily.

A registrar may already choose to investigate related domains when available information suggests a wider campaign.

However, there is not currently a general contractual requirement requiring every registrar to perform an account-wide Associated Domain Check whenever one domain is confirmed as malicious.

That is exactly the gap DNS Abuse Mitigation PDP 1 is examining. (gnso.icann.org)

If the proposed policy ultimately becomes a Consensus Policy, registrars could have a more explicit obligation to investigate associated domains when the required trigger is met.

The details still matter.

Questions under consideration include:

• what triggers an Associated Domain Check;
• what makes domains sufficiently associated;
• what information registrars may use;
• how investigations should be performed;
• what safeguards are needed;
• how privacy should be protected;
• how false positives should be avoided;
• when action against another domain is justified.

What If the Reported Domain Was Hacked Rather Than Registered for Phishing?

This is one of the most important distinctions in DNS Abuse handling.

A legitimate business domain can be compromised without the domain owner knowingly participating in phishing.

For example:

A business may operate:

company.com

An attacker compromises the website and creates:

company.com/login-update

or a malicious subdomain.

The phishing is real.

But suspending company.com could also take down:

• the company's legitimate website;
• corporate email;
• customer services;
• unrelated subdomains.

ICANN’s compliance guidance explicitly recognizes this collateral-damage problem.

In a compromised-domain case, appropriate mitigation may include notifying the registrant or hosting provider and requiring removal of the phishing content rather than immediately suspending the entire domain. (icann.org)

That is why a good abuse process needs both:

effective mitigation

and

proportionate action.

NiceNIC explains its case-status and evidence-review process on the Domain Abuse Handling & Transparency page.

How Do I Report a Phishing Domain to a Registrar?

A useful phishing report should help the registrar reproduce and verify the problem.

Before submitting the report, collect:

1. The domain name

Identify the domain involved.

2. The exact phishing URL

Do not provide only the homepage if the phishing content appears on a specific path or subdomain.

3. A screenshot

Capture the page showing the impersonation or credential request.

4. The legitimate target

Identify the bank, exchange, company, government service or other organization being impersonated.

5. The phishing message

If the URL arrived by email, SMS or another channel, include the relevant message and headers where available.

6. Time and technical details

Timestamps, browser information, location information and other details may help if the malicious page uses cloaking or geo-targeting.

If the domain is sponsored by NiceNIC, use the official NiceNIC Report Domain Abuse form.

NiceNIC's formal handling principles and reporting procedures are published in the Abuse Reporting & Handling Policy.

What Can I Do If a Registrar Does Not Act on a Phishing Report?

First, make sure the report contains enough specific evidence for the registrar to investigate.

If information is missing, provide it through the same abuse case rather than repeatedly opening duplicate complaints.

For a gTLD domain, if a reasonable period has passed and you believe the sponsoring registrar has not met its obligations under RAA Section 3.18, ICANN provides a Contractual Compliance complaint process. ICANN states that reporters may escalate a matter after submitting an abuse complaint to the registrar and allowing a reasonable time for handling. (icann.org)

ICANN Contractual Compliance may then evaluate:

• the evidence supplied by the reporter;
• information available to the registrar;
• the registrar's investigation;
• whether actionable evidence existed;
• what mitigation was taken;
• when action was taken;
• why the chosen action was considered appropriate and proportionate. (icann.org)

Does an Associated Domain Check Mean Every Domain in an Account Could Be Suspended?

No.

That would be an overly broad interpretation of the current proposal.

The policy discussion is about investigating associated domains after actionable evidence exists on a triggering domain.

It does not mean:

one abusive domain = automatic suspension of the entire account.

The current policy work is specifically considering proportionality, privacy, evidence and potential collateral damage. (icann.org)

The distinction matters especially for:

• domain investors with large portfolios;
• hosting providers;
• resellers;
• agencies managing customer domains;
• businesses with many defensive registrations;
• accounts containing both active and parked domains.

Does the Associated Domain Check Proposal Apply to ccTLDs?

The current DNS Abuse Mitigation PDP 1 is being developed through ICANN’s GNSO and concerns obligations for ICANN-accredited registrars under the Registrar Accreditation Agreement.

It should therefore not be interpreted as automatically creating the same rules for every country-code TLD.

ccTLDs such as .uk, .de, .ca or .in may operate under their own registry policies, national requirements and registrar arrangements.

Always check the rules applicable to the specific TLD.

What Should Domain Owners and Resellers Know About Associated Domain Checks?

The most important points are simple:

• Associated Domain Checks are currently proposed, not yet a new final Consensus Policy requirement.
• ICANN's Public Comment period currently runs through September 28, 2026.
• Registrars already have enforceable obligations to receive, investigate and respond to abuse reports.
• Phishing is explicitly defined as DNS Abuse under the RAA.
• A complaint alone does not automatically require suspension.
• Actionable evidence does require prompt and appropriate mitigation.
• A compromised legitimate domain may require a different response from a maliciously registered phishing domain.
• Checking an associated domain is not the same as determining that it is abusive.
• The proposed policy is intended to help identify larger malicious campaigns without treating association alone as proof of abuse.

For NiceNIC customers and resellers, current case status, domain impact, review progress and available next steps can be reviewed through the NiceNIC Domain Abuse Handling & Transparency page.

For anyone evaluating NiceNIC's broader accreditation, security, compliance and public-policy resources, visit the NiceNIC Trust Center.

What Is the Bottom Line on Associated Domain Checks and Phishing Complaints?

Today, ICANN-accredited registrars already have clear responsibilities when they receive credible phishing reports:

Receive the report → confirm receipt → investigate reasonably and promptly → determine whether actionable evidence exists → take appropriate mitigation when required → document the handling of the case.

What may change is what happens next.

ICANN is now considering whether confirmation of DNS Abuse on one domain should trigger a required investigation into other domains associated with the same customer account or registrant.

That could help registrars disrupt coordinated phishing campaigns earlier.

But the safeguards matter just as much.

One domain can justify looking closer. It should not automatically make every related domain guilty.

The outcome of ICANN’s current policy process will determine how that balance is ultimately defined.