Il record CAA per email: serve davvero? Spiegato bene

Il record DNS CAA (Certification Authority Authorization, RFC 8659) è uno dei record meno conosciuti dell'ecosistema DNS, eppure dal 2017 è obbligatorio per ogni Certificate Authority verificarlo prima di emettere un certificato. La maggior parte degli amministratori conosce CAA solo nel contesto HTTPS: dichiari quale CA può emettere certificati TLS per il tuo dominio, e nessun'altra può farlo legittimamente. Ma il record CAA ha tre property type, e una in particolare — smimeemail — riguarda direttamente l'email. In questo articolo spieghiamo cosa è CAA, come si applica al mondo email (S/MIME, MTA-STS), quando configurarlo e gli errori da evitare.

Cosa fa il record CAA

Quando una Certificate Authority riceve una richiesta di emissione per un dominio, prima di rilasciare il certificato è tenuta a interrogare il DNS per i record CAA del dominio (e di tutti i suoi parent fino alla root). Se i record CAA esistono e non includono la CA richiedente, la CA deve rifiutare l'emissione.

Esempio: il dominio targetsmtp.it ha:

targetsmtp.it. 3600 IN CAA 0 issue "letsencrypt.org"
targetsmtp.it. 3600 IN CAA 0 issuewild "letsencrypt.org"
targetsmtp.it. 3600 IN CAA 0 iodef "mailto:security@targetsmtp.it"

Questo dice: solo Let's Encrypt può emettere certificati (incluso wildcard) per questo dominio; in caso di tentativi non autorizzati, notifica via email security@targetsmtp.it.

Anatomia del record

Sintassi generale: CAA <flags> <property> <value>

• flags: 0 o 128. 128 = critical (la CA deve rifiutare se non comprende la property)
• property: issue (cert generico), issuewild (wildcard), iodef (incident reporting), issuemail o smimeemail (S/MIME, RFC 8657)
• value: stringa quotata. Per issue/issuewild è il nome della CA; per iodef è un URI

Property type rilevanti

CAA e MTA-STS: caso pratico

Se hai implementato MTA-STS (vedi articolo dedicato), il subdomain mta-sts.tuodominio.it richiede un certificato TLS valido emesso da una CA pubblica. CAA controlla anche l'emissione per i subdomain, ereditando dal parent in mancanza di record specifici. Per evitare problemi:

targetsmtp.it. 3600 IN CAA 0 issue "letsencrypt.org"
mta-sts.targetsmtp.it. 3600 IN CAA 0 issue "letsencrypt.org"

Il secondo record è ridondante (eredita dal parent) ma utile come documentazione esplicita e per casi di delegation DNS.

⚠️ Attenzione: aggiungere un CAA che non include la CA che attualmente emette i tuoi cert blocca il prossimo rinnovo. Prima di pubblicare CAA controlla con quale CA stai rinnovando (Let's Encrypt? Sectigo? Google Trust Services?). Per Let's Encrypt il valore corretto è letsencrypt.org, NON letsencrypt.com.

CAA per S/MIME

RFC 8657 (del 2019) estende CAA con la property smimeemail per controllare l'emissione di certificati S/MIME (firma e cifratura email). Esempio:

targetsmtp.it. 3600 IN CAA 0 smimeemail "sectigo.com"

Significa: solo Sectigo può emettere certificati S/MIME per indirizzi @targetsmtp.it. Adozione attuale (2026): limitata. Le CA major (DigiCert, Sectigo, GlobalSign) verificano CAA per S/MIME, ma molte CA minori e gestori CA aziendali no. Configurarlo è comunque buona pratica difensiva: protegge contro emissioni rogue se in futuro più CA adotteranno la verifica.

iodef: ricevere alert

Il property iodef dice alla CA dove segnalare richieste di emissione rifiutate o sospette. Valore: URI mailto o HTTP. Esempio:

targetsmtp.it. 3600 IN CAA 0 iodef "mailto:security@targetsmtp.it"

In pratica solo alcune CA inviano effettivamente questi report (Let's Encrypt non lo fa, Sectigo sì in casi specifici). Configurarlo non costa nulla e in caso di attacco mirato può darti early warning.

CAA, account binding e dichiarazione esatta

RFC 8657 ha aggiunto anche il concetto di "account binding": puoi specificare che solo un account specifico presso una CA può emettere, non chiunque sull'intera CA. Esempio Let's Encrypt:

targetsmtp.it. 3600 IN CAA 0 issue "letsencrypt.org;accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/123456789"

Solo l'account ACME numero 123456789 può richiedere certificati per questo dominio. Utilissimo in scenari multi-tenant: se un altro cliente del tuo provider hosting prova a registrare il tuo dominio per emettere cert, fallisce.

Come testare

Da terminale:

dig CAA targetsmtp.it +short
# Output atteso:
# 0 issue "letsencrypt.org"
# 0 issuewild "letsencrypt.org"
# 0 iodef "mailto:security@targetsmtp.it"

# Test con kdig (più informativo)
kdig +trace CAA targetsmtp.it

Tool online:

• SSLMate CAA Record Helper (generatore guidato)
• CAATest UK
• DigiCert CAA Tester

Errori comuni

1. Stringa CA sbagliata: ogni CA pubblica il proprio identifier. Let's Encrypt è letsencrypt.org (non letsencrypt.com, non letsencrypt). DigiCert è digicert.com. Sectigo è sectigo.com (non comodoca.com più dal 2020)
2. Dimenticare issuewild: pubblicare solo issue blocca i wildcard. Se usi wildcard aggiungi issuewild esplicito
3. Flag 128 quando non serve: il flag critical (128) blocca CA che non capiscono la property. Usalo solo per property non-standard, mai per issue/issuewild
4. CAA su CNAME: il record CAA segue regole speciali quando un nome ha CNAME (RFC 8659 §3). In dubbio, pubblica CAA sul nome target del CNAME, non sull'alias
5. TTL troppo lungo: tieni TTL su CAA a 3600-7200 secondi. Se devi cambiare CA, vuoi propagazione rapida

💡 Suggerimento: prima di pubblicare CAA fai un audit delle CA in uso. Apri /etc/letsencrypt/live/*/cert.pem e openssl x509 -in cert.pem -noout -issuer; controlla la CA per ogni cert attivo. Pubblica CAA che include tutte le CA in uso simultaneamente, non solo quella preferita.

Caso d'uso: scenario tipico provider email

Per un dominio che invia email e ha sia MTA-STS sia (opzionalmente) S/MIME, una configurazione completa è:

targetsmtp.it. 3600 IN CAA 0 issue "letsencrypt.org"
targetsmtp.it. 3600 IN CAA 0 issuewild "letsencrypt.org"
targetsmtp.it. 3600 IN CAA 0 issuemail "sectigo.com"
targetsmtp.it. 3600 IN CAA 0 iodef "mailto:security@targetsmtp.it"

Una linea per ogni autorizzazione esplicita. Aggiungere issuemail non è strettamente necessario oggi se non firmi S/MIME, ma costa nulla e prepara per il futuro.

Limiti di CAA

• Non previene CA compromesse: se una CA emette un cert ignorando CAA (malfunzionamento, attacco), CAA non lo blocca. È un controllo cooperativo, non un firewall
• Non si applica retroattivamente: cert già emessi prima della pubblicazione CAA restano validi
• Non rimuove cert in Certificate Transparency: i log CT mostrano tutti i cert emessi storicamente
• Performance DNS: ogni emissione cert genera lookup CAA extra. Su domini con DNS lento può rallentare leggermente i rinnovi automatici

Riferimenti

• RFC 8659 — DNS CAA Resource Record
• RFC 8657 — Account URI and ACME Method Binding for CAA
• Let's Encrypt CAA docs
• Certificate Transparency log search

Il record CAA è una di quelle voci DNS che richiedono 10 minuti di lavoro una volta sola e ti danno un livello di hardening permanente. Non sostituisce nulla — non SPF, non DKIM, non MTA-STS — ma chiude una superficie d'attacco specifica (emissione rogue di certificati) che altrimenti resterebbe aperta. Target SMTP configura automaticamente CAA con account binding ACME per tutti i domini provisionati per i propri clienti, includendo sia issue per i cert TLS sia issuemail dove applicabile.