Raising the Bar: The CA/B Forum’s Move to Extend CAA to S/MIME 

Quick answer: The CA/B Forum’s Ballot SMC05 made CAA (Certification Authority Authorization) checks mandatory for every publicly trusted S/MIME certificate, effective March 15, 2025. Under RFC 9495, certificate authorities must check a domain’s “issuemail” DNS record before issuing an S/MIME certificate, giving domain owners direct control over which certificate authorities can issue email certificates for their organization.

S/MIME (Secure/Multipurpose Internet Mail Extensions) certificates encrypt email content and let recipients verify a message actually came from the sender it claims to be from. Until recently, any publicly trusted certificate authority could issue an S/MIME certificate for an email domain without checking whether the domain owner had authorized it. Ballot SMC05 closed that gap by extending an existing TLS control, CAA, into the S/MIME issuance process. This update walks through what changed, why it matters for enterprise certificate governance, and what PKI, security, platform, and compliance teams should do next.

Key Takeaways

• Ballot SMC05 made CAA checks mandatory for publicly trusted S/MIME certificate issuance as of March 15, 2025, under RFC 9495’s issuemail DNS tag.
• Domains without an issuemail record still allow any publicly trusted CA to issue an S/MIME certificate for them, a governance gap many enterprises have not closed.
• DigiCert’s July 2025 Trust Pulse Survey found 45% of organizations experienced certificate-related downtime in the past year, and 37.5% linked outages to expired certificates managed manually.
• The CA/B Forum’s parallel move to a 47 day maximum TLS certificate validity by March 2029 makes automated, policy-driven certificate management necessary across both TLS and S/MIME.
• PKI, security, platform, and compliance teams each own a piece of CAA and S/MIME governance, and coordinated ownership closes the gaps between DNS configuration, issuance monitoring, and audit evidence.

What CAA Is and What Changed With Ballot SMC05

What Is CAA (Certification Authority Authorization)?

A CAA record is a DNS resource record that lets a domain owner specify which certificate authorities are permitted to issue certificates for that domain. Originally defined for TLS in RFC 8659, the process works like this: before issuing a certificate, a CA checks the domain’s CAA records. If none exist, the CA can proceed after standard validation. If CAA records exist, the CA may only issue a certificate if it is named in one of them. This prevents an unauthorized or misconfigured CA from issuing a valid certificate for a domain it has no relationship with.

What RFC 9495 and the issuemail Tag Add for S/MIME

RFC 9495 applies the same logic to email addresses. It defines a new CAA property tag, “issuemail”, that a domain holder can publish to specify which CAs are authorized to issue S/MIME certificates for that email domain. Ballot SMC05 amended the S/MIME Baseline Requirements to require public CAs to check for an issuemail record before issuing a certificate, following the same authorization model that has protected TLS issuance for years.

Where Ballot SMC05 Stands Today

Ballot SMC05 is no longer a proposal. The CA/B Forum’s S/MIME Certificate Working Group adopted it on February 20, 2024, and CAA checking became mandatory for every publicly trusted S/MIME certificate authority on March 15, 2025. Checking CAA remains optional for the domain owner in the sense that publishing an issuemail record is voluntary, but a public CA is now required to check for one before issuing a certificate. A domain with no issuemail record still permits any publicly trusted CA to issue an S/MIME certificate for it, which is exactly the scenario most enterprises have not yet addressed.

Why This Matters for Enterprise Certificate Lifecycle Management

CAA for S/MIME adds a new, checkable control point to certificate lifecycle management, but only if an organization actually publishes and monitors its issuemail records. Without one, an unmanaged or compromised process anywhere, an old mail gateway, a forgotten subdomain, a third party with residual access, can request and receive a valid S/MIME certificate for your email domain, and it will not show up in a certificate inventory built only around TLS.

The Risk of Manual Handling and How Automation Reduces Outage Risk

Handling CAA and S/MIME governance manually raises three specific risks: missing or misconfigured issuemail records that leave a domain open to unauthorized issuance, delayed detection when an out-of-policy certificate is issued, and certificates that expire unnoticed because no automated system tracked them. Each of these compounds as the number of domains, business units, and mail systems grows, which is precisely when a spreadsheet-based process starts to fail.

Automated certificate lifecycle management addresses this by continuously discovering certificates across every managed domain, enforcing the issuemail policy consistently, and alerting the right team before a misconfiguration or an approaching expiration turns into an outage. Instead of depending on someone remembering to check a DNS record during a quarterly audit, automation applies the policy and the renewal cadence every time, for every certificate.

How This Connects to 47-Day TLS Certificate Readiness

CAA for S/MIME did not arrive in isolation. The CA/B Forum passed Ballot SC-081v3 on April 14, 2025, setting a phased reduction in maximum public TLS certificate validity: 200 days starting March 15, 2026, 100 days starting March 15, 2027, and 47 days starting March 15, 2029. Sectigo, which sponsored the ballot, has noted that the move to 200 day certificates alone roughly doubles the renewal workload for IT and security teams compared with the current 398 day term.

Both changes point in the same direction: shorter validity periods and stronger automated verification across every certificate type a CA issues. An organization that builds automated CAA checking and issuance monitoring for S/MIME now is building the same muscle it will need to survive the 47 day TLS schedule. Treating the two as separate projects duplicates work on the same underlying PKI infrastructure.

Handling CAA for S/MIME in Multi-Cloud and Hybrid PKI Environments

Multi-cloud and hybrid PKI environments make issuemail governance harder because DNS zones, mail infrastructure, and certificate issuance often sit under different teams or cloud accounts. An issuemail record set correctly in one zone does not help if a subdomain managed by a different business unit or cloud provider has no record at all. The practical approach is to centralize visibility: inventory every DNS zone capable of receiving mail, confirm each has a correctly scoped issuemail record naming only the CAs your organization actually uses, and monitor certificate transparency logs for any S/MIME certificate issued outside that list. A single certificate lifecycle management platform that spans on premises, cloud, and hybrid PKI gives one point of policy enforcement instead of a separate, inconsistent configuration in every environment.

Decision Checklist: Matching Your S/MIME Use Case to the Right Action

Use case	Recommendation	Operational owner	Expected outcome
Domain actively issues S/MIME certificates	Publish an issuemail record naming only your approved CAs	PKI team	Only authorized CAs can issue certificates for the domain
Domain never issues S/MIME certificates	Publish an issuemail record with no authorized CAs to block issuance outright	PKI team	Unauthorized S/MIME issuance for the domain becomes impossible
Multiple business units share a parent domain	Audit every subdomain individually rather than relying on the parent record	Security team	No subdomain is left unintentionally open to issuance
Certificates currently tracked manually	Move to automated certificate lifecycle management with CAA policy enforcement	Platform team	Reduced risk of expired certificates and undetected unauthorized issuance
Upcoming compliance audit	Document issuemail configuration and CA authorization list as audit evidence	Compliance team	Certificate governance controls are demonstrable on request

Who Owns What: Action Matrix for PKI, Security, Platform, and Compliance Teams

Team	Immediate action	Why it matters
PKI team	Configure and maintain issuemail DNS records for every domain	This is the control that actually restricts who can issue S/MIME certificates
Security team	Monitor certificate transparency logs for out-of-policy S/MIME issuance	Detects unauthorized certificates that bypass or predate the issuemail policy
Platform team	Deploy automated certificate lifecycle tooling across on-premises, cloud, and hybrid environments	Removes dependence on manual tracking as certificate volume and validity periods shrink
Compliance team	Map issuemail and CAA controls to existing certificate governance and audit requirements	Provides documented evidence that certificate issuance is authorized and controlled

Metrics to Track After Implementation

• Percentage of domains with a correctly configured issuemail record
• Number of S/MIME certificates issued outside the approved CA list
• Mean time to detect unauthorized or out-of-policy certificate issuance
• Certificate renewal completion rate before expiration
• Certificate-related incidents or downtime reported per quarter

How Encryption Consulting Can Help

Most organizations we work with have solid TLS certificate governance and a much thinner picture of S/MIME. CertSecure Manager extends the same automated discovery, policy enforcement, and renewal workflows to S/MIME certificates, so issuemail configuration, CA authorization, and expiration tracking sit in one platform instead of a separate manual process. It flags certificates issued outside your approved CA list and gives PKI, security, and compliance teams a shared, audit ready view of every certificate in the environment.

Because CAA governance, the 47 day TLS schedule, and post-quantum migration all draw on the same underlying cryptographic inventory, it is worth planning them together rather than one control at a time. Our CBOM Secure platform builds that inventory across certificates, keys, and algorithms, and our PQC Center of Excellence helps teams sequence certificate automation, crypto agility, and PQC readiness work as a coordinated program instead of three competing initiatives. If you are still building that inventory, our blog on turning cryptographic inventory into intelligence covers how to prioritize what to fix first.

Conclusion

Frequently Asked Questions

What is the main takeaway from Raising the Bar: The CA/B Forum’s Move to Extend CAA to S/MIME?

CAA checks are no longer optional for S/MIME issuance. Since March 15, 2025, Ballot SMC05 has required every publicly trusted certificate authority to check a domain’s issuemail DNS record under RFC 9495 before issuing an S/MIME certificate. Enterprises that have not configured an issuemail record still have unrestricted issuance for their email domains, which is a governance gap worth closing now.

Why does this matter for enterprise certificate lifecycle management?

CAA for S/MIME adds a new control point to certificate lifecycle management. Without an issuemail record, any publicly trusted CA can issue an S/MIME certificate for your domain without your knowledge, creating shadow certificates that fall outside inventory and audit scope. Extending automated discovery and policy enforcement to cover S/MIME closes that blind spot alongside existing TLS controls.

What teams are responsible for acting on this guidance?

PKI teams typically own the issuemail DNS record configuration and CA authorization list. Security teams validate that only approved CAs are listed and monitor for unauthorized issuance attempts. Platform teams implement automated certificate lifecycle tooling. Compliance teams confirm the control satisfies audit requirements under frameworks such as DORA, PCI DSS, and internal certificate governance policy.

What risks increase if this topic is handled manually?

Manual CAA and S/MIME management increases the chance of misconfigured or missing issuemail records, unauthorized certificate issuance, and delayed detection of shadow certificates. DigiCert’s July 2025 Trust Pulse Survey found 45% of organizations experienced certificate-related downtime in the past year, with 37.5% tracing outages directly to expired certificates managed through manual, fragmented processes.

How does automation reduce certificate outage risk?

Automated certificate lifecycle management continuously discovers certificates, tracks expiration and issuance policy across every domain, and alerts teams before a misconfiguration or an expiring certificate causes an outage. Instead of relying on someone remembering to check a DNS record or a renewal date, automation enforces the issuemail policy and renewal cadence consistently across every certificate the organization issues.

What metrics should teams track after implementation?

Track the percentage of domains with a correctly configured issuemail record, the number of S/MIME certificates issued outside the approved CA list, mean time to detect unauthorized issuance, certificate renewal completion rate before expiration, and the volume of certificate-related incidents or downtime reported quarter over quarter.

How does this connect to 47-day TLS certificate readiness?

Both changes come from the same CA/B Forum direction toward shorter validity periods and stronger automated verification. TLS certificate lifespans are dropping to 200 days in March 2026, 100 days in March 2027, and 47 days by March 2029. Organizations already automating CAA checks and certificate issuance for S/MIME are better positioned to handle the same shift for TLS.

How should this be handled in multi-cloud or hybrid PKI environments?

In multi-cloud or hybrid PKI environments, issuemail records must be consistent across every DNS zone that can issue email certificates, including subdomains managed by different cloud providers or business units. Centralized certificate lifecycle management gives one point of visibility across all environments, so a policy set once applies everywhere rather than being configured separately in each cloud console.