Main section

Onur Cebeci • 09.03.2026

New domain validation method simplifies certificate management

Reusable DNS Validation Available From November 2025 (Ballot SC-088v3).

  

  

Relevance for certificate users

★★☆☆☆ (2/5)

Affected users

Organisations with automated certificate issuance (MPKI, CLM platforms), particularly relevant from 2029

Affected certificate types

TLS (DV, OV, EV) and S/MIME certificates

Implementation effort

★★☆☆☆ (2/5); one-time DNS setup per domain, revalidation at least every 10 days (ready for 2029)

CA/B Forum status

SC-088v3 (Server Certificate) adopted 9 October 2025, effective 11 November 2025

SwissSign status

Go-live planned for summer 2026, revalidation every 8 days

Deadline for certificate users

None (optional method)

Links to the ballot

Summary

Certificate Authorities may now use a new domain validation method that employs DNS TXT records with persistent values. Unlike conventional DNS validation, certificate users need only create the DNS record once and can reuse it for all subsequent domain validations. CAs must check this record at least every 10 days in accordance with CA/Browser Forum requirements. The obligation to implement lies with the CAs. Certificate users who automate their certificate issuance (e.g. via SwissSign Managed PKI) gain a simpler path to validating their domain.

DNS validation: what changes in practice?

Since 11 November 2025, Certificate Authorities have been able to use a new method under Section 3.2.2.4.22 "DNS TXT Record with Persistent Value" for domain validation. CAs create an account-bound token that users place in their DNS. The CA then validates this token at least every 10 days. Unlike conventional methods, there is no need to place a new TXT record with a random value for each domain validation. The validation frequency already meets the requirements that will apply generally to domain validation from March 2029.

The TLS Baseline Requirements have been updated to v2.1.9.

Action required for certificate users

For organisations with 250+ certificates

Impact level: Medium to high (increasing from 2026)

If you use automated certificate management (Managed PKI, ACME, REST APIs, CLM platforms): The new method is already practical today. Whilst other methods (DNS-01, HTTP-01) require a change for each domain validation, Persistent DNS allows the CA to validate the same record automatically at least every 10 days, without any DNS updates on your part.

If you have strict DNS change management processes: Persistent DNS is ideal, a one-time DNS change rather than multiple times per year.

If you manage many domains: Administrative overhead drops significantly. 100 domains × 4 validations per year = 400 DNS changes with other methods vs. 100 one-time set-ups with Persistent DNS.

Preparation for 2029: From 2029, the maximum permitted validity period for TLS/SSL certificates falls to 47 days and domain ownership must be validated at least every 10 days. With Persistent DNS you are already prepared.

What you can do now: We will inform you in good time here, via the RSS feed, and by e-mail before we activate the validation method in our MPKI, including instructions on how to set it up.

Risks of inaction: From 2029 at the latest, domain information must be validated at least every 10 days. This makes manual DNS management increasingly unworkable. With Persistent DNS you are already prepared today and will save DNS changes. Organisations that wait until 2029 will face migrating hundreds of DNS records under time pressure.

For smaller organisations (<250 certificates)

Impact level: Low to medium

For manual workflows with infrequent certificate issuance and non-critical DNS management, the benefit remains limited until 2026/2027.

SwissSign implementation

SwissSign plans to implement this new validation method in July 2026, to offer customers enhanced DNS security and to allow sufficient time to prepare for shorter validity periods. To provide a safety margin, as is standard practice among Certificate Authorities, SwissSign will revalidate domains using the new method every 8 days.

Background to the ballot: reducing operational complexity

Current situation: With certificate validity periods of more than one year, manual management of DNS entries represents an acceptable overhead for most organisations.

Problem / driver: The reuse periods for domain validation data are being significantly shortened in the coming years, with the aim of strengthening the security of the entire public PKI ecosystem:

  • From 15 March 2026: maximum reuse period of 200 days

  • From 15 March 2027: maximum 100 days

  • From 15 March 2029: maximum 10 days

Context: The new method solves this problem. The DNS record is created once and remains permanent. The CA revalidates at least every 10 days, but without the user needing to update the DNS. This makes the method valuable today and essential by 2029.

Background to DNS-based domain validation

What is DNS-based domain validation (existing methods)?

DNS-based domain validation is a method by which the CA verifies that the applicant controls the DNS zone of a domain:

  • The CA generates a random token or requests a token

  • The applicant creates a DNS TXT record (e.g. under _acme-challenge.example.com) containing this token

  • The CA queries the DNS record and validates the token

  • After successful validation, the record may be deleted

  • This process is repeated with a new token for each domain validation

This method exists in various forms (DNS-01 Challenge for ACME, DNS Change Method 3.2.2.4.7, etc.).

What is Persistent DNS TXT Validation (new method)?

The new method works similarly, but with reusable records that are revalidated by the Certificate Authority at least every 10 days.

Security:

  • The Issuer Domain Name prevents other ("malicious") CAs from reusing the same record

  • The Account URI ensures that only the legitimate customer can have certificates issued

  • The 10-day maximum window reduces the risk in the event of domain takeovers

What is an Account URI?

The Account URI is a unique identifier (in URI format) that SwissSign assigns to each customer account.

This URI serves as proof of authorisation: only someone who has both access to the DNS zone and knows the correct Account URI can have certificates issued. An attacker who has only compromised the DNS zone cannot obtain certificates without the Account URI.

Frequently asked questions (FAQ)

No. This is an optional new validation method. All existing methods (HTTP-01, DNS-01 with random value, constructed email, TLS-ALPN-01, etc.) remain fully available and continue to function unchanged.

You can create a separate DNS TXT record for each CA. Records are distinguished by the Issuer Domain Name, so each CA validates only its own record. Multiple TXT records for the same name are permitted in DNS and are all returned.

Yes. The Persistent DNS method supports wildcard certificates (e.g. *.example.com). Once validated, the CA may also issue certificates for other FQDNs ending with all the domain labels of the validated FQDN, exactly as with other DNS-based methods.

Records created using the new method no longer need to be manually renewed by the user. Optionally, the persistUntil attribute may be added, an optional parameter in the TXT record of the new Persistent DNS TXT Validation method. It specifies until when the CA may treat this validation record as valid. If this parameter is not provided, the record is treated as having no expiry date and is revalidated by the CA at least every ten days.

Using these two free tools:

  1. dig: Returns the current DNS TXT record — verify that the format and values are correct

  2. DNS Checker: Shows DNS propagation worldwide — ensure the record is visible everywhere

Yes, because domain ownership must also be demonstrated for S/MIME certificates. Section 3.2.2.1 of the S/MIME requirements references Section 3.2.2.4 of the TLS requirements.

Yes. All TLS/SSL certificates (DV, OV, EV) require domain validation in accordance with Section 3.2.2.4. The new method can be used for domain validation of any TLS/SSL certificate (the reusability of "Subject Identity Information" is also being reduced as part of the validity period changes). OV and EV certificates additionally require organisation validation, but domain validation works identically.