The Unpopular Opinion: Email is the Best Way to Validate Domain Control

I remain with the opinion operationally email may be a better approach but since writing this I learned whois is no longer a trusted source of email address. There are now also records in DNS that can define the email address a CA should follow for domain validation.

Public TLS certificates are the bedrock of web security, but how does a Certificate Authority (CA) know you actually control the domain you're requesting a certificate for? This critical step is Domain Control Validation (DCV), and while seemingly straightforward, the standard methods present real operational friction and, I believe, often misplace the security decision.

Before issuing, a CA performs checks, notably looking for Certification Authority Authorization (CAA) records in DNS. This record dictates which CAs are allowed to issue certificates for your domain, and CAs must respect it (yes, this check involves traversing up the domain tree and handling CNAME complexities). But even with CAA authorization, the CA still needs proof you control the specific hostname right now. This is where the three common DCV methods come in: HTTP file validation, DNS TXT record validation, and Email validation.

My controversial take? Despite its reputation, email validation, when targeted correctly, is the most logically sound and operationally efficient method for many organizations. Let's break down why.

The Operational Hurdles of HTTP and DNS Validation

1. HTTP File (/.well-known/pki-validation/): The CA asks you to place a specific file with specific content at a known path on your web server.

   • The Problem: In large or complex organizations, figuring out which server hosts your.domain.com, who manages it, and getting a file deployed under /.well-known/ can be a slow, painful process involving multiple teams, ticketing systems, and deployment windows. Does the web admin receiving the ticket even understand the security implication of placing that file? Often, it's just another task to clear.

2. DNS TXT Record: The CA gives you a unique token to place in a DNS TXT record for your domain (or a specific subdomain like _acme-challenge).

   • The Problem: While DNS changes might feel like a "well-greased wheel" in some places, the same operational challenges often apply. Who owns the zone? How quickly can records be updated? More critically, does the DNS admin vetting the ticket truly understand they are enabling certificate issuance? And when does that temporary TXT record get removed? DNS TTLs manage cache expiry, not record lifetime, leaving potential validation tokens lingering if cleanup isn't automated or rigorously tracked.

In both HTTP and DNS scenarios, we often burden operations teams—web admins, DNS admins—with making a critical security approval implicitly through task execution. Their primary focus isn't certificate lifecycle management, and asking them to vet the legitimacy of every request adds friction and potential risk if they lack full context. These operational burdens are significantly amplified in environments lacking robust automation, a critical consideration as the industry moves towards shorter certificate lifetimes (e.g., potentially 47 days by 2029). Frequent, manual interventions for DCV under such conditions become unsustainable.

The Case for (Targeted) Email Validation

This leaves us with email. The CA sends an email containing a unique validation link or code to an address associated with the domain. Historically, a key method for targeting responsible individuals was by sending these emails to the domain contact addresses (registrant, technical, administrative) listed in the domain's public WHOIS record.

The Shift Away from WHOIS: However, the landscape has changed. Due to evolving privacy standards and security considerations, the CA/Browser Forum has mandated the deprecation of WHOIS data as a reliable source for domain contact information for DCV. By mid-2025, CAs will no longer be able to use WHOIS-derived email addresses for this purpose.

This might seem like a blow to email validation, especially to the argument of reaching the most appropriate domain contact. But new methods have emerged that allow domain owners to explicitly define validation email addresses, keeping the core benefit of email alive and well.

The CA/Browser Forum Baseline Requirements now primarily support two categories of email addresses for DCV:

1. Generic Constructed Email Addresses: These are the familiar admin@, administrator@, hostmaster@, postmaster@, and webmaster@ for the requested domain. Frankly, as previously noted, these are often unmonitored black holes or overloaded distribution lists if not carefully managed. Relying solely on these can be problematic.
2. DNS TXT Record Defined Email Contact: This method provides a direct and explicit way for domain owners to designate a validation contact. Domain owners can now create a specific DNS TXT record to designate an email address for DCV. For example, a record like _validation-contactemail.yourdomain.com TXT "security-alerts@yourdomain.com" explicitly tells the CA where to send validation emails.

This DNS-defined email contact is where targeted email validation maintains its distinct advantages:

• Explicit Alignment of Responsibility: Who creates a _validation-contactemail DNS record? Someone with DNS control, deliberately choosing an address (or a specific team/role account) they deem responsible for domain security and certificate issuance. These individuals are far more likely to understand the context: "Did I, or someone on my team, just request a certificate for this domain?" They are explicitly designated for this security-sensitive communication. This is arguably a stronger signal of responsibility than relying on potentially outdated or broadly assigned WHOIS contacts.
• Centralized and Intentional Decision: Instead of diffusing the approval across potentially unaware operational teams (as with HTTP/DNS token methods) or relying on poorly monitored generic mailboxes, the decision lands directly with the entity or mailbox explicitly designated by the domain administrator for this very purpose.
• Addressing "Insecure Email": The common objection that "email isn't secure" remains addressable:
  • Transport Security: CAs typically use STARTTLS for opportunistic encryption in transit. You can (and should) configure your own mail infrastructure to enforce TLS for incoming mail. You control this environment.
  • Process Security: The security isn't just the email arriving; it's the action required on the unique, time-sensitive token within it. It's proof of control over the authorized and explicitly designated mailbox.

The Ideal Scenario: Leveraging Explicit Email Designation

If I've gone to the trouble of setting a CAA record pointing exclusively to MyFavCA, it implies a relationship and likely an account with that CA. In this evolving scenario, CAs should strongly encourage or even allow account holders to enforce stricter validation policies. Let me specify: "For domains associated with my account and protected by my CAA record, only send DCV emails to the address defined in the _validation-contactemail DNS TXT record. If that record doesn't exist, perhaps fall back to a specific, pre-validated contact email within my CA account, but do not attempt the generic admin@, webmaster@ et al. unless explicitly permitted by me."

This approach leverages the new DNS-based email contact method to its full potential, eliminating the noise and risk associated with generic legacy mailboxes and ensuring the validation request goes only to the responsible parties I have explicitly designated via DNS.

Conclusion

While HTTP and DNS token validation are technically direct, their operational overhead often places an undue burden on teams not primarily focused on certificate lifecycle management, especially without full automation. In an ideal world with universal, flawless automation, any allowed DCV method could become "set and forget," significantly reducing this friction, and the choice of method would depend on other security or policy aspects. However, for many organizations, this level of automation is not yet a reality. Consequently, email validation, particularly when directed to an explicitly defined contact via the _validation-contactemail DNS TXT record, offers a more operationally sound model. This method aligns the validation step with an entity clearly designated by the domain administrator as responsible for domain security and best positioned to understand the request's implications. As certificate lifetimes shorten, with proposals for as little as 47 days by 2029, the need for efficient and correctly targeted DCV methods becomes even more acute. Therefore, targeted, DNS-driven email validation remains a robust and logical choice for managing DCV effectively.

Looking Forward: Cementing Control with DNSSEC-Validated Policy

Further enhancements to predictability and security can be achieved by leveraging DNSSEC. Domain owners could define their preferred DCV policies directly within their DNS zones, authenticated and integrity-protected by DNSSEC. A CA, when performing validation for a DNSSEC-signed zone, could query for and trust these policy directives.

This could take a couple of forms:

1. Augmented CAA Records: New CAA property tags could be proposed. For example, a tag like dcvmethod: dns-email-only could explicitly tell the CA only to use the email address specified in the _validation-contactemail DNS record. Another tag like dcvemail: explicit-security-validation@example.com could direct all validation attempts to a specific, monitored mailbox, potentially overriding even the _validation-contactemail record if the domain owner wants to centralize further for specific CAs.
2. A New DNS Record Type: A dedicated record type (e.g., DCVPOLICY or DOMAINCTL) could hold structured information specifying allowed DCV methods (e.g., "email-dns-contact-only"), required parameters (like mandating the presence of a _validation-contactemail record), and potentially other related issuance policies.

The DNSSEC Imperative: The key here is DNSSEC validation. Without the cryptographic assurance provided by DNSSEC, a CA couldn't fully trust that such a policy record hadn't been tampered with in transit. But with DNSSEC, the CA gains high confidence in the authenticity of the domain owner's stated policy.

Benefits of This Approach:

• Explicit Domain Owner Control: Puts granular control over the validation process directly into the hands of the domain owner via authoritative, and ideally DNSSEC-signed, DNS.
• Enhanced Security and Predictability: Removes ambiguity. CAs would follow an explicit, verifiable policy, reducing reliance on potentially less secure generic defaults or methods unsuitable for the specific environment.
• Improved Alignment: Allows organizations to definitively route validation challenges to the teams or individuals designated (e.g., via the _validation-contactemail record) and equipped to handle them securely. This reinforces the principle of putting the decision with the responsible, explicitly designated party.
• Reduced Operational Friction: By disallowing problematic methods or directing requests precisely to the intended, monitored mailbox, it could streamline the often-cumbersome validation process, especially critical if full end-to-end automation of the DCV method itself is not yet implemented.

While standardization and widespread adoption (including robust DNSSEC deployment) present hurdles, proposing such DNSSEC-validated mechanisms offers a clear path toward a more secure, predictable, and operationally sane certificate validation ecosystem. It builds upon the logic of targeted validation by making the domain owner's intent explicit and verifiable. In a world moving towards highly automated certificate lifecycles, giving domain owners DNSSEC-backed power to enforce their chosen method(s) and direct challenges appropriately remains a significant step forward, complementing efforts to automate the DCV interactions themselves. ```