Domain Validation in the 47-Day Era
On March 15, 2026, maximum TLS certificate validity drops from 398 days to 200 days. That's weeks away. By March 2027, it drops to 100 days. By March 2029, 47 days — with domain validation data reuse limited to just 10 days.
If your organization isn't ready for the first reduction, it's already behind. And 200 days is only the beginning of a compression that ends with certificates expiring faster than most teams can schedule a change window.
This article examines where Domain Control Validation (DCV) stands today, what survived the recent purge of legacy methods, and where enterprises should place their bets before the next reduction hits.
A Note on Where I Started
I previously argued that email-based DCV, specifically through the _validation-contactemail DNS TXT record, was the most operationally sound method for enterprises. The reasoning was straightforward: it placed the validation decision with an explicitly designated, security-aware human rather than diffusing it across operations teams.
The principle was right. The industry chose a different path. The CA/Browser Forum unanimously adopted Ballot SC-090, sunsetting all email-based, phone-based, and crossover DCV methods by March 2028. The rationale: email exhibits "weak binding" — it proves you can interact with a communication medium associated with the domain, not that you have direct administrative control over the domain's infrastructure.
The governance concern I raised hasn't gone away. It's shifted. Instead of asking "who receives the validation email," we now ask "who holds the ACME account key" and "who audits the authorization records in DNS." Same question, different mechanism.
The Graveyard
Of the 22 DCV methods defined in Section 3.2.2.4 of the Baseline Requirements, 15 are already dead or dying. There's no reason to dwell on them. For the record:
Already gone: Eight methods removed in previous revisions — domain contact validation, fax/postal, authorization documents, test certificates, and legacy phone and TLS methods.
Sunsetting (Ballot SC-090, unanimously adopted): All remaining email-based, phone-based, and IP address validation methods. Phone methods go by March 2027. All email methods — including the DNS-defined _validation-contactemail approach — go by March 2028.
Fifteen of twenty-two methods, gone or going. What remains is what matters.
The Survivors
Seven methods survive. All are automation-friendly. All are DNS or HTTP/TLS based. Here they are, evaluated through an enterprise lens.
HTTP File Validation (3.2.2.4.6, .18, .19)
Three methods that all work the same way: place a token at a well-known path on your web server, and the CA fetches it over HTTP.
For enterprises: Problematic. Requires port 80 open to the internet. In many enterprise environments, the service doesn't exist yet when you need the certificate — you're provisioning infrastructure, and you can't serve HTTP challenges from something that isn't running. Multi-team coordination (who deploys the file? who owns the web server?) creates the same operational friction that made email DCV attractive in the first place.
Verdict: Fine for simple public-facing sites with existing infrastructure. Unsuitable as an enterprise-wide strategy.
TLS-ALPN (3.2.2.4.20)
The CA connects to port 443 and completes a TLS handshake using a special ALPN extension. No HTTP involved.
For enterprises: Better than HTTP — doesn't require port 80. But it requires the endpoint to be reachable on port 443 and to support the ACME TLS-ALPN challenge. Load balancers, CDNs, and multi-tenant platforms complicate this. You're still proving control of an endpoint, not control of the domain's namespace.
Verdict: Good for CDN and hosting providers who control the TLS termination point. Less useful for enterprises managing certificates across diverse infrastructure.
DNS Change (3.2.2.4.7)
The original DNS-based challenge: place a CA-provided token as a TXT record at _acme-challenge.yourdomain.com. Per-issuance — a new token every time.
For enterprises: DNS is the right layer — you're proving control of the namespace itself. But per-issuance DNS writes at scale are painful. At 47-day lifetimes, that's a DNS change every 47 days per certificate. With hundreds of certificates, your DNS team is writing thousands of TXT records per year, each with a different ephemeral token. Automation helps, but it requires granting your certificate automation platform write access to your DNS zones — a significant trust decision.
Verdict: Technically sound but operationally heavy at scale. The per-issuance churn is the problem dns-persist-01 was designed to solve.
DNS with Account Label (3.2.2.4.21 — dns-account-01)
An evolution of dns-01 that scopes the challenge to a specific ACME account by including an account-unique label in the DNS record name. This allows multiple independent systems to validate the same domain concurrently without CNAME conflicts.
For enterprises: Addresses a real multi-tenant problem — when different teams or partners need to independently obtain certificates for the same domain. The account-scoped label means you can delegate validation to multiple parties via CNAME without collisions. Combined with CAA records using the accounturi parameter (RFC 8657), you get CA choice enforcement plus per-account scoping.
Verdict: Valuable for complex delegation scenarios. Still per-issuance, so the renewal churn remains. Think of it as dns-01 with better access control.
DNS Persistent Value (3.2.2.4.22 — dns-persist-01)
The newest method, adopted via Ballot SC-088v3 (October 2025). Place a single TXT record at _validation-persist.yourdomain.com that authorizes a specific CA and ACME account to validate your domain indefinitely — or until a date you specify.
_validation-persist.example.com. IN TXT (
"ca.example.com;"
" accounturi=https://acme.ca.example.com/acct/12345;"
" persistUntil=1767225600"
)
One record. No per-renewal DNS writes. No ephemeral tokens. The CA checks the record, confirms the account URI matches, and validation passes.
This is where the enterprise conversation gets interesting.
The Case for Persist — With Governance
The appeal of dns-persist-01 is obvious: it removes DNS from the renewal critical path. Your automation platform obtains and renews certificates without anyone touching DNS again. At 47-day lifetimes with 10-day validation reuse, this isn't convenience — it's survival.
But "set it and forget it" is not an enterprise security posture. The persist record authorizes an ACME account to obtain certificates for your domain with no further proof of control. If that account key is compromised, certificates get issued until someone notices and deletes the record.
This is where persistUntil becomes essential.
Time-Bounded Authorization
The persistUntil parameter is an optional Unix timestamp that tells the CA to stop honoring the record after a specific date. This transforms persist from an open-ended delegation into a time-bounded authorization:
;; Authorization expires December 31, 2026
_validation-persist.app.example.com. IN TXT (
"ca.example.com;"
" accounturi=https://acme.ca.example.com/acct/12345;"
" persistUntil=1798761600"
)
When the timestamp passes, the CA must re-validate. The security team reviews, approves the extension, and updates the record with a new persistUntil value. Or they don't, and the authorization dies.
The Security Team Dashboard
The tooling will evolve. Just as organizations monitor certificate expiry today, they'll monitor persist record expiry tomorrow. The workflow becomes:
- Inventory: Scan all
_validation-persist.*TXT records across your zones - Review: For each record, verify the CA and account URI are recognized and authorized
- Approve or revoke: Extend the
persistUntildate, or delete the record - Alert: Flag persist records approaching expiry, flag unknown account URIs, flag records without
persistUntil(open-ended authorizations)
This is auditable. The records are in your DNS, clearly labeled, clearly scoped, and clearly time-bounded. Unlike opaque _acme-challenge tokens that linger in DNS zones because nobody knows what they are or whether they're still needed, persist records are self-documenting: they name the CA, the account, and the expiry.
The Coming Cleanup
Speaking of opaque tokens — enterprises will eventually face a reckoning with the legacy TXT records littering their DNS zones. Ephemeral _acme-challenge records that were never cleaned up, validation tokens from CAs that are no longer in use, records that nobody can explain and everyone is afraid to delete.
As persist adoption grows, these opaque records become not just clutter but risk. They're unpredictable, unauditable, and potentially exploitable. The enterprise security posture will evolve toward a simple rule: if it's not a clearly labeled persist record with a known CA, known account, and an expiry date, it gets removed. Scorched earth.
Third-Party Partners
Everything above works cleanly for infrastructure you control. The harder question: what about services hosted by partners?
You own example.com. A partner runs app.example.com on their infrastructure. You want your chosen CA to issue the certificates. The partner needs to automate renewal.
dns-persist-01 handles this, but governance becomes critical:
;; Partner's ACME account, YOUR chosen CA, time-bounded
_validation-persist.app.example.com. IN TXT (
"ca.example.com;"
" accounturi=https://acme.ca.example.com/acct/PARTNER_67890;"
" persistUntil=1798761600"
)
Your security team places this record. The partner's ACME account is authorized. The persistUntil timestamp ensures the authorization expires and must be actively renewed.
If the partner says "we need this to be open-ended, no time limit" — that's a conversation about trust, and the answer should be no. Any partner unwilling to operate within a time-bounded authorization model is a partner whose security posture doesn't align with yours.
You have flexibility on which CA to specify. If you want to enforce your own CA choice, the persist record names your CA and you pair it with a matching CAA record:
;; You enforce your CA choice
app.example.com. IN CAA 0 issue "ca.example.com"
_validation-persist.app.example.com. IN TXT (
"ca.example.com;"
" accounturi=https://acme.ca.example.com/acct/PARTNER_67890;"
" persistUntil=1798761600"
)
Alternatively, if the partner has a preferred CA and you're comfortable with it, you can authorize their CA in both records. The important part is that the decision is explicit and documented in your DNS — not implicitly inherited through a CNAME:
;; Partner uses their preferred CA, with your explicit approval
app.example.com. IN CAA 0 issue "partner-ca.example.com"
_validation-persist.app.example.com. IN TXT (
"partner-ca.example.com;"
" accounturi=https://acme.partner-ca.example.com/acct/PARTNER_67890;"
" persistUntil=1798761600"
)
Either way, CAA ensures no unauthorized CA can issue. The persist record ensures only the known partner account can validate. The timestamp ensures it doesn't last forever. And your security team can see exactly who is authorized, with which CA, until when — right in your DNS.
What's Still Missing: A Reporting Mechanism
We've solved authorization. We haven't solved visibility.
Today, if a CA issues a certificate for your domain, how do you find out? You check Certificate Transparency logs. You search through massive append-only public ledgers, hoping to spot your domain names among billions of entries. CT is a valuable public good, but as a monitoring tool for individual domain owners, it's backwards. You're the one doing all the work.
Consider how email authentication solved this problem. DMARC didn't just define policy — it defined a reporting mechanism. When an SMTP server processes mail claiming to be from your domain, it sends you a report. You know who's sending as you, whether they passed authentication, and what happened. You don't check logs — the ecosystem tells you.
Certificate issuance needs the same model, and the persist record is the natural place to build it. The record's syntax is key-value pairs — inherently extensible. The CA is already reading it for every issuance. The reporting endpoint belongs right where the CA is already looking:
;; PROPOSED — extending the persist record with a report parameter
_validation-persist.app.example.com. IN TXT (
"ca.example.com;"
" accounturi=https://acme.ca.example.com/acct/12345;"
" persistUntil=1798761600;"
" report=mailto:cert-reports@example.com"
)
No additional DNS lookup required. The CA parses the persist record, issues the certificate, and sends a structured report to the declared address — all from the same record it was already reading. Authorization, time-bounding, and reporting in one place.
DMARC proved that DNS-declared reporting endpoints work at internet scale. Email security platforms already consume and visualize DMARC XML reports. The same platforms — or purpose-built ones — could consume certificate issuance reports. The pattern is proven. The infrastructure exists.
CT logs would remain as the public transparency layer, just as SPF/DKIM remain as the authentication layer beneath DMARC. But the domain owner would no longer need to actively search CT logs to learn about issuance under their own names. The CA parsed your persist record. It authorized the issuance. It can tell you what it did.
Where This Leaves Us
The DCV landscape in 2026 is clear:
The past: Email, phone, and manual validation methods are being systematically removed. They served their purpose in an era of year-long certificates and human-paced processes. That era is ending.
The present: Seven automation-friendly methods survive. Of these, dns-persist-01 is the most operationally sound for enterprises — it removes DNS from the renewal critical path while keeping authorization records visible, auditable, and revocable in your own zones.
The practice: Use persistUntil timestamps on every persist record. Treat persist records like you treat certificates — inventory them, monitor their expiry, review them periodically. Build the dashboard. Clean up the opaque legacy tokens. For third-party partners, time-bound every delegation and pair it with CAA for CA enforcement.
The future: Extend the persist record with a report parameter. The CA is already reading the record — it can tell you what it did. The domain owner shouldn't have to go looking.
Automation is the edge we have to ride. Persist is how we ride it without losing governance.