Skip to main content

​
Contacts approach

Reseller-as-Contact optimizes for speed and reliability, while End-User-as-Contact optimizes for clear ownership at the cost of verification and email complexity. Name.com offers three routes you can take with comms:
  • Reseller as contact (you set yourself as the registrant contact): end users will not receive emails from name.com; your contact will
  • Name.com sends required emails on your behalf (whitelabeling available upon request; see Reseller Whitelabeled Email Examples)
  • You send your own emails (requires an addendum assuming email responsibility, plus logging evidence). name.com does not send registrant email for those accounts. For registry compliance notices, subscribe to domain.registry.compliance_notice; that webhook is the only way name.com delivers this notice.
Please reach out to reseller@name.com for more information. To learn more about verification flows and logging requirements for sending your own emails, see the Contact Verification Compliance Guide.

​
Reseller as contact

​
Pros

  • Simplified onboarding
  • High contact verification success (no domains disabled due to verification)
  • Full control over domain management

​
Key risk: reseller as registrant of record

When the reseller is set as the registrant/admin contact, the reseller is the legal owner of the domain in ICANN and registry systems. While this reduces friction at registration time, it shifts ongoing responsibility to the reseller, including:
  • Mediating ownership and transfer requests if a customer wants to move or reclaim a domain
  • Receiving and responding to ICANN compliance, abuse, and policy notices
  • Managing all domain issues, recovery requests, and edge cases on behalf of customers
Because the reseller is the registrant of record, legal notices (e.g., cease-and-desist letters, takedown requests, and potential lawsuits) are served to the reseller, not the end customer.
As domain volume grows, this model can increase support load, compliance responsibility, and operational risk. Resellers using this approach should clearly document domain ownership and customer rights in their terms of service.

​
End user as contact

​
Pros

  • Clear end-customer ownership of domains
  • Avoids reseller legal ownership and liability described above

​
Cons

  • Lower contact verification success rates
  • Requires reliable end-user email delivery
  • Verification, renewal, and compliance emails must either be white-labeled or fully owned by the reseller. If you’d like to fully take over emails and the verification process, please reach out to our team.
  • Higher onboarding and operational complexity

​
ICANN-required registrant emails

​
Verification

The below also must be shared with new registrants: The Organization field in your domain’s contact details relates to legal ownership. If this field contains information, the listed organization is considered the legal “Registered Name Holder” (domain owner).

​
Renewal

​
Transfers, change of registrant, and contact review

​
Registry compliance notices

A registry may require the registrant to remediate a policy issue by a deadline (for example, .NEW Domain Registration Policy requirements). These are not ICANN FOA or WDRP emails, but the domain owner still needs the notice. If name.com sends email for you: we email the domain’s registrant. Whitelabeled branding is applied when your account has it configured. Subscribe to domain.registry.compliance_notice only if you want to take over this notice: that replaces the email with the webhook. Unsubscribing resumes the email. If you have signed an addendum to assume all email responsibility: name.com does not send this email. The webhook is the only delivery path. Subscribe to domain.registry.compliance_notice or the registrant will not be notified. Use the payload to notify the end user. Human-readable fields (issueDescription, remediationInstructions, agreementReminder, noncomplianceConsequences, contactInstructions) are written for forwarding. Branch on policy, not that text. Include registryEmail in the message body when it is present so the registrant can contact the registry. Webhook delivery failure does not fall back to email.