NIS2 Compliance Hub

Stay compliant. Protect domains. Reduce risk.


CentralNic Reseller give you what you need to provide accurate contact data to meet regulations.

Get Started with NIS2

NIS2 Compliance Hub

Stay compliant. Protect domains. Reduce risk.


  • ✓ EU Regulatory Alignment

  • ✓ Registry-Level Compliance Support

  • ✓ Operational Readiness Toolkit

View NIS2 Features

What is NIS2 and Why Does it Matter?

The Network and Information Security Directive 2 (NIS2 / EU 2022/2555) is the EU’s updated cybersecurity
framework that has been expanded to cover domain registration services. This means clearer data accuracy requirements, faster response times to registry verification requests, and tougher consequences for non-compliance.

NIS2 is EU law; not a platform feature.
All domain data must now be: Accurate, Reachable, Verifiable.

It applies to:

  • Registries

  • Registrars

  • Resellers

  • Domain Registrants

Required Registrant Data (Article 28)

Every domain registration must include:

  • Full Registrant Name
  • Verified Email Address
  • Valid Phone Number (must comply with RFC5733 standards, e.g. +44.2071234567)
  • Full Postal Address
  • Domain Name
  • Registration Date
  • Technical Contact (if applicable)

Important Rules:

  • No PO Boxes
  • No Placeholder Phone Numbers
  • No Abbreviated Names

These requirements apply to new domain registrations and existing contacts when they are updated or are flagged by a registry for risk assessment.

Shared Responsibilities

Registries

(e.g. DENIC, EURid, AFNIC)

  • Define TLD-level data policies
  • Conduct automated risk assessments
  • Issue verification requests
  • Quarantine or delete non-compliant domains
  • Publish verification policies
Eine Grafik, die den perfekten Service darstellt

CentralNic Reseller

(Registrar Role)

  • Implements baseline Article 28 controls
  • Enforces email verification
  • Validates phone numbers
  • Enables RDRP reminder workflows
  • Provides X-VERIFICATION-* framework
  • Translates registry poll messages into reseller events
  • Cannot contact registrants directly
A graphic depicting reseller

Resellers

  • Own registrant relationship and all communication
  • Collect and verify customer data
  • Maintain operational compliance workflows
  • Submit updates and verification responses
  • Meet registry response deadlines

Platform Features Supporting NIS2

At CentralNic Reseller, we took a phased approach, first deploying to OT&E (Mar 2025) then to the live environment (Nov 2025). The following six capabilities are now active for all clients, helping you meet your verification obligations.

Platform Features Supporting NIS2

At CentralNic Reseller, we took a phased approach, first deploying to OT&E (Mar 2025) then to the live environment (Nov 2025). The following six capabilities are now active for all clients, helping you meet your verification obligations.

1. Email Verification for all TLDs

Email verification, previously limited to ICANN gTLDs, now applies to all TLDs on the CentralNic Reseller platform. A verification email is sent when a new contact email is first used; domains may be suspended if not confirmed.

Status: OTE: Mar 2025 | Live: Nov 2025

  • Triggered by: AddContact / ModifyContact API commands with a new email address
  • Resellers handling their own verification are on a tracked exemption list and must reconfirm capability before renewal
  • If reseller verification fails our checks, the domain is suspended; prior verification evidence may be submitted to request reactivation

2. Phone Number Validation

RFC-format phone validation is now enforced with the API commands: AddContact, ModifyContact, AddCertificate, and AddCertificateContact. Empty values, placeholder numbers like +1 111 111 1111, and numbers that don’t match the country’s dialling format are rejected at the point of submission.

Status: OTE: Mar 2025 | Live: Nov 2025

  • This was the first mandatory Phase I requirement enforced by DENIC (Jan 2026)
  • Existing contacts with invalid phone numbers were notified via the Jan 2026 newsletter
  • Validation runs as soon as information is updated

3. X-VERIFICATION-* Extension

This new data set allows resellers to attach verification evidence to any contact: covering what was verified, by whom, when, how, with what reference, and the outcome. This helps you meet NIS2 verification requests, including responding to verification requests and recording verification evidence for registrant data.

Status: Live: Nov 2025

  • Added to AddContact and ModifyContact as optional parameters
  • Verification is stored at contact handle level; reusable across all TLDs
  • The reference field is there for resellers to use for your own internal record IDs
  • For .PT, telephone verification can be recorded using a complete X-VERIFICATION-* block with X-VERIFICATION-DATA#=phone, X-VERIFICATION-METHOD#=reachability, X-VERIFICATION-EVIDENCE#=phone_ver_transaction_log

Important: X-VERIFICATION-DATA#=phone is only one part of the verification record. A complete verification block also includes the relevant method, evidence, result, timestamp, trust framework, and reference values.

4. RDRP Reminder Workflow

The Registration Data Reminder Process (RDRP) email, previously only active for gTLDs, has been updated to cover all TLDs. This annually notifies registrants to review and confirm their contact data, fulfilling the Article 28 requirement for data accuracy reminders.

5. Contact Type Enforcement

We now support explicit PERSON vs ORGANISATION designation at contact handle level.

  • Set via the X-DE-HOLDER-PERSON flag (legacy) or the new contact type field
  • PERSON contacts must use Type: PERSON. Never map individuals as ORG
  • Mistyped contacts can be flagged by DENIC during Phase II risk assessment

DENIC (.DE) Requirements

DENIC is the registry for .DE, Germany’s ccTLD with approximately 17 million registered domains. Germany transposed NIS2 via the NIS2 Implementation Act (NIS2UmsuCG), passed in November 2025 and effective from 6 December 2025. The requirements are implemented in two phases.

Phase I: 28 January 2026

  • Mandatory phone number: all .DE owner contacts require an RFC standard phone number via the DENIC RRI. No dummy values or empty fields.
  • Web WHOIS publication: DENIC now publishes the registration date and Managing DENIC member details (name, address, email, phone) for all .DE domains. This includes legal entities managing .DE domains.
  • Contact type must be correct: DENIC requires Type: PERSON for natural persons only. Legal entities must use Type: ORG. Mismatches will be flagged.
  • Initial Email Verification: When an email address is submitted for a domain holder that has not previously been verified, they must immediately send a verification request to that address.
  • Annual Registration Data reminder: Members must share registrant data with the domain holder once per year, and request that they check and notify them if anything is incorrect or incomplete.

Phase II: 14 April 2026 (NOW LIVE)

  • Risk assessment on all contact/domain orders: Every incoming contact creation, contact update, and domain registration for .DE goes through DENIC’s automated risk scoring system.
  • Verification requests: When DENIC classifies data as suspicious or high-risk, it sends a verification request to CentralNic Reseller, which is forwarded onto the reseller.
  • Existing contacts: DENIC can issue verification requests on existing contacts at any time, particularly when they are used in new operations.
  • 3-week escalation: If no verification is completed within the first ~3 weeks, DENIC will email the registrant directly.
  • Quarantine and deletion: If verification is not done, the domain enters a quarantine period (~90 days). After quarantine, the domain is deleted. Suspension occurs only in critical cases during the quarantine window.

DENIC (.DE) Requirements

DENIC is the registry for .DE, Germany’s ccTLD with approximately 17 million registered domains. Germany transposed NIS2 via the NIS2 Implementation Act (NIS2UmsuCG), passed in November 2025 and effective from 6 December 2025. The requirements are implemented in two phases.

Phase I: 28 January 2026

  • Mandatory phone number: all .DE owner contacts require an RFC standard phone number via the DENIC RRI. No dummy values or empty fields.
  • Web WHOIS publication: DENIC now publishes the registration date and Managing DENIC member details (name, address, email, phone) for all .DE domains. This includes legal entities managing .DE domains.
  • Contact type must be correct: DENIC requires Type: PERSON for natural persons only. Legal entities must use Type: ORG. Mismatches will be flagged.
  • Initial Email Verification: When an email address is submitted for a domain holder that has not previously been verified, they must immediately send a verification request to that address.
  • Annual Registration Data reminder: Members must share registrant data with the domain holder once per year, and request that they check and notify them if anything is incorrect or incomplete.

Phase II: 14 April 2026 (NOW LIVE)

  • Risk assessment on all contact/domain orders: Every incoming contact creation, contact update, and domain registration for .DE goes through DENIC’s automated risk scoring system.
  • Verification requests: When DENIC classifies data as suspicious or high-risk, it sends a verification request to CentralNic Reseller, which is forwarded onto the reseller.
  • Existing contacts: DENIC can issue verification requests on existing contacts at any time, particularly when they are used in new operations.
  • 3-week escalation: If no verification is completed within the first ~3 weeks, DENIC will email the registrant directly.
  • Quarantine and deletion: If verification is not done, the domain enters a quarantine period (~90 days). After quarantine, the domain is deleted. Suspension occurs only in critical cases during the quarantine window.
  • DENIC Triggers
    DENIC’s automated risk assessment flags a contact as suspicious. It sends a message to CentralNic Reseller specifying which fields (name, address, email, phone) need verification and the deletion deadline.
  • CentralNic Reseller Informs the Reseller
    We automatically pass on the DENIC message through our backend (CONTACT:UPDATE / CONTACT:NOTIFY). This is sent both as an event queue entry and an email notification (unless you have opted out of emails).
  • Reseller Contacts Registrant
    The reseller must contact the registrant, verify or correct the flagged data, and obtain confirmation. CentralNic Reseller has no direct channel to the reseller’s clients.
  • Reseller Submits Evidence
    The reseller submits updated contact data using the ModifyContact API command, with the X-VERIFICATION-* block. Or they use NIS2 Verify in the Control Panel. The trust framework for DENIC must be set as de_denic.
  • CentralNic Reseller Notifies DENIC
    We process the updated contact and notify DENIC, who reviews the submitted verification data and, if satisfied, closes the request.
  • If No Response
    If the reseller does not respond within ~3 weeks, DENIC emails the registrant directly. After ~90 days total (quarantine period), the domain is deleted.

Associação DNS.PT Requirements

Associação DNS.PT, the Portuguese registry, has announced that from 30 June 2026 mandatory validation and verification requirements for registrant contact data will be introduced.

Unlike DENIC’s risk-based verification model, .PT requires registrars to ensure that the Owner, Admin, Technical, and Billing contacts have been verified before completing certain domain operations.

Mandatory Contact Verification

  • Verified email address and telephone number: Registrars must ensure that each contact associated with the domain has a validated and verified email address and telephone number before certain domain operations can be completed.
  • Optional contacts: Admin, Technical, and Billing contacts remain optional. However, if provided, they must meet the same verification requirements as the Owner contact.
  • No completion without verification: If the required validation and verification cannot be completed, the affected operation cannot proceed.
  • Verification methodology: .PT does not prescribe a specific verification method. Registrars and resellers may implement their own procedures provided they can demonstrate that contact data is operational and reachable.

Operations Requiring Verification

  • New domain registrations: Contact verification must be completed before a new .PT domain can be registered.
  • Ownership transfers: Verification must be completed for the new holder before a transfer of ownership can be completed.
  • Contact data updates: Verification is required when updating a contact email address and/or telephone number.
  • Periodic verification: Registrars are expected to perform validation and verification periodically to support ongoing compliance with applicable legal requirements.

Evidence and Audit Requirements

  • Verification evidence: .PT does not mandate a specific evidence format or retention methodology.
  • Proof of verification: Registrars and resellers must maintain sufficient evidence demonstrating that validation and verification were performed.
  • Registry review: .PT may request supporting evidence where submitted data appears false, incorrect, or incomplete.
  • 8-day response period: Requested supporting documentation must be provided within a maximum of 8 days.

Non-Compliance Consequences

  • Operation rejection: If registrant data cannot be validated and verified, the registration, ownership transfer, or contact update cannot be completed.
  • Additional documentation requests: .PT may require supporting documentation following its risk assessment processes.
  • Domain removal: Failure to provide requested evidence, or provision of insufficient evidence, may result in the removal of the domain name.

Relevant CentralNic Reseller Features

Please refer to the Platform Features Supporting NIS2 section above for details on the CentralNic Reseller capabilities that support compliance with .PT requirements, particularly Email Verification for all TLDs, Phone Number Validation, X-VERIFICATION- Extension, and NIS2 Verify.

Associação DNS.PT Requirements

Associação DNS.PT, the Portuguese registry, has announced that from 30 June 2026 mandatory validation and verification requirements for registrant contact data will be introduced.

Unlike DENIC’s risk-based verification model, .PT requires registrars to ensure that the Owner, Admin, Technical, and Billing contacts have been verified before completing certain domain operations.

Mandatory Contact Verification

  • Verified email address and telephone number: Registrars must ensure that each contact associated with the domain has a validated and verified email address and telephone number before certain domain operations can be completed.
  • Optional contacts: Admin, Technical, and Billing contacts remain optional. However, if provided, they must meet the same verification requirements as the Owner contact.
  • No completion without verification: If the required validation and verification cannot be completed, the affected operation cannot proceed.
  • Verification methodology: .PT does not prescribe a specific verification method. Registrars and resellers may implement their own procedures provided they can demonstrate that contact data is operational and reachable.

Operations Requiring Verification

  • New domain registrations: Contact verification must be completed before a new .PT domain can be registered.
  • Ownership transfers: Verification must be completed for the new holder before a transfer of ownership can be completed.
  • Contact data updates: Verification is required when updating a contact email address and/or telephone number.
  • Periodic verification: Registrars are expected to perform validation and verification periodically to support ongoing compliance with applicable legal requirements.

Evidence and Audit Requirements

  • Verification evidence: .PT does not mandate a specific evidence format or retention methodology.
  • Proof of verification: Registrars and resellers must maintain sufficient evidence demonstrating that validation and verification were performed.
  • Registry review: .PT may request supporting evidence where submitted data appears false, incorrect, or incomplete.
  • 8-day response period: Requested supporting documentation must be provided within a maximum of 8 days.

Non-Compliance Consequences

  • Operation rejection: If registrant data cannot be validated and verified, the registration, ownership transfer, or contact update cannot be completed.
  • Additional documentation requests: .PT may require supporting documentation following its risk assessment processes.
  • Domain removal: Failure to provide requested evidence, or provision of insufficient evidence, may result in the removal of the domain name.

Relevant CentralNic Reseller Features

Please refer to the Platform Features Supporting NIS2 section above for details on the CentralNic Reseller capabilities that support compliance with .PT requirements, particularly Email Verification for all TLDs, Phone Number Validation, X-VERIFICATION- Extension, and NIS2 Verify.

nic.at Requirements

To support its NIS2 compliance requirements, nic.at is introducing several changes affecting .AT contact data, domain transactions and verification procedures. The following changes will take effect on 1 October 2026.

Mandatory Telephone Numbers

A telephone number will be required for .AT contacts. CentralNic Reseller already requires telephone numbers in the correct format, so no technical change or customer action is expected.

Fax Numbers

Fax numbers will no longer be sent to nic.at. You can continue to store fax numbers in your CentralNic Reseller contacts. When a contact is used for a .AT transaction, our system will automatically exclude the fax number to prevent the registry from rejecting the transaction.

Contact Details Can No Longer Be Hidden

nic.at is discontinuing the option to hide phone numbers and email addresses. For legal entities (contacts with the person type ISORGANISATION) these details will be displayed in WHOIS. CentralNic Reseller will therefore stop supporting the X-UNDISCLOSE parameter for .AT contacts. Organizations could use generic email addresses, such as [email protected] instead of personal addresses.

Risk-based Contact Verification

nic.at will use a risk-based approach to identify contact data that may be inaccurate. This does not mean that every .AT contact will need to be verified. Instead, a technical process will identify individual cases and send them to the responsible registrar for review.

CentralNic Reseller will forward the relevant X-VERIFICATION* extensions to nic.at.

Registrars must specify how the contact was verified and retain the supporting documents for one year. If verification is unsuccessful or is not completed by the deadline, nic.at may apply serverHold, prevent further registrations using unverified data, or delete the affected domain.

Parameter

Meaning

Example Values

X-VERIFICATION-DATA# What was verified email / phone / name / address
X-VERIFICATION-TRUSTFRAMEWORK# Who/which TEXT (Entity performing the verification/reseller’s internal trust framework)
X-VERIFICATION-METHOD# How it was verified reachability, electronic_document, phone_call, etc. See all the supported method values below
X-VERIFICATION-EVIDENCE# Type of evidence email_ver_transaction_log, idcard, passport, etc. See all the supported evidence values below
X-VERIFICATION-REFERENCE# Internal reference Free text — use your own record IDs
X-VERIFICATION-RESULT# Outcome success or failed
X-VERIFICATION-TIMESTAMP# When verified ISO 8601 format: YYYY-MM-DD HH:MM:SS

X-VERIFICATION-METHOD# values in details

Values

Meaning

auth Verification completed using an electronic authentication service linked to the user, such as eID or eIDAS.
electronic_document Verification based on official digital documents containing verifiable identification information.
physical_document Verification based on official physical documents containing verifiable identification information.
vdig Validation of digital/electronic evidence by checking the authenticity and integrity of the submitted files or data.
bvr Automated biometric verification using technologies such as facial recognition to confirm the user’s identity remotely.
pvr Physical verification performed remotely by an qualified/authorised person using image or video comparison.
data Verification completed by matching the user’s information against an existing trusted electronic record.
reachability Confirmation that the registrant can be contacted using the provided contact details.

X-VERIFICATION-EVIDENCE# values in details

Values

Meaning

idcard Government-issued identity card used to confirm a person’s identity.
passport Government-issued passport used to verify identity and nationality of its holder primarily for the purpose of international travel.
population_register Record from an official population database.
residence_permit Official document confirming a person’s right to reside within a particular jurisdiction.
proof_of_arrival An audit or compliance record showing that a verification message or document was successfully delivered.
drivers_license Official document permitting an individual to operate motorized vehicles. In the absence of a formal identity document, a driver's license may be accepted in many countries for identity verification.
company_register Official company registry information confirming company-related details.
company_statement Official statement or document issued by a company.
bank_account Bank account information from a recognised financial institution.
online_payment_account Documented payment information used to confirm a transaction.
utility_account Utility account record from a recognized utility provider used as proof of address.
bank_statement Official bank statement issued by a recognised financial institution.
tax_statement Official record issued by a country's tax authority.
written_attestation Written/printed statement/letter confirming the identity from a recognised person or authority.
digital_attestation Electronic confirmation of identity issued by a recognised person or authority.
postal_ver_transaction_log A log of postal or mail-based address verification activities involving PIN code delivery, tracking, or deliverability checks.
phone_ver_transaction_log An audit log of the phone verification process, confirming that the phone number was successfully reached and verified (for example, via SMS or voice call).
email_ver_transaction_log An audit log of the email verification process, confirming that the email address was reachable, verification was completed successfully, and an audit trail is available for compliance purposes.
address_database A record from a trusted government or regulated identity/address database.

Supported Verification Combinations

Use this table to verify that your selected Data, Evidence, and Method combination is supported. If your verification request failed, compare your inputs against the supported combinations below.

Data

Evidence

Method

address address_database data
email email_ver_transaction_log reachability
name bank_account data
name drivers_licence • electronic_document
• physical_document
• bvr
• pvr
name passport • vdig
• electronic_document
• physical_document
• bvr
• pvr
name proof_of_arrival • electronic_document
• physical_document
• bvr
• pvr
• name
• address		 bank_statement • electronic_document
• physical_document
• name
• address
 company_register electronic_document
• name
• address		 company_statement • electronic_document
• physical_document
• name
• address		 idcard • auth
• vdig
• electronic_document
• physical_document
• bvr
• pvr
• name
• address		 population_register • electronic_document
• physical_document
• bvr
• pvr
• name
• address		 postal_ver_transaction_log • vdig
• reachability
• name
• address		 residence_permit • electronic_document
• physical_document
• bvr
• pvr
• name
• address		 tax_statement • electronic_document
• physical_document
• name
• address		 utility_account • electronic_document
• physical_document
• name
• address
• email
 digital_attestation electronic_document
• name
• address
• email
 online_payment_account data
• name
• address
• email
 written_attestation physical_document
phone reachability phone_ver_transaction_log

How Resellers Submit Verification Data

There are two methods. Both result in the same data being stored on the contact handle.

How Resellers Submit Verification Data

There are two methods. Both result in the same data being stored on the contact handle.

Via API

Use AddContact or ModifyContact with the X-VERIFICATION-* parameter set. Multiple verification blocks can be added in a single call by incrementing the index (0, 1, 2…).

To update a specific field, use ModifyContact with the relevant X-VERIFICATION-DATA# + X-VERIFICATION-TRUSTFRAMEWORK# pair. To delete all blocks, send X-VERIFICATION-DATA0= (empty).

Understanding Events and Poll Messages

When DENIC (or another registry) issues a verification request, the following notification chain occurs:

  • DENIC sends an EPP poll message (CONTACT_MODIFICATION_NOTIFY) to CNR with the flagged fields and deletion deadline
  • CNR translates this into a CNR event (class: CONTACT_MODIFICATION, subclass: MODIFICATION_NOTIFY) and pushes it to the reseller’s event queue
  • EPP resellers consume this via — the response contains the flagged contact handle, the verification fields required, and the earliest deletion date
  • An email notification is also sent to the reseller (can be disabled in account settings)
  • The event clearly states the earliest deletion date — resellers must act before this deadline
  • The risk level is not included in the event — only the deadline and which fields need updating

FAQ

Below are the most common questions received from our clients, along with guidance to help you respond confidently and accurately.

NIS2 is EU law, not an optional policy. Once a country has implemented it, non-compliance exposes both the registrar and the reseller to enforcement action. Our platform changes reflect our legal obligations as a registrar. Resellers have their own independent obligations.

DENIC made phone numbers mandatory for .DE contacts in January 2026, and we began enforcing RFC-format validation across all TLDs in November 2025. Numbers that were previously accepted with placeholder values (e.g. +1 111 111 111) are now rejected. You need to update any contacts with invalid phone numbers before using them in new operations.

CentralNic Reseller’s baseline requirements apply to all TLDs: a valid phone number (RFC format, no placeholders), a verified email address, correct contact type (PERSON or ORGANISATION), and accurate name and address. These are enforced at the point of contact creation and update. Some registries (such as DENIC) may request a contact update when they flag data, in which case using the API command, ModifyContact, with corrected data is all that is expected. We do not dictate how resellers verify data pre-registration; that is up to each reseller based on their own processes and NIS2 obligations in their jurisdiction.

DENIC’s risk assessment is automated, and they do not share their exact criteria for it. Common triggers include inconsistent phone formatting (missing country code, spaces), address abbreviations, mismatched contact type (PERSON vs ORG), or non-standard city names. Even correct data may need to be re-submitted via a ModifyContact API command update, which will trigger a fresh risk assessment.

DENIC’s quarantine window is approximately 90 days from the request date. However, if no response is received within ~3 weeks, DENIC will also contact the domain holder directly. To avoid registrant disruption and domain suspension risk, you should aim to respond as quickly as possible, ideally within a few days.

No. CentralNic Reseller does not have a direct relationship with the registrant and cannot contact them. All communication flows through you. We will pass on verification requests to you. It is your responsibly to engage with your customers.

If no contact update is received within ~3 weeks of a verification request, DENIC will email the registrant directly. From that point, communication, including any documentation the registrant may need to provide, is between DENIC and the registrant. We are not involved in that communication and will not receive copies. Try to resolve verification requests before this escalation occurs.

DENIC does not require that CentralNic Reseller nor individual resellers submit identity documents. They just need accurate contact data that passes their risk assessments. If DENIC flags a contact, a ModifyContact with corrected, accurate data is all that is expected.

No. There is no list of flagged or quarantined domains available to CentralNic Reseller or our clients. DENIC sends notifications individually for each domain/contact, which we pass along.

Verification requests arrive as system messages (event class CONTACT_MODIFICATION, subclass MODIFICATION_NOTIFY). The response identifies the contact handle, which fields need updating, and the earliest deletion date. To respond, submit a ModifyContact with corrected contact data. The X-VERIFICATION-* block can optionally be included as supporting metadata but it is not required. Full EPP examples and the XSD schema are in the CentralNic Reseller Knowledge Base.

DENIC decides to suspend a domain, not CentralNic Reseller. DENIC places domains in quarantine and ultimately deletes them if verification is not completed. We will forward all suspension notices to you immediately via event/email. Domains are only suspended in critical cases during quarantine, but deletion follows if the quarantine period expires and the issue has not been resolved. For new registrations, domains that fail validation are simply not activated.

The broadest changes (phone validation, email verification, RDRP) apply to all TLDs on our platform. The most stringent requirements, including risk assessment and verification requests, currently apply mainly to .DE (DENIC), but .FR, .PL, .DK, .IT, .LV, .PT and .ONE all have active NIS2 implementations too.

Genuine DENIC emails always come from a @denic.de sender address. DENIC will never ask for passwords, login credentials, or payment details by email, and all normal verification steps will be carried out by CentralNic Reseller. If anything seems suspicious, contact our support team or call DENIC Direct Services (+49 69 27235-275) or forward the email to [email protected] for verification.

No. Email verification satisfies only part of the requirement. .PT also requires telephone verification. Resellers should record telephone verification using the X-VERIFICATION-DATA#=phone framework before submitting affected .PT transactions.

.PT does not prescribe a specific format, but registrars and resellers should retain sufficient evidence demonstrating:

  • What was verified
  • How it was verified
  • When it was verified
  • The verification outcome

This evidence may be requested by .PT or competent authorities.

No. Supporting documents do not need to be submitted proactively.

However, .PT may request additional evidence if submitted data appears false, incorrect, or incomplete. Requested documentation must generally be provided within 8 days.

The affected operation cannot be completed.

This includes:

  • New domain registrations
  • Ownership transfers
  • Contact data updates

If supporting documentation is later requested and cannot be provided, .PT may remove the domain name.