tld.report · The 2026 Round

Snapshot of 8 October 2026 · ICANN APS, public fields

Applications / .reply / REPLY2656T-T48846 · published by ICANN 7 October 2026 · snapshot 2026-10-08

.reply

Brand TLD · Spec 13Active

Reply S.p.A., IT Q1·Q25

Ultimately controlled by Mario Rizzante Q108 · ICANN record ↗

§ 1 — Meaning of the string Q118·Q120

According to the Oxford English dictionary “reply” means “to say, write, or do something as an answer to someone or something”. Reply S.p.A., has been using this term as both its corporate name and its registered trademark since 1996.

/rɪˈplaɪ/

§ 2 — Mission and purpose Q133

Reply S.p.A. (hereinafter "Reply") is applying for the .reply Top Level Domain as a Brand TLD for the exclusive institutional use of Reply and its affiliated entities, in compliance with all requirements of Specification 13 of the Registry Agreement.

About Reply Reply is a multinational IT group specialising in digital transformation, artificial intelligence, cloud computing, cybersecurity and Internet of Things. Founded in 1996 in Turin, Italy, Reply operates as a network of more than 150 specialised companies across 16 countries, with 16,624 employees and consolidated revenue of €2.48 billion (2025). Listed on Borsa Italiana (BIT: REY), Reply serves clients across manufacturing, financial services, retail, telecommunications, energy, healthcare and the public sector. Reply has maintained continuous and exclusive use of its trademarks since 1996, building a globally recognised brand associated with IT consulting, digital transformation and technology innovation.

About the .reply TLD The mission of .reply is to consolidate Reply's digital identity under a single, secure and exclusively controlled name space, serving as the authoritative online identifier for all products, services and communications of Reply and its affiliates. The only registrants will be Reply S.p.A. and its affiliated entities; no third-party registrations are contemplated. The goals of .reply are to: strengthen the institutional brand in the digital environment; enable the highest security standards in TLD management — including domain lifecycle controls, DNSSEC and real-time abuse monitoring; improve the security of online transactions and client communications; reduce the risks of phishing and identity fraud; unify the group's digital presence under a single coherent namespace; and create new opportunities for digital marketing and client engagement across all business lines and channels.

Commitment to ICANN's principles As a publicly listed group subject to Italian securities regulation, Reply brings to .reply the highest standards of institutional governance, regulatory compliance and risk management. The .reply namespace will at all times serve the public interest by ensuring exclusively legitimate, transparent and accountable use. Reply is committed to full compliance with all applicable Registry Agreements, consensus policies and ICANN bylaws; active engagement with ICANN's multi-stakeholder processes; and robust technical, security and abuse-prevention measures. As a Brand TLD operated exclusively by Reply and its affiliates, .reply poses no risk of consumer confusion, intellectual property abuse or registration conflicts, minimising any adverse impact on the public interest.

Commitment to the operation of the TLD The sustainability of .reply is grounded in Reply's institutional strength and long-term strategic commitment. With the financial capacity, technical expertise and governance structures required to operate internet infrastructure responsibly, Reply is fully committed to fulfilling its obligations as a registry operator. Reply's trajectory, innovation culture and governance model provide full assurance that .reply will be operated consistently with the public interest and in strict accordance with ICANN's policies and requirements.

§ 3 — Commitments and safeguards Q164–Q188

More trustworthy, consumer risk, regulated sector, government reporting, harm, government function Q164–Q169No to each
Voluntary Safeguard PICs Q170·Q171None · 90 applications in the round offer some
Registry Voluntary Commitments Q172·Q173None · 5 do
Brand TLD criteria confirmed, trademark certificate attached Q180·Q181Yes · certificate not published
Confirms the string is not a “generic string” Q183Yes
Spec 11 §3(d) statement Q184

The Applicant confirms that the operation of the .REPLY TLD will not give rise to any conflict with Section 3(d) of Specification 11 of the Registry Agreement.

First, the applied-for string “.REPLY” does not constitute a “Generic String” within the meaning of Specification 11, Section 3(d). While the term “reply” may have a dictionary meaning (please see the answer to the Question 118), in the context of the Applicant’s intended use it functions as a distinctive identifier associated with the Applicant’s brand and services (IT Services), rather than as a term that denotes or describes a general class of goods, services, groups, organizations, or things.

Second, the Applicant intends to operate the .REPLY TLD pursuant to Specification 13 (Brand TLD). As such, the TLD will be used exclusively by the Registry Operator and its Affiliates (and eventually also trademark licensees), and will not be open for general public registration. The eligibility criteria applied within the TLD will therefore be consistent with Specification 13, which expressly permits exclusive registration models for qualifying .Brand TLDs. Consequently, the limitation of registrations to the Registry Operator and its Affiliates is strictly compliant with the applicable ICANN framework and may not contravene Section 3(d) of Specification 11 of the Registry Agreement.

This is supported by the existence of registered trademark rights in the term “REPLY” held by the Applicant (or its Affiliates) in multiple jurisdictions, including Italy (Registration No. 0001008543, classes 9, 16, 35, 38, 41, 42), the European Union (EUIPO Registration Nos. 000365908 and 002729283, classes 9, 16, 35, 38, 41, 42), international registrations via WIPO (Registration Nos. 1086268 and 1398219, classes 9, 16, 35, 36, 38, 41, 42), Switzerland (Registration No. 445466, classes 9, 35, 41, 42), Brazil (Registration Nos. 830692959, 830692967, 830696725, 913480100, 913480185, 913480266, 913480304, 913480363, 913480398, 913480444, covering classes 9, 16, 35, 36, 38, 41, 42), and the United Kingdom (Registration Nos. UK00801398219, UK00900365908 and UK00902729283, covering classes 9, 16, 35, 36, 38, 41, 42). (See https://www.tmdn.org/tmview/welcome.html?lang=es#/tmview/results?page=1&pageSize=30&criteria=I&basicSearch=REPLY&sortColumn=applicantName&desc=false&fAName=REPLY%20S.P.A.&fTMStatus=Registered ) These registrations demonstrate that “REPLY” functions as a distinctive sign identifying the commercial origin of specific goods and services across numerous territories, and not as a term that denotes or describes a general class of goods, services, organizations, or things.

In light of the above, the .REPLY string should not be classified as a “Generic String” for the purposes of Specification 11. Accordingly, the Applicant’s intended exclusive-use model under Specification 13 does not create any inconsistency with Section 3(d).

§ 4 — All other published answers

Every other answer ICANN published for this application, in the order of the form. Contact details (Q17–Q24) are left to the ICANN record.

Q206Q3.2-1 - Provide the applying entity’s self-certification document, signed by the CEO, President, CFO and/or equivalent officer of the applying entity. If the applying entity’s financial statements are provided by a Qualified Parent Entity (QPE), the CEO, President, CFO, and/or equivalent officer of the QPE must co-sign the certification document. The self-certification document must represent and warrant: SC3.2-1.1 - As of the submission date of the application, the applying entity is currently a listed member in one or more of the public stock exchanges identified on ICANN’s list from Market Statistics (https://focus.world-exchanges.org/issue/december-2025/market-statistics, as of December 2025), including information on both the relevant exchange and the current registration ticker symbol. SC3.2-1.2 - The applying entity is in good standing with the public stock exchange in which it is a listed member. SC3.2-1.3 - The applying entity commits to the long-term funding of all applied-for gTLD strings. SC3.2-1.4 - The applying entity and/or its officers are bound by law in its jurisdiction to represent financial statements accurately and the applying entity is in good standing in that jurisdiction.

Q3.2-1 - Provide the applying entity’s self-certification document, signed by the CEO, President, CFO and/or equivalent officer of the applying entity. If the applying entity’s financial statements are provided by a Qualified Parent Entity (QPE), the CEO, President, CFO, and/or equivalent officer of the QPE must co-sign the certification document. The self-certification document must represent and warrant: SC3.2-1.1 - As of the submission date of the application, the applying entity is currently a listed member in one or more of the public stock exchanges identified on ICANN’s list from Market Statistics (https://focus.world-exchanges.org/issue/december-2025/market-statistics, as of December 2025), including information on both the relevant exchange and the current registration ticker symbol. SC3.2-1.2 - The applying entity is in good standing with the public stock exchange in which it is a listed member. SC3.2-1.3 - The applying entity commits to the long-term funding of all applied-for gTLD strings. SC3.2-1.4 - The applying entity and/or its officers are bound by law in its jurisdiction to represent financial statements accurately and the applying entity is in good standing in that jurisdiction.

Answered with a document. Attachments are not published by ICANN.

Q220Q5.1-1 - Provide the applying entity’s self-certification document, signed by the CEO, President, CFO and/or equivalent officer of the applying entity. The self-certification document must represent and warrant: SC5.1-1.1 - The applying entity will appropriately protect confidentiality of data and prevent unauthorized access to data and services. SC5.1-1.2 - The applying entity will maintain a mature, appropriately funded and staffed security program, following a recognized, modern security framework based on risk management (such as the ISO27000 series, COBIT, HITRUST CSF, legally required security frameworks, or equivalent). The security program must be in place prior to delegation, and exist through at least the period of the registry agreement. SC5.1-1.3 - The applying entity is aware of and has designed its systems and business to comply with the relevant privacy and security regulations for all countries in which it operates.

Q5.1-1 - Provide the applying entity’s self-certification document, signed by the CEO, President, CFO and/or equivalent officer of the applying entity. The self-certification document must represent and warrant: SC5.1-1.1 - The applying entity will appropriately protect confidentiality of data and prevent unauthorized access to data and services. SC5.1-1.2 - The applying entity will maintain a mature, appropriately funded and staffed security program, following a recognized, modern security framework based on risk management (such as the ISO27000 series, COBIT, HITRUST CSF, legally required security frameworks, or equivalent). The security program must be in place prior to delegation, and exist through at least the period of the registry agreement. SC5.1-1.3 - The applying entity is aware of and has designed its systems and business to comply with the relevant privacy and security regulations for all countries in which it operates.

Answered with a document. Attachments are not published by ICANN.

Q221Q5.2-1 - Provide the applying entity’s self-certification document, signed by the CEO, President, CFO and/or equivalent officer of the applying entity. The self-certification document must represent and warrant: SC5.2-1.1 - The applying entity will, no later than delegation of the Top Level Domain (TLD), establish a dedicated abuse point of contact responsible for addressing matters requiring expedited attention and providing a timely response to abuse complaints concerning any name registered in the TLD. SC5.2-1.2 - The applying entity will, no later than delegation of the TLD, establish, publish, and provide to ICANN the location of a mechanism for members of the public to submit reports of abuse in accordance with the current obligations of the Base RA and any Consensus Policies. SC5.2-1.3 - The applying entity has developed proposed measures for removal of orphan glue records for names removed from the zone when provided with evidence in written form that the glue is present in connection with malicious conduct (see Specification 6). SC5.2-1.4 - The applying entity has or will have at time of delegation, established policies for handling complaints regarding abuse. Such policies are to be maintained and posted publicly so that anyone can review the policies via the Internet and any other means deemed appropriate by the applying entity. The applying entity’s policies at a minimum should contain appropriate confirmation of the receipt of the abuse report, the process of review of the report, and actions that will be taken if the applying entity confirms the report is legitimate. SC5.2-1.5 - The applying entity understands that DNS Abuse is Phishing, Malware, Botnets, Pharming and Spam (when used to deliver other forms of DNS Abuse). The applying entity understands and is prepared to contribute to the mitigation or disruption of DNS Abuse in domains in the TLD zone. SC5.2-1.6 - The applying entity’s abuse response capabilities are resourced appropriately to ensure a timely and adequate investigation and response to reports of DNS Abuse. This includes capabilities to receive and evaluate evidence of DNS Abuse in reports, and to take action to stop or disrupt the DNS Abuse. SC5.2-1.7 - The applying entity is prepared to conduct periodic scans of its zone to identify if domains are being used to perpetrate DNS Abuse, and to maintain statistical reports of the scans, the findings, and actions taken.

Q5.2-1 - Provide the applying entity’s self-certification document, signed by the CEO, President, CFO and/or equivalent officer of the applying entity. The self-certification document must represent and warrant: SC5.2-1.1 - The applying entity will, no later than delegation of the Top Level Domain (TLD), establish a dedicated abuse point of contact responsible for addressing matters requiring expedited attention and providing a timely response to abuse complaints concerning any name registered in the TLD. SC5.2-1.2 - The applying entity will, no later than delegation of the TLD, establish, publish, and provide to ICANN the location of a mechanism for members of the public to submit reports of abuse in accordance with the current obligations of the Base RA and any Consensus Policies. SC5.2-1.3 - The applying entity has developed proposed measures for removal of orphan glue records for names removed from the zone when provided with evidence in written form that the glue is present in connection with malicious conduct (see Specification 6). SC5.2-1.4 - The applying entity has or will have at time of delegation, established policies for handling complaints regarding abuse. Such policies are to be maintained and posted publicly so that anyone can review the policies via the Internet and any other means deemed appropriate by the applying entity. The applying entity’s policies at a minimum should contain appropriate confirmation of the receipt of the abuse report, the process of review of the report, and actions that will be taken if the applying entity confirms the report is legitimate. SC5.2-1.5 - The applying entity understands that DNS Abuse is Phishing, Malware, Botnets, Pharming and Spam (when used to deliver other forms of DNS Abuse). The applying entity understands and is prepared to contribute to the mitigation or disruption of DNS Abuse in domains in the TLD zone. SC5.2-1.6 - The applying entity’s abuse response capabilities are resourced appropriately to ensure a timely and adequate investigation and response to reports of DNS Abuse. This includes capabilities to receive and evaluate evidence of DNS Abuse in reports, and to take action to stop or disrupt the DNS Abuse. SC5.2-1.7 - The applying entity is prepared to conduct periodic scans of its zone to identify if domains are being used to perpetrate DNS Abuse, and to maintain statistical reports of the scans, the findings, and actions taken.

Answered with a document. Attachments are not published by ICANN.

Q119Script of String

Script of String

Latin

Q121As per Section 3(d) of Specification 11 of the Base Registry Agreement, a registry operator of a “generic string” may not impose eligibility criteria for registering names in the TLD that limit registrations exclusively to a single person or entity and/or that person’s or entity’s “Affiliates” (as defined in Section 2.9(c) of the Registry Agreement). “Generic String” means a string consisting of a word or term that denominates or describes a general class of goods, services, groups, organizations or things, as opposed to distinguishing a specific brand of goods, services, groups, organizations or things from those of others. Confirm that the applied-for string is not a “generic string” in which the applying entity intends to limit registrations exclusively to a single person or entity.

As per Section 3(d) of Specification 11 of the Base Registry Agreement, a registry operator of a “generic string” may not impose eligibility criteria for registering names in the TLD that limit registrations exclusively to a single person or entity and/or that person’s or entity’s “Affiliates” (as defined in Section 2.9(c) of the Registry Agreement). “Generic String” means a string consisting of a word or term that denominates or describes a general class of goods, services, groups, organizations or things, as opposed to distinguishing a specific brand of goods, services, groups, organizations or things from those of others. Confirm that the applied-for string is not a “generic string” in which the applying entity intends to limit registrations exclusively to a single person or entity.

true

Q223By submitting this Application, the applying entity confirms that it is submitting this Application with a good faith (“bona fide”) intent to operate the gTLD for which it has applied, and that the applying entity has read and understands the provisions of Section 5.2.3.1 Prohibited Communications and Activities of the Applicant Guidebook regarding the New gTLD Program rules prohibiting certain communications and activities to prevent parties from privately resolving string contention among themselves.

By submitting this Application, the applying entity confirms that it is submitting this Application with a good faith (“bona fide”) intent to operate the gTLD for which it has applied, and that the applying entity has read and understands the provisions of Section 5.2.3.1 Prohibited Communications and Activities of the Applicant Guidebook regarding the New gTLD Program rules prohibiting certain communications and activities to prevent parties from privately resolving string contention among themselves.

true

Q224By submitting this Application, the applying entity confirms that it has read and understands the provisions of Section 5.2.3.1 Prohibited Communications and Activities of the Applicant Guidebook regarding the New gTLD Program rules prohibiting certain communications and activities to prevent parties from privately resolving string contention among themselves.

By submitting this Application, the applying entity confirms that it has read and understands the provisions of Section 5.2.3.1 Prohibited Communications and Activities of the Applicant Guidebook regarding the New gTLD Program rules prohibiting certain communications and activities to prevent parties from privately resolving string contention among themselves.

true