SPF dinamico, SPF automatico o SPF ospitato: quale di questi risolve effettivamente il problema del tuo record SPF?

Hai appena aggiunto una nuova piattaforma di help desk o di automazione del marketing al tuo stack, hai aggiornato il tuo DNS e, improvvisamente, le tue email transazionali iniziano a tornare indietro. Quando controlli le intestazioni grezze delle email, ti ritrovi di fronte a un PermError: troppe ricerche DNS.

Se inizi a cercare una soluzione, ti imbatterai immediatamente in tre termini presentati come soluzioni complete: Dynamic SPF, Auto SPF e Hosted SPF. Ogni fornitore sostiene che la propria piattaforma offra “ricerche illimitate”, ma i nomi non dicono praticamente nulla su ciò che viene effettivamente pubblicato nel tuo DNS pubblico né su come avviene la verifica dell’autenticazione al momento della consegna.

Ecco subito la realtà tecnica: queste tre denominazioni rappresentano due meccanismi fondamentalmente diversi, non tre varianti di nome dello stesso prodotto. L’SPF dinamico e l’Auto SPF si basano su istantanee IP memorizzate che devono essere continuamente risolte e aggiornate nel DNS. L’SPF ospitato (in particolare PowerSPF di PowerDMARC) utilizza la valutazione delle macro al momento della query per risolvere dinamicamente l’IP del mittente nel momento esatto della consegna. Poiché la valutazione al momento della query non crea alcuna istantanea statica, PowerSPF è l’unico meccanismo in cui il tuo record non può diventare obsoleto in modo impercettibile e bloccare la posta legittima quando un provider ruota gli intervalli IP, il tutto consumando una sola ricerca DNS. Prima di scegliere un fornitore, verifica quante ricerche DNS utilizza attualmente il tuo record per valutare il tuo livello di esposizione di base.

Perché il tuo record SPF non ha funzionato: il limite di 10 ricerche e l’errore PermError

Per correggere un record SPF che supera il limite, occorre innanzitutto comprendere perché tale limite sia previsto nelle specifiche del protocollo. Ai sensi della sezione 4.6.4 della RFC 7208, qualsiasi agente di trasferimento della posta (MTA) ricevente che valuti una politica SPF deve interrompere l'elaborazione e restituire un PermError se la valutazione richiede più di 10 meccanismi di interrogazione DNS.

Contabilità della ricerca dei meccanismi (RFC 7208 §4.6.4)

Questo limite è stato progettato specificatamente per proteggere i resolver destinatari da loop infiniti e attacchi denial-of-service di tipo DNS amplification. Tuttavia, il budget viene esaurito molto più rapidamente di quanto la maggior parte dei team IT preveda, poiché i meccanismi “include:”, “include:”, “a” e “mx” si annidano in modo ricorsivo. Quando si aggiunge una riga “include” relativa a un singolo fornitore SaaS, si ereditano tutti i meccanismi “include:”, “include:”, “a” e “mx” contenuti nell’albero dei record di quel fornitore.

Esempio concreto di record di superamento del limite

None
v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:mail.zendesk.com include:thirdparty.salesforce.com include:servers.mcsv.net ~all

Un PermError non è un avviso non vincolante; fa sì che la valutazione SPF fallisca immediatamente. Secondo lo standard DMARC (RFC 7489), se anche DKIM non supera la verifica e non è rigorosamente allineato per quell'esatto dominio di invio, l'intero messaggio non supera l'autenticazione DMARC.

Oltre al limite massimo di 10 termini di ricerca, i record SPF complessi raggiungono spesso il limite massimo di 512 byte del payload UDP del DNS. Quando una risposta DNS supera i 512 byte, i resolver devono ricorrere al protocollo TCP, il che aumenta la latenza dell’handshake e comporta timeout di autenticazione transitori. Comprendere il funzionamento dell’istruzione “SPF include” e analizzare la sintassi complessiva dei record SPF è fondamentale, specialmente quando si cerca di gestire più record SPF in ambienti di dominio complessi.

SPF dinamico, SPF automatico e SPF ospitato: un confronto rapido

La tabella che segue illustra in dettaglio il funzionamento interno di ciascun meccanismo, mettendo a confronto l'architettura di base, i costi di ricerca e i limiti operativi.

Sebbene tutte e tre le soluzioni mantengano il numero di ricerche DNS al di sotto del limite previsto dall'RFC, Hosted SPF (PowerSPF) risulta chiaramente vincente in termini di meccanismo di base. Utilizzando l'espansione delle macro al momento della query anziché il "flattening" degli indirizzi IP, PowerSPF elimina completamente il problema dell'obsolescenza degli snapshot, anziché limitarsi a ridurre l'intervallo tra gli aggiornamenti del database.

Cosa fa effettivamente l'SPF dinamico

Come funziona

Il termine “SPF dinamico” è stato coniato principalmente da Red Sift (OnDMARC) e adottato da provider quali DmarcDuty, DMARC Advisor e Dmarcly. L’architettura di base si basa su un record DNS ospitato dal fornitore. Quando si autorizza un nuovo servizio di invio nella dashboard della propria piattaforma, l’infrastruttura del fornitore risolve l’albero “include:” di destinazione e aggiorna il record ospitato a cui punta il dominio principale. Red Sift promuove questa funzionalità affermando che gli aggiornamenti avvengono «al momento dell’autenticazione». È fondamentale sottolineare che Dynamic SPF è progettato per essere privo di macro, evitando intenzionalmente la sintassi delle macro a favore di una gestione pulita delle inclusioni SPF.

Chi usa questo termine

Il marchio è utilizzato a fini commerciali da Red Sift OnDMARC, DmarcDuty, DMARC Advisor e Dmarcly. Sebbene il linguaggio di marketing vari, tutte queste implementazioni si avvalgono di server di tracciamento back-end per monitorare le modifiche agli indirizzi IP di terze parti e riscrivere i record ospitati.

Punti di forza

Il vantaggio principale di Dynamic SPF è che aggira completamente il dibattito storico sulla compatibilità a livello macro. Pubblicando meccanismi SPF standard (include:, ip4:, ip6:), garantisce la conformità anche con server di posta in ricezione non standard o legacy. Inoltre, le implementazioni di alto livello come Red Sift offrono una resilienza di fallback documentata: se si verifica un errore temporaneo nel backend, il servizio utilizza l’ultima configurazione funzionante nota proveniente dall’infrastruttura di Google Cloud, garantendo così il regolare flusso della posta.

Limiti

Nonostante il nome “Dynamic”, Dynamic SPF continua a generare un’istantanea IP gestita dietro un puntatore di riferimento. L’accuratezza del vostro record rimane dipendente dalla frequenza di polling e dal ciclo di aggiornamento del fornitore. Se un provider cloud aggiunge un nuovo blocco IP al proprio cluster di invio e invia immediatamente la posta, un ritardo nel ciclo di risoluzione del fornitore può causare errori SPF falsi positivi. Inoltre, concorrenti come AutoSPF puntano spesso su questa categoria, sottolineando che gli aggiornamenti “programmati, non in tempo reale” possono comunque rimanere indietro rispetto ai rapidi cambiamenti dell’infrastruttura.

Cosa fa effettivamente l'Auto SPF (appiattimento SPF)

Come funziona

Auto SPF solutions typically offer a hybrid approach, providing both scheduled SPF flattening and dynamic macro-based resolution. When operating in flattening mode, the system recursively queries all include:, a, and mx mechanisms, extracts the underlying IP blocks, and writes them into hosted sub-records on a scheduled loop. When operating in macro mode, tools like AutoSPF utilize %{ir} macro-flattening to evaluate connecting IPs dynamically at run-time, similar to Hosted SPF solutions.

Architettura di appiattimento SPF

1. Record originale: v=spf1 include:_spf.google.com include:sendgrid.net ~all

2. Elaborazione tramite il motore di appiattimento:

• Risolve _spf.google.com → 35.190.247.0/24, 172.217.0.0/19…
• Risolve sendgrid.net → 167.89.0.0/17, 208.117.48.0/20…

3. Record pubblico semplificato pubblicato: v=spf1 ip4:35.190.247.0/24 ip4:167.89.0.0/17 ~all

Punti di forza

Auto SPF elimina completamente la necessità di scrivere ed eseguire manualmente script Python locali per appiattire i record. È indipendente dal fornitore, conveniente e ideale per le organizzazioni che desiderano risolvere un singolo errore di ricerca SPF senza dover aderire a una piattaforma di sicurezza informatica più ampia.

Limiti

L'appiattimento comporta alcuni evidenti svantaggi operativi:

1. Obsoleta dell'istantanea: un record appiattito è un'istantanea relativa a un determinato momento. Quando un provider di posta elettronica amplia i propri intervalli IP senza preavviso, il record risulta inesatto fino al completamento del successivo polling programmato.

2. Efficienza delle ricerche: l'appiattimento richiede in genere 2 ricerche (una per il reindirizzamento CNAME e una per la catena TXT appiattita), mentre le soluzioni basate su macro ne richiedono solo 1.

3. Ingombro delle dimensioni dei record: la sostituzione degli "include" con centinaia di blocchi CIDR grezzi porta la lunghezza dei record a sfiorare il limite UDP di 512 byte.

4. Divulgazione dell’infrastruttura IP pubblica: il “flattening” espone l’intero stack di invio autorizzato in un DNS pubblico in chiaro, fornendo ai malintenzionati una mappa esatta dei vostri fornitori terzi. Gli esperti del settore hanno costantemente sconsigliato il “flattening” puro proprio a causa di queste precise vulnerabilità strutturali.

Le sfumature della comunicazione

Sebbene AutoSPF venga ampiamente pubblicizzato per le sue funzionalità di “flattening” automatizzato, pensate per gli utenti che desiderano disporre di elenchi di indirizzi IP statici e leggibili nel proprio DNS, è importante sottolineare che la piattaforma supporta nativamente anche la risoluzione delle macro in tempo reale per le organizzazioni che necessitano di aggiornamenti senza alcun ritardo.

Cosa distingue Hosted SPF (PowerSPF): le macro in fase di query

“Hosted” è un modello di distribuzione, non un meccanismo

Per valutare questi prodotti in modo obiettivo, è necessario tenere presente che il termine “hosted” descrive la modalità di distribuzione del record, non la tecnologia che sta alla base. Dynamic SPF, Auto SPF e PowerSPF sono tutti servizi “hosted”: l’utente pubblica un unico riferimento statico nel DNS del proprio dominio e il fornitore gestisce il contenuto sottostante. Ciò che distingue l’Hosted SPF (PowerSPF) di PowerDMARC è il motore che sta alla base di quel riferimento: la valutazione delle macro al momento della query.

Pipeline di valutazione delle macro PowerSPF

1. Indirizzo IP dell'MTA del mittente: 192.0.2.45

2. Receiver Queries Domain SPF Policy: v=spf1 exists:%{i}.abcde12345.macrospf.powerspf.com -all

3. Receiver Expands Macro %{i} to Connecting IP: 192.0.2.45.abcde12345.macrospf.powerspf.com

4. Il destinatario esegue 1 ricerca DNS sul nome host espanso:

• La query arriva al DNS periferico di PowerDMARC.
• 192.0.2.45 è autorizzato nella dashboard → Restituisce 127.0.0.2 (esiste un record A).
• Risultato della valutazione SPF: SUPERATO

Come PowerSPF identifica il mittente

Anziché memorizzare un elenco di indirizzi IP risolti nel proprio DNS, PowerSPF utilizza le macro ufficiali definite nella RFC 7208. Quando si implementa PowerSPF, il record DNS pubblico viene configurato con un meccanismo "exists:" strutturato in questo modo:

v=spf1 exists:%{i}.abcde12345.macrospf.powerspf.com -all

When a receiving mail server processes an incoming message, it evaluates the macro %{i}, which the SPF specification defines as the connecting sender’s IP address. The receiver automatically inserts the sender’s IP into the string and executes a single DNS query:

192.0.2.45.abcde12345.macrospf.powerspf.com

La rete DNS globale di PowerDMARC riceve questa richiesta. Se l'indirizzo IP 192.0.2.45 è autorizzato nella dashboard di PowerDMARC, il server DNS restituisce una risposta con un record A (127.0.0.2). Il server ricevente verifica che il dominio esista e convalida il controllo SPF come "Pass".

Cosa ottieni con questo acquisto

1. Sempre 1 ricerca DNS: indipendentemente dal fatto che si autorizzino 3 o 50 strumenti di invio, il record consuma esattamente 1 ricerca DNS. Secondo i test di benchmark interni di PowerDMARC, la transizione da un record standard a 5 ricerche al funzionamento delle macro SPF riduce il costo delle ricerche a 1, mentre l’appiattimento lo porta in genere a 2.

2. Assenza totale di obsolescenza degli snapshot: poiché l'IP di connessione viene valutato in tempo reale al momento della consegna, non esiste un elenco di IP memorizzato nella cache che possa diventare obsoleto.

3. Privacy totale dell'IP: gli intervalli IP autorizzati non vengono mai pubblicati in chiaro nei record DNS pubblici.

4. Nessun aumento di dimensioni: la stringa del record DNS rimane molto breve e statica, totalmente immune agli errori di troncamento UDP a 512 byte.

Configurazione e operazioni del secondo giorno

Per configurare l’SPF in hosting (PowerSPF) è necessario aggiungere un unico record CNAME al proprio DNS, un’operazione che richiede meno di cinque minuti. Una volta configurato, il team IT non dovrà più intervenire sui record DNS. L’autorizzazione o la revoca dei mittenti avviene direttamente dalla dashboard di PowerDMARC, con applicazione immediata a livello globale.

Capacità di governance aziendale

Gli strumenti che offrono soluzioni puntuali gestiscono i record in modo isolato, mentre PowerSPF opera all’interno di una piattaforma di sicurezza completa. Offre:

• Analisi granulari dell'SPF che descrivono in dettaglio il volume di invio per fonte, meccanismo e singolo indirizzo IP.
• Rilevamento automatico di PermError, ricerche nulle ed errori di sintassi con istruzioni di correzione integrate.
• Integrazione SSO/SAML aziendale, supportata dalle certificazioni SOC 2 Tipo 2 e ISO 27001.
• Uno SLA con un tempo di attività del 99,995% basato su un’infrastruttura edge ad alta disponibilità.
• Integrazione completa con l'applicazione di DMARC, la gestione di DKIM, la distribuzione del marchio tramite BIMI e la gestione delle politiche MTA-STS.

La modalità di guasto che nessuno inserisce nella propria pagina dei prezzi

Per capire perché il meccanismo di base sia importante, prendiamo in esame uno scenario operativo standard:

Un’azienda di medie dimensioni configura uno strumento di flattening SPF per gestire sei servizi cloud, tra cui un importante CRM e un provider di posta elettronica transazionale. Tutte le autenticazioni avvengono senza problemi e il numero di ricerche scende da 13 a 2.

Sei settimane dopo, il provider di email transazionali assegna un nuovo blocco di indirizzi IP al proprio cluster di invio per gestire l'aumento del traffico. Il provider aggiorna il proprio record SPF primario (_spf.vendor.com). Tuttavia, il tuo strumento di "flattening" effettua la risoluzione dei record esterni solo a intervalli fissi di 4 o 12 ore.

Analisi del divario temporale di appiattimento

Durante quel periodo di transizione, i messaggi transazionali legittimi — notifiche di fatturazione, reimpostazioni delle password, conferme d'ordine — vengono inviati dai nuovi indirizzi IP del provider. Quando i server di destinazione verificano il tuo record SPF semplificato, il nuovo IP risulta assente.

La verifica dell'SPF fallisce. Se il DKIM è danneggiato, non allineato o rimosso da un relay intermedio, il messaggio non supera il controllo DMARC. I server di ricezione applicano la tua politica DMARC, indirizzando la posta aziendale legittima nelle cartelle dello spam o eliminandola del tutto.

Poiché questa modalità di guasto è parziale e specifica della fonte, raramente attiva avvisi di rete immediati. La posta elettronica principale continua a circolare, ma un flusso transazionale critico si interrompe in modo impercettibile.

Il confronto: con la valutazione delle macro al momento della query, non esiste alcuna istantanea del database degli IP che possa diventare obsoleta. Quando il fornitore invia un’e-mail da un servizio di invio appena autorizzato, PowerSPF valuta in tempo reale l’IP di connessione in base alla politica della tua dashboard proprio nel momento esatto della consegna.

Il compromesso tecnico onesto: nessuna architettura di sicurezza è priva di rischi. L’appiattimento sposta la dipendenza in materia di sicurezza sulla frequenza di aggiornamento del database del fornitore; tuttavia, poiché gli IP appiattiti sono memorizzati nella cache dei record TXT DNS standard, l’autenticazione delle e-mail rimane valida anche se il backend del fornitore va offline. La valutazione delle macro sposta la dipendenza sulla raggiungibilità del servizio DNS delle macro del fornitore al momento della query. Se un fornitore basato su macro subisce un’interruzione del DNS autorevole, i controlli SPF in entrata restituiranno un TempError o falliranno completamente fino al ripristino del servizio. I provider di alto livello risolvono questo problema mantenendo reti periferiche distribuite a livello globale con uno SLA che garantisce un tempo di attività del 99,995%.

Due obiezioni che sentirai dai concorrenti

1. «La valutazione basata su macro crea un unico punto di errore.»

I concorrenti che si affidano esclusivamente all’approccio tradizionale di “appiattimento” sottolineano spesso che la valutazione delle macro al momento della query richiede una ricerca DNS in tempo reale sul server del fornitore per ogni singola consegna di e-mail.

Verifica dei fatti: si tratta di una distinzione architettonica valida. Se l’infrastruttura DNS di un provider di macro va offline, il destinatario non è in grado di espandere la macro, causando un errore SPF TempError. Il “flattening” tradizionale evita questo problema perché i record TXT standard rimangono memorizzati nella cache a livello globale. Per mitigare questo rischio, i provider di macro-SPF aziendali (come PowerSPF) gestiscono reti DNS Anycast altamente ridondanti e distribuite a livello globale, al fine di garantire risposte alle query in meno di un millisecondo e la massima disponibilità.

2. “Le macro SPF non funzionano correttamente sui server di posta in entrata meno recenti.”

Competitors using traditional flattening often claim that macro syntax (exists:%{i}) breaks compatibility with legacy email gateways.

Verifica dei fatti: l’espansione delle macro e il meccanismo “exists:” sono componenti fondamentali della RFC 7208 §7, pubblicata nel 2014 (e in precedenza nella RFC 4408 del 2006). Non si tratta di estensioni proprietarie dei fornitori. Ogni server di posta in ricezione conforme agli standard RFC su Internet, inclusi Microsoft 365, Google Workspace, Proofpoint, Cisco Secure Email e Mimecast, supporta nativamente l’espansione delle macro.

Sebbene un gateway legacy non conforme, evento eccezionalmente raro, possa non riuscire ad analizzare correttamente le macro, questo rischio marginale deve essere valutato alla luce del rischio quotidiano garantito di obsolescenza degli snapshot degli IP statici causato dal tradizionale appiattimento.

Quale soluzione dovresti scegliere?

Matrice decisionale

Scenario 1: si dispone di 2-3 server di invio cloud stabili e meno di 10 ricerche

Se il tuo dominio utilizza solo Google Workspace e un unico help desk, potrebbe non essere necessario acquistare alcun software di gestione SPF. Verifica il tuo record utilizzando uno strumento di ricerca, rimuovi le righe "include:" inutilizzate e sostituisci i meccanismi MX o A superflui con regole semplici. Se il numero di ricerche rimane inferiore a 10, mantieni la tua configurazione DNS standard.

Scenario 2: Gestisci da 5 a 30 strumenti cloud con rotazioni IP attive

Se la vostra organizzazione si avvale di una suite moderna di strumenti di marketing, vendite e risorse umane, l’appiattimento tradizionale comporta un rischio costante in termini di deliverability. La valutazione delle macro al momento della query tramite PowerSPF rappresenta la scelta tecnica ottimale, in quanto elimina il problema dell’obsolescenza degli snapshot, protegge la vostra topologia IP interna e limita le ricerche a 1.

Scenario 3: MSP e team aziendali che gestiscono portafogli multidominio

Se gestite l'autenticazione delle e-mail su decine di domini client, valutare strumenti specifici in modo isolato complica la gestione. Avete bisogno di una dashboard multi-tenant, controlli di accesso basati sui ruoli, analisi granulari degli indirizzi IP e una suite completa per l'autenticazione. Esplorare le alternative ad AutoSPF porterà i team aziendali a piattaforme unificate come PowerDMARC.

Conclusione

SPF dinamico, SPF automatico e SPF ospitato riusciranno tutti a ridurre il numero di ricerche DNS al di sotto della soglia di 10 ricerche prevista dalla RFC già da oggi. Tuttavia, solo la valutazione delle macro al momento della query garantisce che il record non subisca domani uno scostamento impercettibile.

Verificando l'autorizzazione del mittente in tempo reale al momento della consegna, Hosted SPF (PowerSPF) elimina il problema dei dati obsoleti, nasconde la traccia degli IP interni e riduce il costo delle ricerche DNS a 1, il tutto all’interno di una piattaforma di livello aziendale supportata da uno SLA che garantisce un tempo di attività del 99,995%.

Prossimi passi:

1. Utilizza il nostro strumento gratuito di analisi SPF per verificare il numero attuale di ricerche relative al tuo dominio e individuare eventuali inclusioni annidate.

2. Se il tuo record supera le 10 consultazioni, avvia una prova gratuita di PowerSPF (Hosted SPF) per correggere il tuo record in meno di cinque minuti.

3. Gestisci un’azienda o un portafoglio MSP? Fissa una demo tecnica con il nostro team di ingegneri per scoprire la nostra dashboard di autenticazione multi-tenant.

Domande frequenti

L'SPF dinamico è la stessa cosa dell'appiattimento dell'SPF?

L'SPF dinamico è un termine generico, mentre l'appiattimento dell'SPF è un meccanismo specifico. Molti fornitori che offrono l'“SPF dinamico” si avvalgono, dietro le quinte, dell'appiattimento automatico dell'SPF, che risolve periodicamente le catene di include: in indirizzi IP statici pubblicati nei record ospitati.

Qual è la differenza tra SPF in hosting e SPF flattening?

SPF Flattening estrae gli intervalli di indirizzi IP e li pubblica come blocchi di IP statici nel tuo DNS. L'SPF ospitato (in particolare PowerSPF di PowerDMARC) utilizza la valutazione delle macro al momento della query per verificare in tempo reale l'IP del mittente al momento della consegna, evitando la memorizzazione di IP statici e prevenendo l'obsolescenza degli snapshot.

Le macro SPF funzionano con Microsoft 365 e Google Workspace?

Sì. L'espansione delle macro e il meccanismo "exists:" sono pienamente standardizzati ai sensi della RFC 7208, paragrafo 7. Sia Microsoft 365 che Google Workspace gestiscono in modo nativo la valutazione SPF basata sulle macro senza problemi di compatibilità.

Esiste davvero la possibilità di effettuare “ricerche SPF illimitate”?

Nessun singolo record può superare il limite di 10 ricerche previsto dalla RFC 7208 durante la valutazione. Le piattaforme che offrono “ricerche illimitate” ottimizzano l’architettura dei record, ricorrendo all’appiattimento o alle macro, in modo che, indipendentemente dal numero di mittenti aggiunti, il server ricevente esegua al massimo 1 o 2 ricerche.

Cosa succede alla mia posta elettronica se il mio provider SPF in hosting subisce un’interruzione del servizio?

I fornitori di alto livello come PowerDMARC utilizzano reti edge distribuite con uno SLA che garantisce un tempo di attività del 99,995%. In caso di interruzione del servizio, i nodi DNS ridondanti continuano a rispondere e le regole di fallback impediscono il verificarsi di errori di autenticazione.

Come posso risolvere il problema delle “troppe ricerche DNS” nel mio record SPF?

È possibile correggere un record che supera il limite effettuando una verifica e rimuovendo le istruzioni `include:` obsolete, spostando determinati mittenti su sottodomini dedicati oppure implementando una soluzione di macro in hosting come PowerSPF per ridurre il costo di valutazione a una sola ricerca.

• Informazioni su
• Ultimi messaggi

Milena Baghdasaryan

Specialista dei contenuti presso PowerDMARC

Milena è un'abile scrittrice e creatrice di contenuti con oltre 7 anni di esperienza nella creazione di contenuti coinvolgenti su IT, cybersicurezza, eventi virtuali e altro. Ha una comprovata esperienza nella realizzazione di lavori di alta qualità per riviste internazionali e si è laureata in istituzioni prestigiose come la New York University Abu Dhabi, l'UWC China e il College of Europe.

Ultimi messaggi di Milena Baghdasaryan (vedi tutti)

• SPF dinamico, SPF automatico o SPF ospitato: quale di questi risolve effettivamente il problema del tuo record SPF? - 25 agosto 2026
• "Rispondi" vs "Rispondi a tutti": galateo e rischi per la sicurezza - 14 agosto 2026
• Rapporti di errore DMARC (RUF): cosa sono, come funzionano e come abilitarli in modo sicuro - 11 agosto 2026