Configurare SPF, DKIM e DMARC in AWS Route 53

AWS Route 53 è un servizio veloce e affidabile su cui pubblicare i tre record DNS che autenticano le tue email (SPF, DKIM e DMARC), ma la sua console ha un paio di convenzioni che creano spesso confusione: nomi di record completi (fully-qualified) e virgolette doppie obbligatorie attorno a ogni valore TXT. I record sono identici a quelli che pubblicheresti con qualsiasi altro provider DNS; cambia solo l'editor. Questa guida spiega esattamente dove aggiungere ogni record nella console di Route 53, cosa scrivere nel campo del nome del record per il dominio radice, per _dmarc e per il selettore DKIM, e la particolarità delle virgolette che rompe le chiavi DKIM lunghe senza alcun avviso, se non ci fai caso.

In breve#

Tutti e tre i record sono normali record TXT all'interno della tua hosted zone di Route 53. Da un provider all'altro cambiano solo la convenzione sui nomi e il formato di inserimento:

• SPF: un record TXT sulla radice del dominio. In Route 53 lasci vuoto il campo del nome del record e il record si applica alla radice della zona.
• DKIM: un record TXT su <selector>._domainkey.yourdomain.com. Nel campo del nome del record scrivi solo la parte <selector>._domainkey; il selettore e il lungo valore della chiave arrivano entrambi dal tuo provider di posta.
• DMARC: un record TXT su _dmarc.yourdomain.com. Nel campo del nome del record scrivi _dmarc e Route 53 aggiunge la zona per te.

I valori dipendono dal provider, quindi non scriverli a mano. Genera la riga SPF con il generatore di record SPF, la riga della policy con il generatore di record DMARC e copia la chiave DKIM direttamente dalla dashboard della tua piattaforma email. Per i concetti alla base di ogni record, SPF, DKIM e DMARC spiegati illustra cosa fanno e perché contano.

Come SPF, DKIM e DMARC diventano record di Route 53#

Route 53 organizza il DNS attorno a una hosted zone: una zona per dominio. In una zona, ogni record ha un nome completo relativo alla radice della zona, e la console lo rende esplicito: accanto alla casella "Record name" mostra il suffisso del tuo dominio e ciò che scrivi viene anteposto a quel suffisso. Questo solo dettaglio spiega dove vanno tutti e tre i record.

Dove aggiungere i record nella console di Route 53#

Il percorso è lo stesso per tutti e tre i record. Apri la console di Route 53, scegli Hosted zones nella navigazione a sinistra e fai clic sulla zona del dominio da cui invii le email. Fai clic su Create record e, se la console offre la scelta tra "Quick create" e "Wizard", Quick create è la strada più semplice per una singola voce TXT.

Nel modulo di creazione del record imposti tre cose: Record name (il prefisso, secondo la tabella qui sopra), Record type (TXT per tutti e tre) e Value. Lascia la policy di routing sul valore predefinito "Simple routing": sono semplici record informativi, non instradamento del traffico. Il TTL può restare sul valore predefinito (300 o 3.600 secondi vanno bene); un TTL più breve significa solo che le modifiche si propagano più in fretta mentre fai le prove.

Pubblicare il record SPF sul dominio radice#

SPF stabilisce quali server possono inviare email usando il tuo dominio. Crea un record TXT, lascia vuoto il nome del record in modo che finisca sul dominio radice e incolla il valore SPF. Un valore tipico ha questo aspetto:

"v=spf1 include:amazonses.com include:_spf.google.com ~all"

Nota le virgolette doppie che racchiudono il valore: Route 53 si aspetta che i valori TXT siano tra virgolette e la console di solito le aggiunge se te ne dimentichi, ma è più pulito inserirle tu. Il ~all finale è un soft fail; -all è un hard fail che chiede ai server riceventi di rifiutare direttamente i mittenti non autorizzati.

Qui contano due regole più di ogni altra cosa. Prima di tutto, pubblica esattamente un record SPF. Se un secondo record TXT sulla radice inizia anch'esso con v=spf1, SPF diventa non valido e ogni controllo fallisce: quindi, se invii già tramite un altro servizio, unisci tutti i meccanismi include: in un'unica riga invece di aggiungere un nuovo record. In secondo luogo, resta entro le 10 ricerche DNS: ogni include: conta e, se superi il limite, ottieni un errore SPF permanente. Il generatore di record SPF crea un'unica riga valida a partire dai provider che usi davvero e ti segnala il limite di ricerche.

Aggiungere il record DKIM sul selettore#

DKIM rende disponibile la parte pubblica di una chiave di firma, così i server riceventi possono verificare che i tuoi messaggi non siano stati falsificati o alterati. Il tuo provider di posta ti fornisce due cose: un selettore (un'etichetta breve come s1, google o una stringa casuale) e il lungo valore della chiave pubblica. Pubblichi quella chiave come record TXT su <selector>._domainkey.

Crea un record TXT, scrivi il selettore più ._domainkey nel campo del nome del record (per esempio s1._domainkey) e incolla il valore che ti ha dato il provider. Il valore ha questo aspetto:

"v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQ..."

Non inventare e non modificare questo valore: copialo alla lettera dalle impostazioni di autenticazione della tua piattaforma email, perché la chiave pubblica deve corrispondere esattamente alla chiave privata che firma. Alcuni provider (tra cui Amazon SES) forniscono tre record DKIM basati su CNAME invece di un singolo record TXT; in questo caso crea tre record CNAME con i nomi e le destinazioni che ti danno, seguendo la stessa regola "scrivi il prefisso, Route 53 aggiunge la zona". Qualunque sia la forma usata dal tuo provider, i valori arrivano da lui, mai da te.

Pubblicare il record DMARC su _dmarc#

DMARC collega SPF e DKIM all'indirizzo "From" visibile, indica ai server riceventi cosa fare con le email che non superano i controlli e ti invia i report. Crea un record TXT, scrivi _dmarc nel campo del nome del record e incolla una policy iniziale:

"v=DMARC1; p=none; rua=mailto:dmarc@example.com"

Parti da p=none. È la modalità di monitoraggio: non cambia nulla nel modo in cui viene gestita la tua posta, ma attiva i report aggregati giornalieri che rendono possibile un'introduzione sicura. Solo dopo che i report confermano che ogni flusso legittimo si autentica con allineamento dovresti inasprire la policy a p=quarantine e poi a p=reject. Pubblicare p=reject il primo giorno è il modo più rapido per mandare nello spam le tue stesse email. Il generatore di record DMARC crea una policy sintatticamente corretta e la guida passo dopo passo all'introduzione di DMARC spiega nel dettaglio la sequenza monitoraggio-applicazione; quando iniziano ad arrivare i report, leggere i report aggregati DMARC spiega come agire di conseguenza. Il monitoraggio check-up del dominio controlla ogni giorno MX, SPF, DKIM, DMARC, MTA-STS e BIMI, quindi un valore incollato che rompe SPF o DMARC viene segnalato via email.

La particolarità delle virgolette che rompe le chiavi DKIM lunghe#

Questo è il dettaglio specifico di Route 53 su cui vale la pena fermarsi, perché l'errore non dà alcun avviso. Una singola stringa TXT del DNS è limitata a 255 caratteri. I valori brevi (la riga SPF, la policy DMARC) stanno comodamente in una sola stringa tra virgolette. Ma una chiave pubblica DKIM a 2048 bit supera i 255 caratteri, quindi non può stare in una singola stringa.

La soluzione di Route 53 è dividere il valore in più stringhe tra virgolette, ciascuna di 255 caratteri al massimo, inserite insieme nello stesso valore del record. I resolver DNS concatenano le stringhe ricomponendo un'unica chiave. Nella casella Value della console appaiono come due stringhe tra virgolette affiancate:

"v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQ...up-to-255-chars"
"...the-remaining-characters-of-the-public-key"

L'insidia: le due stringhe si concatenano in un'unica chiave continua senza spazi tra loro, quindi non aggiungere caratteri nel punto in cui dividi e tieni entrambe le stringhe in un unico valore del record TXT, senza lasciare che diventino due record separati. Se il controllo DKIM fallisce subito dopo la configurazione e la chiave sembra completa, la causa tipica è una divisione errata. Incolla l'intera chiave, lascia che la console o i tuoi strumenti gestiscano la suddivisione quando possono e verifica il risultato invece di darlo per buono.

Gestire i record come codice#

Route 53 è molto apprezzato dai team che gestiscono l'infrastruttura come codice e non sei obbligato a usare la console. La AWS CLI pubblica i record con aws route53 change-resource-record-sets, passando un change batch in JSON che specifica nome, tipo TXT, TTL e valore. In Terraform, ogni record è una risorsa aws_route53_record:

resource "aws_route53_record" "dmarc" {
  zone_id = aws_route53_zone.primary.zone_id
  name    = "_dmarc.example.com"
  type    = "TXT"
  ttl     = 3600
  records = ["v=DMARC1; p=none; rua=mailto:dmarc@example.com"]
}

Valgono le stesse regole: un record SPF sulla radice, il valore DKIM direttamente dal tuo provider, DMARC che parte da p=none. Anche qui si applica il limite di 255 caratteri per stringa: una chiave DKIM lunga va comunque divisa in più stringhe all'interno del valore del record, quindi applica il record e verifica il risultato pubblicato.

Verifica prima di applicare la policy#

Le modifiche DNS in Route 53 si propagano di solito entro un paio di minuti, anche se il TTL e le cache a valle possono allungare i tempi. Quando i record sono attivi, verifica che tutti e tre si risolvano e vengano interpretati correttamente con lo strumento di controllo SPF, DKIM e DMARC: segnala un record SPF mancante o duplicato, una chiave DKIM divisa o incollata male e una policy DMARC con un errore di sintassi, cioè le tre cose che più facilmente vanno storte su Route 53. Solo quando il controllo è tutto verde dovresti iniziare ad alzare la policy DMARC da none verso reject.

Pubblicarli tutti e tre e superare i controlli è ciò che ti permette di soddisfare i requisiti di Google e Yahoo per i mittenti di grandi volumi. Ma ricorda il limite: l'autenticazione dimostra chi sei, non che sei un buon mittente. Un messaggio perfettamente autenticato inviato a una lista piena di indirizzi inattivi finisce comunque nello spam. La guida alla deliverability delle email spiega il lavoro su reputazione e igiene della lista che trasforma un'identità affidabile in un buon posizionamento nella posta in arrivo.

Route 53 rende semplici i tre record una volta che conosci le sue convenzioni su nomi e virgolette, ma l'autenticazione è solo il biglietto d'ingresso per la posta in arrivo. Crea i tuoi record con gli strumenti gratuiti, poi pulisci la lista che c'è dietro con la verifica email gratuita: individua domini inesistenti, errori di battitura e spam trap prima che generino bounce, perché un'identità affidabile conquista il posizionamento solo quando la lista per cui firma è pulita.