Il numero si può ottenere. È solo più difficile da ottenere giusto di quanto sembri, e quasi tutti i modi di sbagliarlo lo fanno crescere — cioè vanno nella direzione che vende allarme.

Partiamo dall’include più diffuso che esista:

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

_spf.google.com   v=spf1 ip4:74.125.0.0/16 ip4:209.85.128.0/17
                  ip6:2001:4860:4864::/56 ip6:2404:6800:4864::/56
                  ip6:2607:f8b0:4864::/56 ip6:2800:3f0:4864::/56
                  ip6:2a00:1450:4864::/56 ip6:2c0f:fb50:4864::/56 ~all

Risolti ad agosto 2026. I fornitori cambiano i propri range senza preavviso: risolvi i tuoi, invece di fidarti di un numero stampato in un articolo — compreso questo.

La metà IPv4 è aritmetica da scuola media. Un /16 sono 2¹⁶ = 65.536 indirizzi, un /17 sono 32.768. In tutto: 98.304 indirizzi abilitati a spedire posta a nome di quel dominio.

Poi c’è la metà IPv6, ed è lì che un conteggio che sembrava facile comincia a mentire. Sei blocchi. Ci torniamo.

E quello era un record semplice: un include, due letterali IPv4, nessun meccanismo dinamico. Ecco i quattro modi in cui il conto sbaglia su tutti gli altri.

Regola 1: ip4: e ip6: non sono tutto il record

Alcuni meccanismi non contengono indirizzi. Contengono istruzioni per trovare degli indirizzi, eseguite nell’istante in cui un messaggio arriva.

_spf.salesforce.com   v=spf1 exists:%{i}._spf.mta.salesforce.com -all

Conta i meccanismi ip4: in quel record: zero. Uno strumento che conta i letterali dirà che quel fornitore non autorizza niente — un numero che non è impreciso, è rovesciato.

Quello che il record dice davvero è questo. exists: costruisce un nome di dominio a partire dall’indirizzo IP che si sta connettendo (%{i} è la macro che lo rappresenta), cerca un record A a quel nome, e autorizza il mittente se ne trova uno (RFC 7208 §5.7). L’autorizzazione è una domanda che si pone un indirizzo alla volta, e la risposta sta in una zona DNS che non hai modo di elencare. Ho provato con un indirizzo di documentazione — 192.0.2.1._spf.mta.salesforce.com risponde NXDOMAIN, quindi quello non è autorizzato — ma per ricostruire l’insieme completo bisognerebbe fare la stessa domanda 4,3 miliardi di volte.

a, mx e ptr hanno la stessa forma: si risolvono al momento della valutazione, contro record che possono cambiare da un messaggio all’altro. (ptr è un caso a parte: la §5.5 di RFC 7208 si intitola letteralmente “ptr” (do not use) e dice che il meccanismo non andrebbe pubblicato. Se ne trovi uno nel tuo record, quello è già un risultato.)

Un conteggio onesto fa quindi due cose insieme: somma i letterali e dichiara i meccanismi che non ha potuto enumerare. Quello che ne esce è un minimo, mai un totale. Un numero che tace sul terzo tipo non è una misura.

Regola 2: IPv4 e IPv6 non si sommano

Torniamo a quei sei blocchi IPv6. Prendiamo un esempio più grosso — l’infrastruttura di invio di Microsoft 365, che pubblica entrambe le famiglie:

spf.protection.outlook.com
  v=spf1 ip4:40.92.0.0/15 ip4:40.107.0.0/16 ip4:52.100.0.0/15
         ip4:52.102.0.0/16 ip4:52.103.0.0/17 ip4:104.47.0.0/17
         ip6:2a01:111:f400::/48 ip6:2a01:111:f403::/49
         ip6:2a01:111:f403:8000::/51 ip6:2a01:111:f403:c000::/51
         ip6:2a01:111:f403:f000::/52 -all

Il lato IPv4 fa 458.752 indirizzi. Adesso il lato IPv6: un singolo /48 contiene 2⁸⁰ indirizzi, e i cinque blocchi insieme fanno circa 2,19 × 10²⁴.

Somma le due metà e ottieni 2,19 × 10²⁴, cioè la stessa cifra di prima. I 458.752 indirizzi IPv4 non sopravvivono all’arrotondamento: sono diciotto ordini di grandezza troppo piccoli per comparire. Un totale unico non è un numero grande, è il numero dell’IPv6 travestito — e per produrlo si è cancellata l’unica parte su cui un sistemista può davvero ragionare.

Quindi: gli IPv4 si contano a indirizzi, gli IPv6 a blocchi, e non si pubblica mai una cifra sola per entrambi. Chi ti dice che il tuo SPF autorizza settantanove miliardi di miliardi di indirizzi ha sommato le due famiglie e ti sta citando la dimensione di IPv6.

Regola 3: i range sovrapposti vanno fusi prima

Qui i trabocchetti sono tre, e tutti e tre gonfiano.

Range scritti separati che sono un range solo. Riguarda il record Microsoft qui sopra. Pubblica sei letterali IPv4, ma 52.100.0.0/15, 52.102.0.0/16 e 52.103.0.0/17 stanno attaccati uno all’altro: insieme sono un’unica corsa ininterrotta da 52.100.0.0 a 52.103.127.255, 229.376 indirizzi. I letterali sono sei, i blocchi contigui sono quattro. Chi dice «sei range» ha contato la punteggiatura, non la superficie.

Lo stesso fornitore contato due volte. Il record di sendgrid.net finisce già con include:ab.sendgrid.net. Un dominio che pubblica entrambi gli include — cosa in cui è facile ritrovarsi seguendo due guide di configurazione a un anno di distanza — eredita quel secondo record lungo tutte e due le strade. Sommando i letterali alla cieca vengono 238.592 indirizzi. Fondendo prima gli intervalli il numero vero è 237.056: la differenza, 1.536, è esattamente il sotto-record contato una seconda volta.

Host-bit che non stanno dove pensi. La §5.6 di RFC 7208 dice che si confrontano solo i bit alti del prefisso, quindi i bit sotto la lunghezza del prefisso, nel letterale pubblicato, sono semplicemente irrilevanti. Il record di _spf-b.microsoft.com contiene ip4:207.46.22.98/29. Non autorizza otto indirizzi a partire da .98: autorizza da 207.46.22.96 a 207.46.22.103, quindi anche .96 e .97, e non .104. Prendi il letterale alla lettera e ogni intervallo ti si sfasa da entrambi i lati — il che manda in pezzi, silenziosamente, la fusione del paragrafo precedente.

Qui in ballo ci sono due cifre diverse, e conviene tenerle separate. I range che stanno soltanto uno accanto all’altro gonfiano il conteggio dei blocchi lasciando corretto il totale degli indirizzi — è il caso Microsoft. Un fornitore ereditato due volte gonfia gli indirizzi stessi — è il caso SendGrid. Gli host-bit letti male rovinano entrambi.

Quello che i tre errori hanno in comune è la direzione. Tutti e tre fanno la cifra più grande: un conteggio che salta la fusione non è approssimativo in modo neutro, è sistematicamente sbilanciato verso l’allarme.

Regola 4: zero e «non lo so» sono numeri diversi

example.com   v=spf1 -all

Quel record autorizza esattamente zero indirizzi, ed è un fatto vero, utile e difendibile: è quello che dovrebbe pubblicare un dominio che non spedisce posta.

Adesso considera un include: che non si è risolto, o un ramo abbandonato perché il record aveva già esaurito i dieci lookup consentiti (RFC 7208 §4.6.4). Gli indirizzi che ci stanno dietro non sono zero. Sono ignoti, e la risposta onesta è una casella vuota, non una cifra.

La distinzione sembra pedanteria finché non guardi da che parte cade l’errore. Scritto 0, un dato ignoto si legge come una buona notizia: il record più permissivo del tuo parco, mostrato come il più stretto. E uno strumento che non sa dirti quando non è riuscito a guardare ha zeri che non valgono niente nemmeno altrove.

La domanda migliore: quanti di quegli indirizzi hanno mai spedito?

La superficie autorizzata è un elenco di permessi, e da sola non dice nulla su che cosa sia effettivamente in uso. La cifra interessante è la sovrapposizione con la realtà, e i report aggregati DMARC forniscono l’altra metà: ogni report elenca le sorgenti che hanno spedito posta a nome del tuo dominio (RFC 9990 §3.1).

Incrocia i due insiemi e ottieni due numeri utili:

• autorizzati ∩ osservati — gli indirizzi che spediscono davvero la tua posta;
• autorizzati − osservati — il peso morto: indirizzi per cui garantisci e che non spediscono un messaggio da mesi.

Il peso morto è quasi sempre archeologia. L’ESP da cui sei migrato e che nessuno ha tolto. Un server di posta dismesso due traslochi fa. Un apparato di monitoraggio che ha smesso di mandare email quando qualcuno ne ha spento gli avvisi. Nessuno di questi si annuncia: l’include: continua a risolversi, il record continua a essere valido, e gli indirizzi continuano a essere autorizzati.

Due discipline rendono onesto quel numero, e contano più dell’aritmetica:

«Nessun report» non è «zero mittenti». Se nella finestra di osservazione non è arrivato niente, non hai imparato nulla sull’uso. Dire a chi ha configurato il reporting la settimana scorsa che nessuno dei suoi 98.304 indirizzi autorizzati spedisce posta sarebbe assurdo, e uno strumento che lo fa sta sottraendo da dati che non ha. L’esito corretto è tacere sull’uso, non esibire un numero grande e preoccupante.

Si contano le sorgenti distinte, non i messaggi. La domanda è quanti indirizzi autorizzati siano vivi, quindi un server che ha spedito un milione di messaggi vale uno. Pesare per volume produce una cifra grossa e senza alcun rapporto con la superficie che dovrebbe descrivere.

Un SPF largo non è, di per sé, un errore

Va detto chiaramente, perché il genere a cui questo articolo appartiene di solito chiude lasciando intendere il contrario.

I 98.304 indirizzi di Google non sono sciatteria. Sono la dimensione di una piattaforma di posta che recapita per moltissime organizzazioni, e qualunque fornitore che operi a quella scala autorizzerà un intervallo paragonabile. Non è successo niente di male.

E quella cifra non è nemmeno un voto. Non esiste una soglia oltre la quale un record diventa cattivo, non c’è un valore di riferimento sotto cui stare, e il numero non va messo dietro un semaforo rosso. È una misura — la stessa categoria del numero di host sulla tua rete: utile da sapere, priva di senso come pagella.

Vale anche la pena essere precisi su che cosa quella superficie esponga. Un indirizzo autorizzato non è una porta aperta: è una macchina per la cui posta il tuo dominio si fa garante. Il rischio che rappresenta è condizionato — conta se una di quelle macchine viene compromessa, o se un range torna al fornitore cloud e viene riaffittato a qualcun altro. È una preoccupazione reale, ed è esattamente il motivo per cui la provenienza conta più della dimensione. Un record che autorizza 98.304 indirizzi di un solo fornitore che usi attivamente sta meglio di uno che ne autorizza 3.000 distribuiti su sei fornitori, quattro dei quali hai smesso di pagare due anni fa.

Che cosa farsene, di quel numero

Togli i fornitori che non usi più. È l’unico intervento sempre giusto, non costa niente e riduce insieme la superficie e il conteggio dei lookup. Non richiede alcuna valutazione: serve solo l’elenco, e qualcuno disposto a dire quali voci sono ancora vere. Comincia dal peso morto.

Dai un sottodominio ai mittenti pesanti. La posta di marketing e quella transazionale spedite da mail.example.com, con un proprio record SPF, tengono piccolo e verificabile a parte il record del dominio aziendale. I range del tuo ESP finiscono così dietro a un nome il cui unico mestiere è la posta massiva, e la compromissione di quella superficie non si porta dietro il peso del tuo dominio principale.

Non ricorrere al flattening. Sostituire include:_spf.google.com con i range letterali in cui si risolve oggi riduce davvero il conteggio dei lookup, ed è il consiglio standard per i record che hanno sbattuto contro il tetto dei dieci. Ma trasforma un riferimento vivo in un’istantanea, e il fornitore continua a cambiare i range alle tue spalle. Quando ne aggiunge uno, la posta che parte da lì comincia a fallire. Quando ne rilascia uno — restituito al pool del cloud, riassegnato a un altro cliente — il tuo record continua ad autorizzare indirizzi che ormai appartengono a un estraneo. È precisamente il rischio che l’espressione «superficie d’attacco» era stata coniata per descrivere, e il flattening lo fabbrica. Merita un articolo a sé, ma la versione breve è che baratta un limite misurabile con un’esposizione che non si vede.

Contare la superficie richiede un pomeriggio e un resolver. Sapere quanta ne sia ancora viva richiede i report DMARC su una finestra abbastanza lunga da intercettare anche i mittenti trimestrali, ed è la metà che nessuna ispezione del record può darti. Sentinely fa entrambe le cose: misura la superficie autorizzata, dichiara le parti che non ha potuto enumerare invece di arrotondarle a zero, e incrocia il risultato con le sorgenti che i tuoi report mostrano davvero — che è dove il peso morto diventa visibile. Se sei arrivato qui per il taglio sicurezza, quel lato sta qui.

Quasi tutti gli elenchi di cause che si trovano in giro sono disordinati, ed è l’unica cosa che un elenco del genere non può permettersi. Le verifiche hanno una sequenza naturale — ognuna dà senso alla successiva — e farle alla rinfusa significa dimostrare due volte la stessa cosa mentre la causa vera aspetta più in basso. Qui sotto c’è la sequenza. Prima ci sono due domande, perché per una buona parte di chi legge la risposta è che non si è rotto niente.

Due domande che possono chiudere la faccenda subito

Sono passate 48 ore?

I report aggregati non vengono emessi man mano che la posta viaggia. Ogni report copre un periodo di rilevazione, e RFC 9990 (§3.1.1.4) dice che quel periodo di norma coincide con una giornata UTC che comincia alle 00:00. La generazione e l’invio avvengono dopo che il periodo si è chiuso.

Quindi: se hai pubblicato martedì alle 16:00, il primo periodo che contiene il tuo record si chiude alle 00:00 UTC di mercoledì, e il report viene costruito e spedito qualche tempo dopo. Ventiquattro-quarantotto ore sono l’attesa normale, e i grandi riceventi si distribuiscono dentro quella finestra.

Due cose la allungano:

• La cache del DNS. Se il nome _dmarc.example.com prima non esisteva, i resolver hanno messo in cache la sua assenza, non solo il suo contenuto. La cache negativa (RFC 2308) dura un tempo che deriva dal record SOA della zona, e un ricevente che ha guardato un’ora prima della tua pubblicazione non tornerà a guardare finché non scade. Controlla il minimum del tuo SOA prima di dare per scontato che qualcosa non funzioni.
• Non puoi chiedere di andare più in fretta. Il tag ri= serviva a chiedere un intervallo di rilevazione più corto. RFC 9989 lo ha rimosso (Appendice C.5.2) e il registro IANA oggi lo classifica come historic. Pubblicare ri=3600 non ottiene niente: è un tag sconosciuto, e i tag sconosciuti vengono ignorati.

Il dominio spedisce davvero posta?

Un ricevente scopre che vuoi i report solo quando interroga la tua policy, e interroga la tua policy solo quando gli è arrivato un messaggio con il tuo dominio nel campo From: (RFC 9990 §3.4).

Niente posta, nessuna interrogazione, nessun report. Se il dominio è parcheggiato, o serve solo un sito web, o l’hai registrato il mese scorso e non ha ancora spedito nulla, il silenzio è l’esito corretto e nessun lavoro sul DNS lo cambierà. Un dominio che manda una manciata di messaggi al giorno è la versione attenuata dello stesso caso: riceverai report solo dai riceventi che hanno visto la tua posta e che gestiscono un programma di reporting, quindi una settimana magra non dimostra che il record sia sbagliato.

Se hai superato entrambe le domande, si scende lungo l’elenco.

Le sei cause, nell’ordine in cui vanno verificate

1. Non c’è nessun record DMARC dove i riceventi lo cercano.
2. Il record c’è, ma i riceventi lo scartano — quasi sempre un punto e virgola mancante.
3. Il record è valido e non ha il tag rua=, oppure ne ha uno inutilizzabile.
4. Il rua= è valido e non è il tuo — i report esistono, e vanno altrove.
5. È troppo presto — se ne è parlato sopra.
6. Stanno arrivando — e il problema è a valle.

Un comando solo risolve le prime quattro:

dig +short TXT _dmarc.example.com

1. Nessun record dove i riceventi lo cercano

La ricerca della policy parte dal nome che si ottiene anteponendo _dmarc al dominio scritto nel campo From: (RFC 9989 §4.10.1). Non l’apice, non www, non un CNAME verso la pagina commerciale del fornitore.

L’errore che genera più confusione lo produce il pannello DNS che aggiunge la zona per conto tuo. Hai scritto _dmarc.example.com nel campo nome, il pannello ha appeso .example.com, e il record adesso vive su _dmarc.example.com.example.com, dove nessuno guarderà mai. Il dig qui sopra non restituisce niente e il pannello continua a mostrarti un record che sembra perfetto. Credi al dig, non al pannello.

Ce n’è una versione più insidiosa. Se la posta parte da un sottodominio — From: noreply@mail.example.com — la ricerca guarda prima _dmarc.mail.example.com, e solo se lì non trova un record valido risale verso il dominio organizzativo (RFC 9989 §4.10). Entrambi gli esiti sono normali. Quello che conta per la tua dashboard vuota è che nel secondo caso il record che si applica è quello del dominio padre, e i report di quella posta vanno al rua del padre. Tienilo da parte se stai monitorando un sottodominio.

2. Il record c’è e i riceventi lo scartano

Tre modi in cui un record pubblicato viene buttato via prima che qualcuno arrivi a leggere il tuo rua:

Più di un record. Se un’interrogazione restituisce più record DMARC per lo stesso nome, vengono scartati tutti (RFC 9989 §4.10). È il classico strascico di un cambio di fornitore: il record vecchio non è mai stato cancellato e quello nuovo gli è stato messo accanto. dig +short li mostra entrambi. Due record corretti sono peggio di uno.

v= non è il primo, o non è esattamente DMARC1. Il tag di versione deve venire per primo, e il suo valore distingue maiuscole e minuscole. Se manca, se non è in testa o se è scritto diversamente, l’intero record va ignorato (RFC 9989 §4.7). v=dmarc1 non è un record DMARC.

Un punto e virgola mancante. Questo merita una sezione a sé, perché è invisibile e per come fallisce.

Un carattere: il punto e virgola mancante

Questi due record differiscono per un solo ;:

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

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

Aperti nel pannello del DNS sono indistinguibili. Il primo non ti porta nessun report, ed ecco il meccanismo, perché non è quello che quasi tutti immaginano.

La grammatica di RFC 9989 §4.8 definisce il valore di un tag come qualunque carattere stampabile tranne il punto e virgola. Lo spazio rientra. Anche = rientra. Un ricevente che analizza il primo record non si ferma allo spazio: legge il valore di p come none rua=mailto:dmarc@example.com.

Adesso sono vere due cose insieme, ed è la seconda quella che fa male:

• p ha un valore che non è none, quarantine né reject, quindi non è valido;
• nel record non c’è più nessun tag rua — è stato inghiottito dentro il valore di p.

RFC 9989 §4.10.1 tratta con indulgenza un p non valido, ma l’indulgenza ha una condizione. Se nel record c’è un tag rua con almeno un URI sintatticamente valido, il ricevente si comporta come se il record dicesse p=none e tira dritto — e il reporting sopravvive. Altrimenti «non applica alcuna elaborazione DMARC al messaggio».

Il punto e virgola mancante cancella esattamente il tag che avrebbe salvato la situazione. È per questo che questo refuso è silenzioso invece che rumoroso: non indebolisce la policy, ti toglie i report.

Lo stesso errore in altra forma, meno frequente, è un record con i tag in ordine sbagliato — p=none; v=DMARC1; rua=… — che cade sulla regola della versione vista sopra.

E il rovescio rassicurante, così non ci passi un pomeriggio: un frammento estraneo che non sia una coppia tag=valore non è fatale. RFC 9989 §4.8 dice che gli errori di sintassi nel resto del record vengono scartati in favore dei valori di default, oppure ignorati. Sciatto, da ripulire, ma non è il motivo per cui la tua dashboard è vuota.

3. Nessun rua= utilizzabile

Il tag è facoltativo per lo standard, e la sua assenza non lascia margini: senza rua i riceventi non devono generare report aggregati per quel dominio (RFC 9989 §4.7). Un record può essere impeccabile, imporre p=reject, e non dirti niente.

Tre modi in cui il tag c’è ma non serve a nulla:

• Un indirizzo al posto di un URI. rua=dmarc@example.com non è un URI di reporting DMARC: un URI richiede uno schema. Va scritto rua=mailto:dmarc@example.com. È una dimenticanza facile da fare e difficile da vedere, perché a un lettore umano un indirizzo senza schema sembra del tutto ragionevole.
• Solo https:. I riceventi sono obbligati a supportare mailto:; il supporto a qualunque altro schema è facoltativo, e gli URI con schemi non supportati devono essere ignorati (RFC 9989 §4.7). Un rua solo HTTPS è una scommessa, ricevente per ricevente.
• Il vecchio limite di dimensione. Il suffisso !10m oggi è sintassi obsoleta, e chi genera i report è invitato a ignorarlo (RFC 9989 §4.8). Innocuo se c’è già, inutile da aggiungere.

4. Il rua= è valido, e non è il tuo

È la causa che sopravvive a tutte le verifiche precedenti, ed è quella che quasi nessuno va a cercare.

Un validatore di sintassi ti confermerà che rua=mailto:dmarc@reports.fornitore.example è un URI di reporting ben formato, perché lo è. Quello che nessun validatore può sapere è se quell’indirizzo sia tuo. Lo sai solo tu. Così il record supera ogni controllo, lo strumento che stai pagando resta vuoto, e da nessuna parte compare un errore — perché dal punto di vista del protocollo non c’è niente che non va. I report vengono generati, puntuali, tutti i giorni. Vanno da un’altra parte.

Da dove arriva, di solito, quell’altro indirizzo:

• un fornitore DMARC precedente, dopo la scadenza dell’abbonamento — disdire un contratto non modifica il tuo DNS;
• l’agenzia o l’MSP che ha configurato il dominio anni fa, che puntava al proprio account di aggregazione;
• una casella interna su un sistema di posta che nel frattempo è stato dismesso.

La verifica consiste nel leggere l’elenco con i propri occhi, invece di fidarsi di una spunta verde. Lancia il dig di prima e leggi il valore di rua= per quello che è: una lista di destinazioni separate da virgola. Su ogni voce fatti una domanda sola: chi riceve posta a quell’indirizzo, oggi? Se per una non sai rispondere, l’hai trovata.

Due cose da sapere prima di mettere mano al record:

Essere uno fra tanti è del tutto normale, quindi la correzione di solito è aggiungere, non sostituire. Ogni destinazione valida dell’elenco riceve la propria copia; non esiste un destinatario principale. Se stai passando da uno strumento a un altro, tienili accesi entrambi per una settimana e confronta, poi togli il vecchio.

Se stai monitorando un sottodominio, controlla anche il padre. Per la risalita descritta nella causa 1, la posta che parte da un sottodominio privo di un proprio record _dmarc ricade sotto il record del dominio organizzativo — quindi i suoi report arrivano al rua del padre mentre la dashboard del sottodominio resta vuota. Non c’è niente di sbagliato nella configurazione: stai guardando lo scaffale sbagliato.

Due cause che non stanno nel record

La destinazione è su un altro dominio e non ha acconsentito

Se l’indirizzo rua sta sotto un dominio organizzativo diverso da quello che pubblica la policy, i riceventi devono prima accertarsi che la destinazione sia d’accordo (RFC 9990 §4). Il motivo è evidente appena lo si dice: senza quel controllo chiunque potrebbe pubblicare un record che dirotta una valanga di report su una vittima.

La verifica è un’interrogazione DNS che fa il ricevente. Prende l’host dal tuo URI rua, gli antepone _report._dmarc, e antepone ancora il dominio da cui è arrivata la policy. Quindi una policy su example.com che chiede rua=mailto:dmarc@reports.example.net produce una richiesta TXT per

example.com._report._dmarc.reports.example.net

e la risposta deve leggersi come un record DMARC con v=DMARC1 in testa. Se quel record non c’è, l’URI deve essere ignorato dal ricevente che sta generando il report (RFC 9990 §4). Di nuovo silenzio, senza che si sia rotto niente in nessuno dei posti in cui ti verrebbe da guardare.

Tre conseguenze pratiche:

• Il record va nella zona della destinazione, non nella tua. Se i report vanno a un servizio di terze parti, tocca a loro pubblicarlo, e la maggior parte usa una wildcard — *._report._dmarc.<loro dominio> — che copre tutti i clienti in un colpo solo. Se invece i report vanno a una casella su un secondo dominio tuo, nessuno lo pubblicherà al posto tuo.
• Stesso dominio organizzativo, nessuna verifica. Una policy su _dmarc.mail.example.com che spedisce a dmarc@example.com non attiva affatto questo controllo.
• L’ultima parola ce l’ha la destinazione. Il record di consenso può a sua volta contenere un rua, che sovrascrive quello della tua policy, vincolato allo stesso host (RFC 9990 §4). È raro, ma è un altro modo legittimo in cui i report finiscono dove non hai deciso tu.

È la casella che se li mangia

Un report è una normalissima email con un allegato: un file XML che dovrebbe essere compresso con gzip, trasportato come application/gzip oppure text/xml, con un nome costruito nella forma ricevente!dominio-policy!timestamp-inizio!timestamp-fine.xml.gz (RFC 9990 §3.5.2).

L’oggetto è fissato dallo standard, e questo ti dà una cosa da cercare:

Subject: Report Domain: example.com
    Submitter: mx.example.net
    Report-ID: 1755820800-example.com@example.net

Cerca Report Domain: in tutta la casella — spam, quarantena e archivio compresi. Se saltano fuori dei messaggi, tutto quello che c’è scritto sopra è a posto e il problema è a valle. Se non salta fuori niente da nessuna parte, le cause precedenti sono ancora in gioco.

Che cosa se li mangia, grosso modo in ordine di frequenza: le policy sugli allegati che bloccano o rimuovono i file compressi; una regola che li archivia in una cartella che nessuno apre; una casella condivisa la cui quarantena non guarda nessuno; e un indirizzo rua che in realtà non accetta posta, il che produce bounce che tu non vedi mai, perché tornano al ricevente e non a te.

Un dettaglio che ti risparmia una discussione con chi gestisce la posta: il traffico dei report è a sua volta autenticato con DMARC — RFC 9990 §3.5.2 richiede che questi flussi producano un pass allineato. Quando i report finiscono in quarantena si tratta di una scelta del filtro locale, non di un problema di autenticazione.

Arrivano, e la dashboard è comunque vuota

Se i messaggi li hai trovati, quello che resta sta tutto a valle della consegna.

Stai guardando il dominio sbagliato. Viene generato un report distinto per ogni dominio della policy incontrato nel periodo (RFC 9990 §3.1). Apri uno degli XML e leggi policy_published/domain: è lo scaffale su cui quei dati sono stati archiviati. Se dice example.com e tu stai guardando mail.example.com, torna alla causa 4.

I duplicati sono stati tolti, ed è giusto così. Quando chi genera un report lo rispedisce deve riutilizzare il nome di file originale, e il Report-ID esiste proprio perché chi lo riceve possa riconoscere e ignorare i duplicati (RFC 9990 §3.5.2). Un report arrivato due volte che compare una volta sola è il sistema che funziona.

L’importazione ha una sua cadenza. I report vengono raccolti e analizzati a lotti, non nell’istante in cui atterrano. Se il primo è arrivato venti minuti fa, dagli un’ora prima di aprire una segnalazione.

Mentre aspetti il primo report non sei costretto ad aspettare per sapere qualcosa. Un report riassume una giornata di posta; le intestazioni di un singolo messaggio ti dicono che cosa ha concluso un ricevente su quel messaggio, adesso. Se puoi mandarti un messaggio di prova, incolla le sue intestazioni nel nostro analizzatore di intestazioni email: legge le dichiarazioni di chi ha ricevuto, non richiede alcun account e non conserva niente.

E quando i report cominceranno ad arrivare, la cosa da tenere d’occhio non è solo che il record continui a essere leggibile, ma che il suo rua continui a nominare te. È il controllo che Sentinely fa in continuo, ed è la differenza fra accorgersene oggi e accorgersene al prossimo audit.

Quasi certamente no. Quello che hai davanti è la parola fail usata per due cose diverse, e gli strumenti che ti mostrano un unico “tasso di fallimento” di solito le fondono. Una delle due significa che un messaggio è stato bloccato. L’altra significa che un messaggio è stato consegnato regolarmente, da un destinatario che ne era perfettamente soddisfatto. Distinguerle richiede circa un minuto per riga, e il resto di questo articolo è quel minuto.

Due cose diverse che si chiamano “fail”

Un report DMARC aggregato (il formato è specificato in RFC 9990) non è un elenco di messaggi. È un elenco di gruppi: ogni <record> copre un lotto di messaggi arrivati dallo stesso IP sorgente con lo stesso esito di autenticazione, e <count> dice quanti messaggi rappresenta quel lotto. Qualunque percentuale tu veda, da qualunque parte, è pesata su quel numero.

Dentro ogni record ci sono tre livelli, e rispondono a tre domande diverse.

<record>
  <row>
    <source_ip>203.0.113.47</source_ip>
    <count>128</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>pass</dkim>
      <spf>fail</spf>
    </policy_evaluated>
  </row>
  <identifiers>
    <header_from>example.com</header_from>
  </identifiers>
  <auth_results>
    <dkim>
      <domain>example.com</domain>
      <selector>s1</selector>
      <result>pass</result>
    </dkim>
    <spf>
      <domain>fwd.example.net</domain>
      <result>pass</result>
    </spf>
  </auth_results>
</record>

<auth_results> — i protocolli hanno verificato qualcosa? Sono gli esiti grezzi, non interpretati. Qui SPF ha restituito pass, ma guarda per quale dominio è passato: fwd.example.net, non example.com. DKIM ha verificato una firma che porta d=example.com.

<policy_evaluated>/<spf> e /<dkim> — hanno verificato e combaciano con il dominio del From:? Questa è la vista di DMARC, e ha solo due valori: pass o fail. SPF ha verificato per il dominio di qualcun altro, quindi dal punto di vista di DMARC è fail. DKIM ha verificato per il tuo, quindi è pass.

<policy_evaluated>/<disposition> — cosa ha fatto davvero il destinatario? Tre valori: none (consegnato), quarantine, reject.

Il record qui sopra contiene la parola fail, e non è andato storto assolutamente nulla. DMARC passa quando passa almeno uno dei due metodi allineati — la firma DKIM allineata è bastata — quindi il messaggio è stato autenticato, consegnato e corretto. Se la tua dashboard traccia un “tasso di pass SPF” e tu guardi quel numero, questo record ti preoccuperà ogni singolo giorno senza motivo.

La regola

Eccola per intero, e vale la pena tenerla da qualche parte a portata di copia-incolla.

Un gruppo di messaggi in un report aggregato è un fallimento vero se e solo se:

(A) il destinatario l’ha bloccato — disposition è quarantine o reject; oppure

(B) è stato consegnato (disposition è none), la policy in vigore per quel report era p=none, e entrambi gli esiti grezzi in <auth_results> sono esattamente fail.

Tutto il resto appartiene al tuo volume, non ai tuoi fallimenti.

Il caso (A) non richiede interpretazione. Il destinatario ha preso una decisione e te l’ha comunicata. Non importa quali fossero gli esiti grezzi e non importa cosa dica la tua policy: se disposition è quarantine o reject, della tua posta non è arrivata in una casella, e questo merita attenzione tanto se la causa è un attaccante quanto se è un fornitore configurato male.

Il caso (B) è quello che nessuno mette per iscritto. Il messaggio è stato consegnato, entrambi i protocolli hanno fallito del tutto, e l’unico motivo per cui è finito in una casella è che non hai ancora chiesto a nessuno di fermarlo. Quello è spoofing latente: sembra innocuo oggi e diventa un messaggio bloccato il giorno in cui passi all’enforcement.

Nel caso (B) ci sono due dettagli facili da sbagliare.

La policy che conta è quella di quel report, non quella che hai nel DNS oggi. Ogni report porta con sé la policy che il destinatario ha visto, in <policy_published>/<p>, e descrive una finestra che si è già chiusa — di solito il giorno prima. Se hai cambiato il record martedì, i report di lunedì descrivono ancora la policy di lunedì. La p va letta dal report che hai in mano.

Conta solo il valore esatto fail. RFC 9990 ammette in <auth_results> diversi altri valori — none, neutral, policy, temperror, permerror, e per SPF anche softfail — e nessuno di questi dimostra alcunché. Un temperror significa che il destinatario non è riuscito a completare il controllo. Un softfail significa che è stato il tuo stesso record a chiedere indecisione. Trattarli come fallimenti è il modo in cui uno strumento di monitoraggio si inventa problemi che non esistono.

Perché il caso (B) richiede esattamente p=none

È la parte che si salta, e saltandola il significato della riga si capovolge.

Immagina che il tuo dominio sia già a p=quarantine, e che un report mostri un lotto che ha fallito entrambi i metodi ed è stato comunque consegnato, disposition=none. A una lettura ingenua è peggio: lo spoofing è passato lo stesso. È l’opposto. Tu avevi chiesto al destinatario di mettere in quarantena quella posta, e il destinatario ha scelto di non farlo. RFC 9989 è esplicito nel dire che la gestione finale resta sempre una decisione locale di chi riceve: il protocollo esprime una preferenza, non un comando. Un messaggio consegnato su un dominio in enforcement significa quindi che è stata applicata un’eccezione: una allowlist locale, una regola su un inoltratore fidato, oppure — sui record che portano ancora il tag legacy pct, che RFC 9989 ha rimosso — una decisione di campionamento.

Su quel dominio l’enforcement esiste. Il destinatario ha guardato la tua policy e ha fatto un’eccezione. È una situazione diversa da “l’enforcement non c’è ancora”, e non è spoofing latente.

Lo stesso ragionamento copre il terzo caso: se non sai quale policy fosse pubblicata, il caso (B) non si applica affatto. Non puoi concludere “consegnato solo perché mancava l’enforcement” senza sapere se l’enforcement ci fosse.

A volte il destinatario ti dice perché

Quando applica un’eccezione, chi riceve può dirlo. <policy_evaluated> può portare uno o più elementi <reason>, e RFC 9990 ne definisce cinque tipi: local_policy, mailing_list, other, policy_test_mode e trusted_forwarder. Alcuni reporter aggiungono anche un <comment> in testo libero.

<policy_evaluated>
  <disposition>none</disposition>
  <dkim>fail</dkim>
  <spf>fail</spf>
  <reason>
    <type>mailing_list</type>
  </reason>
</policy_evaluated>

È un destinatario che ti dice, dentro il report, di aver riconosciuto una mailing list e di aver deciso di non farti pagare la tua stessa policy. È il campo più utile del formato, ed è opzionale: la maggior parte dei record non lo avrà, ma quando c’è ti risparmia l’indagine. I reporter, inoltre, si muovono più lentamente della specifica: fino al 2026 il riferimento era RFC 7489, il cui elenco di motivi comprendeva anche forwarded e sampled_out, e continuerai a vederli in circolazione.

Le tre spiegazioni ordinarie

La maggior parte del volume allarmante viene da tre situazioni.

Inoltro automatico. Un utente si fa inoltrare la posta altrove, oppure un vecchio alias punta ancora fuori. Il server che inoltra spedisce dal proprio IP, che non è nel tuo record SPF, quindi SPF non è più allineato con il tuo dominio. Se l’inoltratore lascia il messaggio intatto, la firma DKIM sopravvive, DMARC passa su DKIM e il messaggio viene consegnato. Nel report: <spf>fail</spf>, <dkim>pass</dkim>, disposition none. Cosa fare: niente. È esattamente il motivo per cui i metodi di autenticazione sono due.

Mailing list. Una lista aggiunge un prefisso all’oggetto o un piè di pagina, e questo invalida la firma DKIM sul corpo modificato; poi riscrive il mittente di busta con il proprio dominio, e questo sposta SPF lontano dal tuo. Entrambi i metodi falliscono l’allineamento, e il messaggio viene consegnato lo stesso perché chi riceve riconosce lo schema. Nel report: entrambi fail, disposition none, a volte con <reason><type>mailing_list</type>. Cosa fare: niente. Il meccanismo pensato per portare l’autenticazione attraverso questo tipo di riscrittura è ARC (RFC 8617), e implementarlo è compito della lista, non tuo.

Un fornitore che firma con il proprio dominio. La piattaforma di fatturazione, il CRM o lo strumento di newsletter spediscono per tuo conto e firmano con d=fornitore.example, non d=example.com. Guarda <auth_results>: il result di DKIM è pass, ma <domain> è quello del fornitore. Successo grezzo, nessun allineamento, quindi <policy_evaluated>/<dkim> è fail. Qui invece serve agire — non con urgenza, ma sul serio. Chiedi al fornitore la firma DKIM sotto il tuo dominio (quasi sempre un CNAME che punta a un selettore che ti fornisce lui) e, se spedisce con un mittente di busta nel tuo dominio, assicurati che il suo include: sia nel tuo record SPF. Fino ad allora quel traffico non ha alcun identificatore allineato, ed è esattamente il traffico che si romperà il giorno in cui passerai all’enforcement.

I record che non sono né l’uno né l’altro

C’è una quarta forma, e non rientra pulitamente in nessuna delle due: SPF fail, e nessun elemento <dkim>, perché il messaggio non era firmato da niente.

La regola qui sopra non li conta come fallimenti, ed è una scelta deliberata. Un elemento DKIM mancante non è un fallimento di DKIM: è l’assenza di prove su quel lato, e l’assenza di prove non è una prova. Ma questi record non sono nemmeno “a posto”, e meritano una coda tutta loro, perché su un dominio a p=none le spiegazioni possibili sono esattamente due e nel report sono identiche:

1. qualcuno sta falsificando il tuo dominio, oppure
2. un tuo mittente legittimo non ha alcuna autenticazione — il plugin di un modulo di contatto su un piccolo VPS, uno script di monitoraggio, un’applicazione di reparto che nessuno ricorda di aver installato.

Il report non può dirti quale delle due. L’IP sorgente di solito sì. Lavora questo elenco prima di alzare la policy, perché sono i messaggi che cominceranno a sparire nel momento esatto in cui lo farai.

Quando è davvero spoofing

I segnali, nell’ordine in cui vale la pena guardarli:

• L’IP sorgente non ha alcun rapporto con te. Non è il tuo provider, non è il tuo ufficio, non è un fornitore che sai nominare. È il segnale più forte che esista, e l’unico che si regga da solo.
• Non passa niente, nemmeno in grezzo. Nessuna firma DKIM allineata, e nessun pass SPF per un dominio che riconosci.
• L’infrastruttura di invio non somiglia a un sistema di posta. DNS inverso inutilizzabile, range di hosting invece che range di posta, una sorgente che compare una volta e non torna più.
• <header_from> è il tuo dominio mentre tutto il resto appartiene a qualcun altro. È la definizione dell’attacco per cui DMARC è stato costruito.

Qui non ci sono soglie, deliberatamente. “Più del X% da un singolo IP” è il tipo di numero che si copia da un articolo all’altro e non dice niente sul tuo dominio: un fornitore di invio legittimo concentra volumi enormi su pochissimi indirizzi. Si giudicano le sorgenti, non le percentuali.

Cosa farne, di quel numero

Non alzare la policy per far scendere un numero. È il numero sbagliato, e alzare la policy non farà quello che ti aspetti.

Procedi invece in quest’ordine. Identifica ogni sorgente nei tuoi report finché non ne resta nessuna inspiegata: quello è il lavoro vero, e su un dominio di una certa età richiede settimane, non un pomeriggio. Sistema l’allineamento di quelle legittime, cominciando dai fornitori che firmano sotto il proprio dominio. Poi sposta la policy, e non prima.

E sappi cosa succederà alla tua dashboard quando lo farai. Un lotto di spoofing latente a p=none è il caso (B): consegnato, contato come fallimento. A p=reject quello stesso lotto diventa il caso (A): rifiutato, e contato ancora come fallimento. Il conteggio dei fallimenti non deve per forza scendere perché l’enforcement stia funzionando — quella posta ha smesso di arrivare nelle caselle, che era tutto il punto. Quello che deve scendere è il volume che non sai spiegare.

I report aggregati riassumono; non contengono mai il messaggio. Quando è un messaggio specifico a darti fastidio e vuoi sapere cosa ne ha concluso davvero il server che l’ha ricevuto, incolla le sue intestazioni nel nostro analizzatore di intestazioni email: legge le dichiarazioni di chi ha ricevuto, non richiede alcun account e non conserva niente.