CAA Records for Email: Does It Actually Matter? Explained Clearly

CAA (Certificate Authority Authorization, RFC 8659) is one of those DNS records most teams have heard of, mentioned once during a TLS configuration review, and then never touched again. They imagine CAA is about HTTPS websites. It is — but also about every TLS-protected service you run, including SMTP, MTA-STS endpoints, IMAP, submission and even DKIM key rotation.

This article walks through what CAA does in plain terms, why it matters for email infrastructure specifically, and exactly how to deploy it without locking yourself out of certificate renewal.

What CAA Actually Does

A CAA record tells public certificate authorities: "you are (or are not) authorised to issue certificates for this domain." Authorised CAs check the record before issuing. If their identifier is not in the list, they must refuse — even if the requester proves domain control through DNS or HTTP challenge.

example.com.  IN CAA 0 issue "letsencrypt.org"
example.com.  IN CAA 0 issue "sectigo.com"
example.com.  IN CAA 0 iodef "mailto:security@example.com"

The three fields are flag, tag and value. Flag 0 means "if you do not understand this record, ignore it". The tags are:

• issue: allowed CA for any cert
• issuewild: allowed CA for wildcard certs specifically
• iodef: where to send incident notifications

Why CAA Matters for Email

Every modern email subsystem uses TLS:

• SMTP submission (port 587/465) needs a cert for your submission hostname.
• IMAP/POP3 endpoints need certs.
• MTA-STS policy file requires a cert on mta-sts.example.com.
• DKIM key rotation services often need API access to a TLS-protected endpoint.
• Webhook receivers for bounce notifications run on HTTPS.

If an attacker manages to issue a certificate for any of those hostnames from a CA you do not normally use, they can perform a man-in-the-middle attack on your email infrastructure. CAA is the only public mechanism that prevents this.

The Real Threat Model

The threat is not random hackers — issuing a certificate still requires proving domain control. The threat is:

1. A misconfigured employee or vendor accidentally issuing a cert from an unusual CA, breaking your monitoring.
2. A compromised registrar or DNS provider issuing certs from an unexpected CA before you notice.
3. An advanced attacker who has compromised one DNS path but not the others, exploiting CA validation behaviour.

All three scenarios are rare. CAA still pays off because the cost of deploying it is minutes and the upside is bounded blast radius.

The Right CAA Configuration for Email

For a typical email-heavy domain, here is a complete CAA setup:

example.com.        IN CAA 0 issue "letsencrypt.org"
example.com.        IN CAA 0 issue "sectigo.com"
example.com.        IN CAA 0 issuewild ";"
example.com.        IN CAA 0 iodef "mailto:security@example.com"

What this says:

• Only Let's Encrypt and Sectigo may issue certs.
• No CA may issue wildcard certs (we use specific names instead).
• Any unauthorised issuance attempt should be reported to security@example.com.

💡 Tip: List two CAs even if you only use one. The day Let's Encrypt has an outage and you need an emergency cert, you do not want to also be editing DNS to add a fallback CA.

The Common Mistakes

Forgetting Subdomain Coverage

CAA records on example.com also apply to mta-sts.example.com unless you publish a separate record on the subdomain. If you have weird requirements per subdomain (e.g. a vendor that only supports DigiCert on your CRM subdomain), publish a record specifically on that subdomain.

Forgetting iodef

The iodef entry tells CAs where to email if someone tries (and fails) to issue an unauthorised cert. Without it, you never learn about the attempt. With it, you get a paper trail.

Issuewild Confusion

Wildcard certs are subject to issuewild if present, otherwise issue. If you want to forbid wildcards entirely, use issuewild ";" (semicolon meaning "no one").

Stale Records After Migration

You migrate from Sectigo to Let's Encrypt and forget to remove the Sectigo entry. Two years later a stale automation tries to renew via Sectigo, succeeds, and your old monitoring fails to detect it. Audit CAA records every cert rotation.

Validation

dig +short CAA example.com
# 0 issue "letsencrypt.org"
# 0 issue "sectigo.com"
# 0 iodef "mailto:security@example.com"

You can also check via https://crt.sh/?caa=example.com or the Let's Encrypt CAA tester.

Interaction with ACME

When you use ACME (Let's Encrypt, ZeroSSL, etc.), the client performs the validation. The CA itself checks CAA at the time of issuance. So if you suddenly remove letsencrypt.org from CAA, the very next certbot renewal fails. Always update CAA first, wait for DNS propagation (5-10 minutes), then test renewal.

⚠️ Warning: If you use DNS-01 challenge, CAA is checked for both the target domain and any CNAME pointers used for delegation. A broken CAA on the delegation chain looks like a "challenge failed" error.

CAA and Internal CAs

If you run an internal CA (e.g. for client certificate auth on a private SMTP), CAA does not affect it — CAA only constrains public CAs. You can still publish CAA for your public-facing hostnames safely.

Cost-Benefit Verdict

CAA takes 15 minutes to deploy and zero ongoing maintenance once your CA list is stable. It prevents an entire class of certificate misissuance attacks. There is no reason not to deploy it. The only mistake to avoid is being too restrictive: if you only list one CA and that CA has an outage, you cannot get an emergency cert.

Why It Belongs Next to MTA-STS

MTA-STS pins your mail to a TLS-secured channel. If an attacker can issue a cert from an unexpected CA they could spoof your MTA-STS endpoint and break the chain. CAA closes that door.

Target SMTP automatically suggests CAA records for every domain provisioned in the platform and verifies them at the DNS level alongside SPF, DKIM, DMARC, MTA-STS and TLS-RPT. The Send-Time Firewall reads the verification status and can refuse to start mail flow when transport-layer protections are misconfigured — catching the kind of silent misconfiguration that surfaces months later as a deliverability incident.