The DCV Methods Sunset Timeline
By 2028, 11 of today's domain validation methods will be completely prohibited. The email addresses you've been using for certificate requests? Gone. Phone-based validation? Eliminated. If your certificate renewal process depends on [email protected] or a phone call from your CA, you have 24 months to redesign your validation infrastructure.
Watch the Video
At a Glance
11
Methods sunset
4
Phases
Mar 2028
Final sunset
3
Ballots
DNS and HTTP validation methods are NOT affected. ACME-based automation remains the recommended path forward.
Primary audience: IT engineers, PKI engineers, and security management
Phase 0 (WHOIS)
July 15, 2025
Phase 1 (IP Crossover)
March 15, 2026
days
hrs
min
Phase 2 (Phone/DNS)
March 15, 2027
days
hrs
min
Phase 3 (Email)
March 15, 2028
days
hrs
min
TL;DR: All human-dependent email/phone DCV is being phased out; DNS-01, HTTP-01, and TLS-ALPN-01 survive and must be automated. If you don't change anything, routine renewals that used to "just work" via email will start failing between 2026 and 2028.
The Three Ballots
SC-080v3 (The First Wave)
COMPLETEAuthor
Martijn Katerbarg (Sectigo)
Effective
July 15, 2025
Scope
WHOIS-based email and phone validation
Trigger
WatchTowr .mobi TLD research (September 2024)
Modifies
BR sections 3.2.2.4.2, 3.2.2.4.15
SC-090 (The Main Sunset)
PHASED 2026-2028Author
Corey Bonnell (DigiCert)
Passed
November 2025
Scope
All remaining email, phone, and crossover methods
Modifies
BR sections 3.2.2.4.4, 3.2.2.4.8, 3.2.2.4.13, 3.2.2.4.14, 3.2.2.4.16, 3.2.2.4.17, 3.2.2.5.2, 3.2.2.5.5
SC-091 (IP Address Validation)
MARCH 2027Author
Corey Bonnell (DigiCert)
Passed
November 2025
Scope
Reverse Address Lookup sunset + introduces new persistent DCV TXT method for IP addresses
Modifies
BR section 3.2.2.5.3 (new 3.2.2.5.X for persistent TXT)
Key Point: Like SC-081, these ballots passed with strong consensus. Browser vendors are aligned on eliminating manual, human-dependent validation methods.
The Complete Sunset Timeline
This is the master schedule. Copy this table into your internal PKI roadmap. All 11 methods being sunset are listed below with their BR section references (see table).
| Phase | Effective Date | Method Sunset | BR Section | Ballot |
|---|---|---|---|---|
| 0 ✓ | July 14, 2025 (passed) | Email/Fax/SMS/Postal to Domain Contact | 3.2.2.4.2 | SC-080 |
| 0 ✓ | July 14, 2025 (passed) | Phone Contact with Domain Contact | 3.2.2.4.15 | SC-080 |
| 1 | March 14, 2026 (passed) | IP Address (crossover method) | 3.2.2.4.8 | SC-090 |
| 2 | March 14, 2027 (150d) | Phone Contact with DNS TXT Contact | 3.2.2.4.16 | SC-090 |
| 2 | March 14, 2027 (150d) | Phone Contact with DNS CAA Contact | 3.2.2.4.17 | SC-090 |
| 2 | March 14, 2027 (150d) | Email to DNS TXT Contact | 3.2.2.4.14 | SC-090 |
| 2 | March 14, 2027 (150d) | Reverse Address Lookup | 3.2.2.5.3 | SC-091 |
| 2 | March 14, 2027 (150d) | Email/Fax/SMS/Postal to IP Contact | 3.2.2.5.2 | SC-090 |
| 2 | March 14, 2027 (150d) | Phone Contact with IP Contact | 3.2.2.5.5 | SC-090 |
| 3 | March 14, 2028 (516d) | Constructed Email to Domain Contact | 3.2.2.4.4 | SC-090 |
| 3 | March 14, 2028 (516d) | Email to DNS CAA Contact | 3.2.2.4.13 | SC-090 |
Total: 11 methods eliminated — BR = Baseline Requirements section reference
What This Means for PKI Engineering
The DCV sunset eliminates human-dependent validation methods. Here's what changes in your workflow:
- Eliminate email-based DCV from all production workflows — admin@, webmaster@, hostmaster@ validation is dying
- Move away from phone validation entirely — no CA will support calling you to verify domain ownership
- Standardize on DNS-01 or HTTP-01 validation — these methods (used by Let's Encrypt/ACME, internal CLM platforms, cloud DNS APIs) survive and scale with automation
- Audit your current DCV method usage — work with your CA to identify which methods you're using today
- The crossover method (IP → domain) ends first — if you validate domains by validating their IP addresses, migrate by March 2026 (now in effect)
- Ensure your CLM platform can complete DCV challenges via API — your certificate lifecycle management system must request DNS-01/HTTP-01/TLS-ALPN-01 challenges programmatically, not via human inboxes
- Build reporting to show "certs by DCV method" — prove that sunset methods are gone ahead of Phase 2 and Phase 3
Bottom line: If your validation process involves checking an email inbox or answering a phone call, that process will start breaking between 2026 and 2028.
Use the Migration Matrix below as the basis for your DCV migration backlog.
What IT Engineers Need to Do Now
- Map which apps or environments rely on email/phone DCV today — flag them for migration before 2027
- Ensure you have scriptable access to DNS or web servers — PKI needs to roll out DNS-01/HTTP-01 challenges without tickets getting stuck in queues
- Plan for "hands-off" renewals — the goal is DCV runs via automation and your only involvement is handling exceptions or failures
Example: The public-facing customer portal that still uses [email protected] for renewals should move to DNS-01 via your cloud DNS provider.
Phase-by-Phase Breakdown
Use this section when building migration milestones or CA/Browser Forum-aligned roadmaps.
Phase 0: Already Complete ✓
July 15, 2025Methods removed:
- Email/Fax/SMS/Postal to Domain Contact (BR 3.2.2.4.2)
- Phone Contact with Domain Contact (BR 3.2.2.4.15)
What happened: These methods relied on WHOIS data to find domain contacts. The WatchTowr research showed that expired WHOIS infrastructure could be hijacked to intercept validation emails.
Phase 1: March 15, 2026
0 days awayMethod removed:
- IP Address crossover method (BR 3.2.2.4.8)
What it was: Validate domain ownership by validating the IP address the domain resolves to. This created a dependency chain where IP validation "proved" domain ownership.
Why it's dying: The indirection adds complexity without adding security. If you can validate the IP, you should validate the domain directly.
Phase 2: The Big Wave
March 15, 2027Methods removed (6 total):
- Phone Contact with DNS TXT Contact (BR 3.2.2.4.16)
- Phone Contact with DNS CAA Contact (BR 3.2.2.4.17)
- Email to DNS TXT Contact (BR 3.2.2.4.14)
- Reverse Address Lookup (BR 3.2.2.5.3)
- Email/Fax/SMS/Postal to IP Contact (BR 3.2.2.5.2)
- Phone Contact with IP Contact (BR 3.2.2.5.5)
What these were: Methods that used DNS records (TXT, CAA) or IP WHOIS data to find contact information, then validated via email or phone to that contact.
Why they're dying: Human-dependent validation doesn't scale with shorter certificate lifetimes. With 47-day certs and 10-day DCV reuse by 2029, you'd need ~35 validations per domain per year.
New method introduced (SC-091): Persistent DCV TXT record for IP address validation — an automated alternative to the sunset methods.
Phase 3: The Final Sunset
March 15, 2028Methods removed:
- Constructed Email to Domain Contact (BR 3.2.2.4.4)
- Email to DNS CAA Contact (BR 3.2.2.4.13)
What these were: Constructed email sends validation to admin@, webmaster@, hostmaster@, postmaster@, or administrator@ at the domain. DNS CAA email reads an email address from the domain's CAA record. Their removal marks the end of email-based domain validation entirely.
The WatchTowr Research That Started It All
In September 2024, security researchers at WatchTowr published findings that exposed critical weaknesses in WHOIS-based certificate validation:
The $20 Attack:
- Researchers acquired the expired domain for the .mobi TLD's WHOIS server
- For $20, they gained control of legacy WHOIS infrastructure
- Certificate Authorities querying this WHOIS data would receive attacker-controlled contact information
- This could have enabled fraudulent certificate issuance for any .mobi domain
The Response:
- CA/Browser Forum fast-tracked SC-080 to eliminate WHOIS-dependent methods
- July 2025 deadline was aggressive but necessary
- Broader review led to SC-090/SC-091 sunset of all manual methods
"The infrastructure underlying WHOIS has always been fragile... this research demonstrated that fragility could be weaponized against the certificate ecosystem."
Lesson: Any DCV method that depends on third-party registry/WHOIS infrastructure is now considered too brittle. The CA/Browser Forum will not allow validation to rely on infrastructure you don't control.
What Methods Survive?
| Method | BR Section | Type | Automatable? | Status |
|---|---|---|---|---|
| Agreed-Upon Change to Website | 3.2.2.4.6 | HTTP-01 | REMAINS | |
| DNS Change | 3.2.2.4.7 | DNS-01 | REMAINS | |
| TLS Using ALPN | 3.2.2.4.20 | TLS-ALPN-01 | REMAINS | |
| ACME (any method) | 3.2.2.4.19 | Protocol | REMAINS |
Notice the pattern? Every surviving method is fully automatable. The sunset isn't random — it's eliminating human-dependent validation to enable the shorter certificate lifetimes required by SC-081.
Migration Matrix
| If You're Using... | Migrate To | Effort | Notes |
|---|---|---|---|
| admin@ email validation | DNS-01 or HTTP-01 | Medium | Requires DNS API access or web server control |
| WHOIS-based email | DNS-01 or HTTP-01 | Medium | Already sunset (July 2025) |
| Phone validation | DNS-01 or HTTP-01 | Medium | No phone-based alternatives |
| IP crossover method | Direct DNS-01 for domain | Low | Validate domain directly, not via IP |
| Reverse address lookup | Persistent DCV TXT (SC-091) | Low | New method available March 2027 |
| Mixed methods across CAs | Single standardized method per domain | High | Requires cross-CA alignment, possibly vendor consolidation |
The Connection to 47-Day Certificates
The DCV sunset isn't happening in isolation — it's part of the same automation push as SC-081v3 (47-day certificates).
| Timeline | Cert Validity | DCV Reuse | Validations/Year |
|---|---|---|---|
| Today | 398 days | 398 days | ~1 |
| March 14, 2027 (150d) | 100 days | 100 days | ~4 |
| March 14, 2029 (881d) | 47 days | 10 days | ~35 |
At 35 validations per domain per year:
- Email validation: Checking inbox 35 times/year for each cert? Unsustainable.
- Phone validation: Answering 35 calls/year from your CA? Impossible.
- DNS/HTTP automation: Runs in the background, scales infinitely.
The sunset and shorter validity are the same strategy: Force automation to improve security.
For PKI / Security Managers
Planning your organization's migration away from sunset DCV methods:
- Audit current DCV methods now — work with your CA to get a report of which methods are in use across your certificate portfolio
- Identify certificates using sunset methods — these need migration plans
- Evaluate DNS-01 feasibility — do you have API access to your DNS provider? Can your CLM platform manage DNS records?
- Consider HTTP-01 as fallback — requires web server access but no DNS changes
- Budget for CLM/automation work — this aligns with SC-081 automation requirements
- Set internal deadlines ahead of CA/B Forum deadlines — don't wait until the last month
Ownership matrix: DNS team owns DNS-01 infrastructure, web/app teams own HTTP-01 endpoints, PKI owns policy and exception handling. Make these responsibilities explicit before migrations begin.
Quick start: See the Migration Matrix above and use it as your project backlog seed.
How to Explain This to Senior Management
- This is a regulatory change, not an optional best practice — By 2028, the old email/phone-based checks simply stop working
- Risk if we do nothing: Routine certificate renewals will start failing between 2026 and 2028, causing outages and incident noise
- Investment needed: Time and budget for DNS/HTTP automation and CLM integration now, which reduces outage risk and manual effort later
- Cross-team impact: DNS, application, and PKI teams must coordinate; treating this as "just a certificate team task" will delay migrations
This aligns with our broader automation and resiliency goals; treating it as a one-off PKI task would under-scope the work.
Primary Sources
Related Guides
The 47-Day Certificate Timeline
SC-081v3 is reducing certificate validity to 47 days by 2029
ACME Protocol Guide
Learn how to automate certificate issuance with ACME
What is the CA/Browser Forum?
Understand the organization behind these ballots
Certificate Lifecycle
From request to renewal — the complete lifecycle
The PKI Automation Gap
Why nobody is ready — an honest assessment of where automation fails