Summary

  • RFC 9873 defines an EPP command-response extension associating one additional email address with a contact object.
  • The additional value can be ASCII or SMTPUTF8 internationalized mail; primary identifies the preferred address within this extension.
  • An empty addlEmail removes the second address, and primary must be absent in that removal form.

The authority here is narrow and concrete. RFC 5730 supplies the EPP command and response framework; RFC 5733 defines contact objects and disclosure treatment; RFC 9873 adds the additional email element and its update semantics. If the contact disclosure flag applies, it applies to both email fields. Negotiated support also has a transport consequence: clients and servers must process ASCII and SMTPUTF8 forms and support SMTPUTF8 when sending or receiving mail. RFC 6530 and RFC 6531 explain that internationalized-mail context.

The RFC establishes a data model and protocol behavior. It cannot verify mailbox ownership or guarantee delivery. It does not show that SMTPUTF8 support is universally deployed by registries or registrars. Marking an address primary does not automatically change every downstream registry workflow. A second address does not resolve every privacy, abuse-contact, or domain-transfer failure. Finally, the RFC alone provides no basis for adoption, performance, incident, or named-operator deployment claims.

The boundary matters because the second field can look like a routing promise when it is only protocol state. Operators should validate Unicode confusability, email-domain syntax, and reachability as policy controls, while recognizing that such checks remain separate from EPP’s representation of the contact.

Sources