Aggiornamento: A partire da novembre 2025, Gmail intensificherà l'applicazione sulle email non conformi. I messaggi che non soddisfano i requisiti richiesti per l'invio saranno soggetti a interruzioni, inclusi rifiuti temporanei e permanenti.
Introduzione
In risposta alle sfide sempre crescenti poste da spam, phishing e frodi via email, i giganti dei servizi email Microsoft, Google e Yahoo hanno implementato cambiamenti significativi per gli invii massivi—aziende che inviano più di 5.000 email al giorno. Google e Yahoo sono stati i primi ad annunciare tali requisiti nell’ottobre 2023, seguiti da Microsoft nell’aprile 2025. Dal 2026, questi requisiti sono ora lo standard di settore e sono applicati rigorosamente da tutti e tre i provider.
Questi requisiti condividono alcuni punti chiave, che si possono raggruppare nelle seguenti categorie:
- Autentica il tuo dominio. Proteggi i destinatari da messaggi malevoli e la tua organizzazione dall’essere impersonata.
- Rendi facile la disiscrizione. Offri ai destinatari un modo semplice per annullare l’iscrizione ai tuoi messaggi.
- Non fare spam. Invia messaggi desiderati solo a chi si è iscritto esplicitamente.
L’obiettivo alla base di queste nuove politiche è un impegno collettivo per rendere le caselle di posta più sicure e meno soggette a spam. Con questa presa di posizione unitaria, Microsoft, Google e Yahoo stanno indicando che la sicurezza email non è più un'opzione. Dal 2026, gli standard di sicurezza email considerati best practice ora sono un obbligo di fatto. Chi non si adeguata a tali requisiti vedrà i tre provider limitare le velocità di invio o classificare i messaggi legittimi come spam. Per gli utenti Microsoft, i messaggi non conformi saranno rifiutati completamente.
Che tu sia un marketer, un IT manager, o un piccolo imprenditore che invia più o circa 5.000 email al giorno a caselle di Microsoft, Google o Yahoo, questa guida ti aiuterà a comprendere i requisiti, i vantaggi e come prepararti.
Cosa è cambiato e cosa fare ora
Il panorama degli invii massivi è cambiato drasticamente tra il 2024 e il 2026. Ecco una rapida panoramica dei cambiamenti e cosa devi fare concretamente.
Tempistiche delle modifiche di applicazione
Data | Provider | Cosa è cambiato |
Febbraio 2024 | Google, Yahoo | Inizio dell’applicazione. I messaggi non conformi iniziano a ricevere rifiuti temporanei (errori 421) |
Aprile 2024 | Google, Yahoo | Applicazione più rigorosa. I tassi di rifiuto aumentano per le email non autenticate |
Maggio 2025 | Microsoft | Parte l'applicazione per Outlook.com. I messaggi non conformi vengono rifiutati su hotmail.com, live.com, outlook.com |
Novembre 2025 | Applicazione rafforzata. Il traffico non conforme subisce ora rifiuti permanenti (errori 550) | |
2026 | Google, Yahoo & Microsoft | Applicazione totale su Microsoft, Google e Yahoo. Questi requisiti sono ora lo standard di settore |
Cosa devi fare subito
Se non sei ancora conforme:
- Controlla il tuo stato attuale. Usa Red Sift Investigate per inviare un’email di prova da ciascun servizio che usi per l’invio. Riceverai un riepilogo visivo di ciò che va correttamente configurato.
- Risolvi le lacune di autenticazione. I problemi più comuni che vediamo: Record SPF mancante o configurato male DKIM non impostato su tutti i servizi Nessun record DMARC pubblicato SPF o DKIM non allineato col dominio di invio (From)
- Abilita la disiscrizione con un clic. Controlla le impostazioni del tuo ESP (HubSpot, Mailchimp, Salesforce Marketing Cloud, ecc.). La maggior parte delle piattaforme la abilita di default, ma verifica che funzioni davvero.
- Monitora il tuo tasso di spam. Configura Google Postmaster Tools e Yahoo's Complaint Feedback Loop. Tieni il tasso sotto lo 0,1% e non lasciare mai che superi lo 0,3%.
Se sei già conforme:
- Passa all’applicazione DMARC. Il requisito attuale è p=none, ma la best practice di settore è p=reject. Così ottieni protezione integrale contro l’impersonificazione del dominio.
- Monitora in modo continuativo. L’autenticazione può smettere di funzionare se aggiungi nuovi servizi di invio, cambi ESP o fai modifiche DNS. Imposta un monitoraggio costante con uno strumento come Red Sift OnDMARC.
- Tieni d’occhio gli aggiornamenti di policy. Microsoft, Google e Yahoo potrebbero irrigidire ancora i requisiti. DMARC a p=reject potrebbe diventare obbligatorio.
Guida rapida alle decisioni
Devi agire se ti riconosci in uno di questi punti:
- Invii più di 5.000 email al giorno a indirizzi Gmail, Yahoo o Outlook.com
- Hai rilevato errori SMTP 421 o 550 riguardanti l’autenticazione
- Il tuo record DMARC manca o è impostato su p=none senza allineamento SPF/DKIM
- Non hai una firma DKIM per tutti i servizi di invio
- La procedura di disiscrizione richiede più di 2 giorni
- Il tuo tasso di reclami per spam è sopra lo 0,1%
Sei a posto se:
- SPF e DKIM superano i controlli per tutti i servizi di invio
- Almeno uno tra SPF o DKIM è allineato col dominio From
- DMARC è pubblicato (idealmente a p=reject, minimo p=none)
- La disiscrizione one-click è abilitata ed elaborata entro 2 giorni
- Il tasso di spam resta sotto lo 0,1%
- FCrDNS è configurato per i tuoi IP di invio
- TLS è abilitato per la trasmissione delle email
Checklist di applicazione
Usa questa checklist per verificare la conformità su tutti i servizi di invio email che utilizzi. Ricorda: ogni ESP e dominio di invio va controllato separatamente.
Checklist autenticazione email
Requisito | Stato | Come verificare | Come sistemare |
Record SPF pubblicato | [ ] | Usa Red Sift Investigate o controlla i DNS cercando il record TXT che inizia per "v=spf1" | Aggiungi il record SPF ai DNS. Includi tutti gli IP autorizzati all’invio |
Firma DKIM presente | [ ] | Invia una prova e verifica la presence di "DKIM-Signature" nell’header | Configura DKIM nel tuo ESP e aggiungi la chiave pubblica nei DNS |
SPF supera i controlli | [ ] | Verifica nell’header la scritta "spf=pass" | Accertati che l’IP mittente sia incluso nel record SPF |
DKIM supera i controlli | [ ] | Verifica nell’header la scritta "dkim=pass" | Controlla che le chiavi DKIM siano correttamente pubblicate nei DNS |
SPF o DKIM allineati | [ ] | Il dominio in SPF o DKIM deve coincidere col dominio From | Configura l’ESP per inviare con domini allineati |
Record DMARC pubblicato | [ ] | Controlla nei DNS il record TXT in _dmarc.tuodominio.com | Aggiungi il record DMARC: v=DMARC1; p=none; rua=mailto:dmarc@tuodominio.com |
Policy DMARC almeno p=none | [ ] | Controlla il tuo record DMARC | Aggiorna la policy a p=none (minimo) o p=reject (consigliato) con il supporto di Red Sift |
FCrDNS configurato | [ ] | Il lookup DNS inverso sull’IP di invio deve restituire un hostname che risolva lo stesso IP | Contatta il tuo provider di hosting o ISP per configurare il reverse DNS |
TLS abilitato | [ ] | Controlla negli header l’indicazione della crittografia TLS | Abilita nelle impostazioni dell’ESP (la maggior parte dei provider lo fa di default) |
Inizia subito con risultati automatici
Checklist disiscrizione one-click
Requisito | Stato | Come verificare | Come risolvere |
Intestazione List-Unsubscribe presente | [ ] | Controlla le intestazioni dell'email per "List-Unsubscribe" e "List-Unsubscribe-Post" | Abilita nelle impostazioni dell'ESP |
Disiscrizione con un clic funzionante | [ ] | Testa il link di disiscrizione nelle tue email | Configura la disiscrizione conforme a RFC 8058 nel tuo ESP |
Le disiscrizioni vengono elaborate entro 2 giorni | [ ] | Testa la disiscrizione e verifica la rimozione dalla lista | Rivedi le impostazioni di automazione dell'ESP |
Checklist tasso di spam
Requisito | Stato | Come verificare | Come risolvere |
Tasso di spam sotto lo 0,1% | [ ] | Google Postmaster Tools | Pulisci le liste, migliora i contenuti, verifica il double opt-in |
Il tasso di spam non deve mai raggiungere lo 0,3% | [ ] | Google Postmaster Tools | Azione immediata richiesta se sopra lo 0,3% |
Monitoraggio attivo | [ ] | Conferma l'accesso a Postmaster Tools e Yahoo CFL | Crea gli account e verifica i domini |
Codici di errore comuni e cosa significano
Se non soddisfi i requisiti, vedrai questi codici di errore SMTP:
Codice errore | Significato | Cosa correggere |
421-4.7.26 | SPF e DKIM entrambi falliti | Configura sia SPF che DKIM per l'autenticazione |
421-4.7.30 | DKIM non passa (mittente bulk) | Configura DKIM per il tuo servizio di invio |
421-4.7.32 | Nessun allineamento DMARC | Assicurati che il dominio SPF o DKIM sia allineato con il dominio From |
550-5.7.26 | Email non autenticata rifiutata (permanente) | Correggi immediatamente SPF e DKIM. Non si tratta più di un rinvio temporaneo |
Se visualizzi errori 421: La posta viene temporaneamente rimandata. Risolvi i problemi di autenticazione prima che Google passi al rifiuto permanente (errori 550).
Se visualizzi errori 550: La posta viene rifiutata in modo permanente. Richiede attenzione immediata.
Quali sono i requisiti?
I requisiti per mittenti bulk/ad alto volume coprono tre aree chiave. Nella tabella qui sotto approfondiamo ciascuna area e i requisiti specifici, incluse le eventuali sotto-requisiti, a partire dal requisito più importante e impegnativo dal punto di vista del tempo – l'autenticazione delle email.
Nota che tali requisiti devono essere applicati per ogni servizio di invio e/o piattaforma da cui inoltri posta – ulteriori dettagli più avanti.
Requisiti per mittenti bulk
Requisito | Spiegazione | Beneficio | Tempistiche applicazione |
Autenticazione email | |||
Configura SPF e DKIM per ogni dominio mittente. | SPF e DKIM sono due protocolli di sicurezza email. Occorre definire i record per ciascun protocollo e aggiungerli al tuo DNS o sulla piattaforma che gestisce SPF e DKIM per il tuo dominio. SPF valida l'indirizzo IP del mittente, DKIM garantisce l'integrità del messaggio. Insieme al protocollo DMARC (di cui si parla più avanti), questi protocolli impediscono che il tuo dominio venga impersonato. | Migliora l'integrità delle email e la verifica dell'identità del mittente. | Google e Yahoo hanno iniziato l'applicazione nel 2024. Microsoft dal 5 maggio 2025. Dal 2026, tutti e tre i provider applicano rigorosamente questi requisiti. |
Invia con un dominio `From` allineato in almeno uno tra i domini SPF o DKIM. | Allineamento SPF e DKIM assicura che il dominio mittente nell'indirizzo “From” sia allineato a quello autorizzato dai record SPF e coperto dalla firma DKIM. Microsoft, Google e Yahoo richiedono l'allineamento di almeno uno tra SPF o DKIM. Senza allineamento, DMARC non sarà valido. È quindi essenziale che almeno uno dei protocolli passi ed abbia l'allineamento richiesto. | Senza l'allineamento, rischi che le email finiscano nello spam invece che nella posta in arrivo. Inoltre, se ottieni l'allineamento su tutti i servizi di invio, sarai pronto a proteggere il tuo dominio portando DMARC a una policy di reject. | Vedi sopra |
Pubblica una policy DMARC per ogni dominio mittente con almeno policy “none”. | DMARC è un altro protocollo di sicurezza email. Insieme a SPF e DKIM protegge il tuo dominio da impersonificazione. Dovrai creare un record DMARC in policy none. È il primo passo di un progetto DMARC – dovresti puntare a raggiungere la policy reject per una protezione completa. | Raggiunta la policy reject, DMARC aiuta a bloccare attacchi di impersonificazione diretta del dominio, proteggendo dipendenti, clienti e partner da email malevole inviate in tuo nome. | Vedi sopra |
Assicurati che domini o IP mittenti abbiano FcrDNS impostato | FCrDNS significa Forward Confirmed Reverse DNS. Serve a dimostrare la relazione tra l'indirizzo IP e il nome di dominio. FCrDNS viene configurato dal proprietario del dominio e dal proprietario dell'IP. Se non possiedi l'IP, potresti dover contattare il provider di hosting o l'ISP per configurare il reverse DNS. | Aiuta con la deliverability delle email. Senza FCrDNS alcuni provider potrebbero bloccare o filtrare nello spam. | Vedi sopra |
Usa una connessione TLS per trasmettere email | TLS cripta la comunicazione tra il mittente e il destinatario per evitare che i messaggi vengano letti durante il transito. | Impedisce ai malintenzionati di intercettare le email. | Vedi sopra |
Disiscrizione con un clic | |||
Abilita la disiscrizione con un solo clic per i destinatari delle email promozionali. | Facilita agli utenti l'opzione di non ricevere più email inserendo un link disiscrizione one-click e assicurati che venga processata entro 2 giorni. | Diminuisce le possibilità di essere contrassegnato come spam (e migliora le probabilità di finire in inbox), favorendo il tasso di spam. | Google e Yahoo hanno iniziato ad applicare questa regola nel 2024. Microsoft dal 5 maggio 2025. Dal 2026, tutti e tre i provider la applicano. |
Bassi tassi di spam | |||
Mantieni i tassi di spam sotto lo 0,10%. | Google e Yahoo raccomandano di mantenere il tasso di spam sotto lo 0,1%. Non dovresti mai raggiungere lo 0,3%. Per verificare i tuoi valori consulta Google Postmaster Tools o Yahoo Complaint Feedback Loop. | Migliora la reputazione dei mittenti e i tassi di deliverability | Google e Yahoo l'hanno reso obbligatorio dal 2024. Microsoft non lo richiede come parte dei requisiti per mittenti bulk. Tuttavia rimane una best practice per il 2026. |
Scenari comuni che possono portare al fallimento
Segue una lista illustrativa – non esaustiva – di scenari comuni che possono portare i mittenti bulk a non soddisfare i nuovi requisiti.
Scenari comuni che possono causare il fallimento dei mittenti bulk
Componenti di intestazione | Policy DMARC | SPF | Allineamento SPF | DKIM | Allineamento DKIM | FCrDNS | Conformità | |
Configurazione DMARC | Messaggio 1 FROM: @example.com MAILFROM/RP: @example.com DKIM: d=example DMARC: p=reject rDNS = 1.23.45.6 -> mta.example.com A record: mta.example.com -> 1.23.45.6 | 🟢 | 🟢 | 🟢 | 🟢 | 🟢 | 🟢 | 🌟 Questa è la best practice per gli invii massivi |
Messaggio 2 FROM: @example.com MAILFROM/RP: @example.com DKIM: d=example DMARC: p=none rDNS = 1.23.45.6 -> mta.example.com Record A: mta.example.com -> 1.23.45.6 | 🟢 | 🟢 | 🟢 | 🟢 | 🟢 | 🟢 | ✅ Agli speditori è richiesto solo di avere un record DMARC, non l'applicazione DMARC | |
Messaggio 3 FROM: @example.com MAILFROM/RP: @example.com DKIM: d=example DMARC: nessun record rDNS = 1.23.45.6 -> mta.example.com Record A: mta.example.com -> 1.23.45.6 | 🔴 | 🟢 | 🟢 | 🟢 | 🟢 | 🟢 | ❌ È richiesto un record DMARC. | |
SPF & DKIM | Messaggio 4 FROM: @example.com MAILFROM/RP: @example.comDMARC: p=reject rDNS = 1.23.45.6 -> mta.example.com Record A: mta.example.com -> 1.23.45.6 | 🟢 | 🟢 | 🟢 | 🔴 | 🔴 | 🟢 | ❌ Richiede SPF & DKIM |
Messaggio 5 FROM: @example.com MAILFROM/RP: @somethingelse.com DKIM: d=example DMARC: p=reject rDNS = 1.23.45.6 -> mta.example.com Record A: mta.example.com -> 1.23.45.6 | 🟢 | 🔴 L’IP di invio non è presente nel record SPF | 🔴 | 🟢 | 🟢 | 🟢 | ❌ Richiede SPF & DKIM | |
Messaggio 6 FROM: @example.com MAILFROM/RP: @somethingelse.com DMARC: nessun record DKIM: d=somethingelse rDNS = 1.23.45.6 -> mta.example.com Record A: mta.example.com -> 1.23.45.6 | 🔴 | 🟢 | 🔴 | 🟢 | 🔴 | 🟢 | ❌ Richiede l’allineamento SPF o DKIM. Non avendone nessuno, questo messaggio non può neanche avere DMARC. | |
FcrDNS | Messaggio 7 FROM: @example.com MAILFROM/RP: @example.com DKIM: d=example DMARC: p=reject rDNS = nessun record Record A: mta.example.com -> 1.23.45.6 | 🟢 | 🟢 | 🟢 | 🟢 | 🟢 | 🔴 | ❌ L’indirizzo IP di invio non risolve in un hostname valido. |
Messaggio 8 FROM: @example.com MAILFROM/RP: @example.com DKIM: d=example DMARC: p=reject rDNS = 1.23.45.6 -> mta.example.com Record A: nessun record | 🟢 | 🟢 | 🟢 | 🟢 | 🟢 | 🔴 | ❌ Il record A non corrisponde all’indirizzo IP di invio. |
Aiuto! Dove sono configurati i requisiti di Microsoft, Google e Yahoo?
Nella tabella sottostante, mostriamo quali requisiti sono configurati a livello di email service provider (ESP) (Hubspot, MailChimp, ecc.) e/o a livello di dominio. Questo ti aiuterà a capire dove è necessario intervenire per ciascun requisito.
È importante notare che se la tua organizzazione utilizza più ESP, dovrai configurare questi elementi su ciascuna piattaforma. Lo stesso vale per l'uso di più domini.
Dove vengono configurati i requisiti di Microsoft, Google e Yahoo
Requisito | Configurato a livello ESP/piattaforma | Configurato a livello DNS |
Implementazione di SPF e DKIM | ✅ | ✅ |
Invio con un dominio From allineato in uno tra i domini SPF o DKIM | ✅ | ✅ |
Invio da un dominio con una policy DMARC di almeno p=none (incluso un tag RUA, come raccomandato da Yahoo*) | ❌ | ✅ |
Utilizzo di una connessione TLS per la trasmissione delle email | ✅ | ❌ |
DNS forward e reverse validi (FCrDNS) | ✅ | ✅ |
Annullamento iscrizione con un solo clic (RFC 8058) | ✅ | ❌ |
Tasso basso di segnalazione spam | ✅** | ❌ |
*Anche se l’inclusione del tag RUA è al momento solo consigliata e non obbligatoria da parte di Yahoo, siamo pienamente d’accordo con questa scelta. Il tag RUA specifica dove inviare i rapporti aggregati DMARC che forniscono una panoramica quotidiana del traffico email di un dominio. Questi report forniscono insight fondamentali sullo stato dell’autenticazione SPF, DKIM e DMARC così come su dove viene utilizzato il tuo dominio, facilitando l’individuazione delle email che non rispettano i requisiti di autenticazione.
**Sebbene un basso tasso di spam sia sotto il controllo del mittente, la posta parte dal livello ESP. Se, ad esempio, usi Salesforce Marketing Cloud per la posta marketing e SendGrid per le transazionali con Mailgun come backup, il tuo tasso complessivo di reclami per spam, indipendentemente dalla piattaforma di invio, deve rimanere al di sotto della soglia dello 0,3%.
Chi è interessato da questi cambiamenti?
Le Linee guida per i mittenti email di Google dichiarano che i requisiti si applicano ad aziende che inviano email a qualsiasi casella personale Gmail, quindi un “account che termina con @gmail.com o @googlemail.com”. Inoltre, Google precisa che “i requisiti non si applicano ai messaggi in ingresso o intra-dominio in Google Workspace.” Dal 2026 Google applica rigorosamente tali requisiti a tutti gli invii massivi.
La normativa di Yahoo riguarda “tutti i domini e i brand email consumer ospitati da Yahoo Mail”.
Per Microsoft, le policy email di Outlook.com si applicano agli indirizzi consumer dei domini hotmail.com, live.com e outlook.com. Tali requisiti sono entrati in vigore il 5 maggio 2025 e sono pienamente applicati dal 2026.
Come Red Sift può aiutarti a prepararti
Vuoi un modo semplice per verificare se i tuoi domini mittenti sono conformi? In meno di un minuto, il nostro tool Investigate gratuito controlla quanto sei allineato ai requisiti di Microsoft, Google e Yahoo e ti fornisce una panoramica visiva di ciò che devi ancora sistemare.
Tutto ciò che serve per iniziare con Red Sift Investigate è inviare un’email a una casella di test.
Comprendere i codici di errore di enforcement di Google
I codici di errore SMTP (Simple Mail Transfer Protocol) sono codici a tre cifre restituiti dai mail server per indicare lo stato di un tentativo di consegna email. Questi codici aiutano a diagnosticare problemi di consegna fornendo informazioni sul motivo della mancata consegna.
Se non stai ancora rispettando i requisiti per gli invii massivi, è probabile che tu abbia visto questi codici e ti stia chiedendo cosa significano. Questi codici segnalano che la tua posta non autenticata è stata rifiutata e ti aiutano a individuare e correggere problemi legati al dominio.
Sebbene Google non abbia ancora aggiornato il suo articolo sugli errori e codici SMTP, sappiamo che esistono già i seguenti codici di errore 421:
1) Fallimento sia di SPF che DKIM:
421-4.7.26 This mail has been rate limited because it is unauthenticated. Gmail 421-4.7.26 requires all senders to authenticate with either SPF or DKIM. 421-4.7.26 421-4.7.26 Authentication results: 421-4.7.26 DKIM = did not pass 421-4.7.26 SPF [redacted] with ip: [redacted] = did not pass 421-4.7.26 421-4.7.26 For instructions on setting up authentication, go to 421 4.7.26 https://support.google.com/mail/answer/81126#authentication [redacted] - gsmtp (in reply to end of DATA command))
2) Il messaggio è stato inviato da un mittente massivo la cui configurazione ha fallito DKIM:
421 4.7.30 This mail has been rate limited because DKIM does not pass. Gmail requires all large senders to authenticate with DKIM. Authentication results: DKIM = did not pass
3) Il messaggio potrebbe aver passato SPF e/o DKIM, ma nessuno dei due era allineato col dominio From visibile, come richiesto da DMARC:
421 4.7.32 This mail has been rate-limited because there is no DMARC alignment
4) Google ha inoltre iniziato a restituire il codice 550 per email non conformi, simile al punto 1 ma non più una temporanea deferral:
Error: 550-5.7.26 Your email has been blocked because the sender is unauthenticated. Gmail requires all senders to authenticate with either SPF or DKIM. Authentication results: DKIM = did not pass SPF [example.com]= did not pass
Se visualizzi questi messaggi, ti consigliamo di risolvere al più presto questi errori per evitare che la tua posta venga bloccata quando i requisiti entreranno in vigore a giugno.
Come Red Sift può aiutarti a prepararti
Se vuoi un modo semplice per verificare che i tuoi domini mittenti siano pronti e conformi come bulk sender, Red Sift lo rende facile.
In meno di un minuto, il nostro tool Investigate gratuito controlla il tuo stato di conformità e ti fornisce un riepilogo visivo di ciò che devi sistemare.
Tutto ciò che serve per iniziare con Red Sift Investigate è inviare un’email a una casella di test.
I migliori strumenti di validazione
I migliori strumenti per convalidare che supererai i nuovi requisiti per bulk sender
Oggi la maggior parte dei team utilizza diversi strumenti per assicurarsi che tutti i domini e servizi mittenti siano conformi ai nuovi requisiti. Abbiamo raccolto qui di seguito un elenco degli strumenti a tua disposizione.
Red Sift Investigate
Red Sift Investigate è l’unico strumento gratuito sul mercato che può confermare che il tuo dominio sia autenticato e che hai le corrette misure di disiscrizione per superare i nuovi requisiti di Microsoft, Google e Yahoo.
Ciò che distingue Red Sift Investigate è che, tramite un’email di test, lo strumento può esaminare la prontezza di ciascuno dei tuoi servizi di invio email. Invia una email di test da ciascun servizio, e Red Sift Investigate potrà valutare l’infrastruttura di invio/ricezione, analizzare le intestazioni del messaggio e valutare in tempo reale lo stato della cifratura delle email.
Così, gli utenti possono capire se servizio e dominio mittente rispettano i seguenti criteri:
- Autenticazione SPF e DKIM
- Allineamento SPF o DKIM
- Un record DMARC valido con almeno una policy p=none
- Connessione TLS per trasmissione email (nuovo requisito da dicembre 2023)
- Record DNS forward e reverse validi
- Annullamento iscrizione con un solo clic incluso nel messaggio
Tutto ciò che serve per iniziare con Red Sift Investigate è inviare un’email a una casella di test.
Molti strumenti gratuiti online come MX Toolbox possono visionare i tuoi record DNS per vedere se hai un record SPF e DMARC valido. Poiché le informazioni su DMARC, SPF e DKIM sono pubbliche, questi strumenti partono dal tuo dominio per vedere se esiste un record DMARC valido pubblicato nel DNS. Tuttavia, questi strumenti non necessariamente confermano che tu abbia il record SPF corretto e l’allineamento per ciascuno dei servizi mittenti. Questo può essere testato solo attraverso un invio manuale.
Questi strumenti sono utili per le organizzazioni che hanno dubbi solo sulla configurazione DMARC. Dal momento che si basano solo sul DNS, non possono dare informazioni su allineamento SPF o DKIM, FCrDNS, connessione TLS o presenza della funzionalità di disiscrizione con un clic.
Verifica manuale delle intestazioni email
Per chi ha una buona conoscenza della sicurezza email e i giusti permessi in azienda, potrebbe essere possibile controllare la prontezza ai nuovi requisiti con una verifica manuale.
Questo comporterebbe l’invio di una email di test da ogni servizio di posta verso una casella cui il soggetto ha accesso ed esaminare le intestazioni per verificare la presenza delle informazioni richieste dai nuovi requisiti. Per le grandi aziende questo può diventare velocemente laborioso, dato il numero tipico di servizi di invio email.
Nota importante sul controllo dei tassi di spam
I tassi di spam dipendono dai dati storici e quindi non possono essere verificati con uno strumento in tempo reale o statico. Ciò detto, Google e Yahoo offrono ottimi strumenti gratuiti per assicurarti che il tuo tasso di spam non raggiunga mai lo 0,30% o più.
Microsoft Smart Network Data Services (SNDS)
Smart Network Data Services (SNDS) di Outlook.com ti offre i dati necessari per comprendere e migliorare la tua reputazione su Outlook.com. Analogamente alle sue controparti Google & Yahoo, permette di aggiungere i tuoi IP e vedere la reputazione e i reclami generati.
Google Postmaster Tools
Google Postmaster Tools traccia i dati su grandi volumi di email inviate per assicurare che il tuo dominio mittente sia sempre sano. Postmaster Tools mostra il tasso di spam secondo la percentuale di email segnalate come spam dagli utenti rispetto alle email recapitate in inbox per utenti attivi. Questo strumento richiede la verifica del dominio e può mostrare dati utili solo in base al tempo trascorso dalla verifica. Un trucco: se verifichi il dominio di primo livello puoi aggiungere anche tutti i sottodomini senza doverli verificare individualmente tramite record DNS.
Nel marzo 2024 Google ha rilasciato una dashboard Compliance Status all’interno di Google Postmaster. Da qui puoi verificare la conformità dei tuoi domini ai requisiti per bulk sender.
Yahoo Complaint Feedback Loop
Con il Complaint Feedback Loop (CFL) di Yahoo, gli speditori riceveranno i reclami inoltrati dagli utenti che segnalano un messaggio come spam. Queste segnalazioni consentono alle organizzazioni di escludere i destinatari da future campagne, e rivedere targeting e frequenza per ridurre reclami. Questo programma richiede la verifica del dominio tramite DKIM.
A maggio 2024 Yahoo ha annunciato una nuova Sender Hub Dashboard, un portale dove "gli speditori email possono visualizzare e gestire i servizi Yahoo associati al proprio brand". È accessibile qui.
Cosa fare ora
Il passo successivo per tutte le organizzazioni che inviano grandi volumi di posta è agire. Usa uno degli approcci illustrati sopra e verifica che domini e servizi mittenti siano conformi.
Se ti rendi conto che devi apportare modifiche per essere conforme, prova Red Sift OnDMARC, il nostro pluripremiato strumento DMARC che rende semplice ed efficiente la configurazione e l’implementazione di DMARC, SPF e DKIM.
Cosa devono sapere i marketer
Se sei un marketer e vuoi garantire che le tue email arrivino costantemente nella casella di posta di Microsoft, Google o Yahoo, è importante essere a conoscenza dei cambiamenti in arrivo e rivedere subito le tue pratiche di invio. In questo articolo analizzeremo i requisiti, spiegheremo cosa significano e ti aiuteremo a ottenere informazioni in tempo reale su come è configurato il tuo sistema email grazie al nostro strumento gratuito Bulk Sender Compliance Checker, Red Sift Investigate.
Perché Microsoft, Google e Yahoo hanno introdotto questi cambiamenti?
Google e Yahoo hanno introdotto per primi requisiti per l’invio massivo di email, con l'obiettivo di migliorare l’esperienza degli utenti e contribuire a caselle di posta più sicure e meno piene di spam. Lo scopo è quello di evitare che le caselle siano sommerse da email indesiderate o potenzialmente pericolose e assicurare che i destinatari ricevano solo le email che desiderano leggere.
Nell’aprile 2025 anche Microsoft ha adottato requisiti per i mittenti ad alto volume indirizzati agli indirizzi Outlook.com, Hotmail.com e Live.com.
A chi si applicano?
Se invii newsletter, email su aggiornamenti di prodotto o qualsiasi comunicazione promozionale a più di 5.000 indirizzi Microsoft, Google e/o Yahoo, questi nuovi requisiti valgono anche per te.
I marketer B2C dovrebbero porre particolare attenzione, dato che è probabile che il loro database email sia principalmente composto da indirizzi personali, con la maggioranza su gmail.com. Gmail detiene una quota di mercato del 30% tra i client di posta (che rappresenta quasi un quarto della popolazione mondiale che utilizza l'email), quindi la conformità per l’invio massivo è fondamentale se ti affidi all’email per comunicare.
Ok, quali sono i requisiti?
Le linee guida per l’invio massivo di email ruotano attorno a tre pilastri fondamentali:
- Rendi semplice per le persone smettere di ricevere le tue email: gli invii massivi dovranno offrire un link di disiscrizione visibile nelle comunicazioni di marketing/commerciali e gestire le richieste di cancellazione entro due giorni.
- Non fare spam: sarà fissato un chiaro limite di spam allo 0,3% per tenere fuori dalla casella di posta i messaggi indesiderati. (Questo requisito riguarda solo Google e Yahoo, ma lo consigliamo come best practice a prescindere dal provider.)
- Autentica i domini di invio: Microsoft, Google e Yahoo richiederanno standard di sicurezza best practice, tra cui SPF, DKIM e DMARC. Confuso dalle sigle? Spiegheremo tutto qui sotto.
Per cominciare, analizziamo prima i requisiti più immediati — link di disiscrizione e tasso di spam — e vediamo perché sono vantaggiosi per chi fa marketing.
Includi link di disiscrizione con un clic
La disiscrizione con un clic è una pratica ampiamente adottata nell’email marketing. È obbligatoria secondo CAN-SPAM, CASL e GDPR, quindi non sorprende che anche Microsoft, Google e Yahoo stiano imponendo marketing via email basato sul consenso.
La maggior parte delle piattaforme di invio email offre di default la disiscrizione con un clic, tra cui Hubspot, Mailchimp e customer.io. Tuttavia, verifica sempre tutte le piattaforme che utilizzi per assicurarti di essere conforme.
Usa il nostro Bulk Sender Compliance Checker gratuito, Red Sift Investigate, per verificare se il tuo servizio email ha la funzione di disiscrizione
Mantieni basso il tasso di spam
Google è la prima azienda del settore a rendere obbligatorio il mantenimento del tasso di spam segnalato sotto lo 0,10%, senza mai raggiungere lo 0,30%. Yahoo si è allineata su questa posizione.
È importante ricordare che, per un utente, segnalare un messaggio come spam è molto semplice. Proprio per questo, è fondamentale che i destinatari ricevano contenuti utili e coinvolgenti, ai quali abbiano aderito. Ti consigliamo inoltre di pulire, segmentare e aggiornare regolarmente le tue liste per mantenere una buona reputazione di mittente e vedere le mail consegnate nella posta in arrivo, non nello spam.
Tutti e tre i provider offrono ottimi strumenti gratuiti per aiutare chi invia grandi quantità di email a monitorare regolarmente le proprie performance: scopri Microsoft’s Smart Network Data Services (SNDS), Google’s Postmaster Tools e il programma Complaint Feedback Loop (CFL) di Yahoo.
Autenticazione del dominio
I requisiti di autenticazione email—SPF, DKIM e DMARC—sono il fulcro della sicurezza email moderna. Consentono di evitare che attori malevoli usino il tuo dominio di invio per inviare mail a tuo nome. Anche se per un marketer questi standard possono sembrare complessi, non implementarli può avere gravi ripercussioni sia sulla sicurezza che sulla deliverability. Inoltre, non è previsto che tu debba occupartene: qui entra in gioco il tuo team IT! Ne parleremo più avanti.
Nella tabella seguente trovi una panoramica dei vari requisiti e dei vantaggi associati.
Requisiti di autenticazione e vantaggi
Requisito di autenticazione | Vantaggio |
Configura SPF e DKIM per ogni dominio che invia email | Migliora l’integrità dell’email e la verifica del mittente. |
Invia con un dominio `From` allineato in SPF o DKIM | Senza allineamento, rischi che le tue email finiscano nello spam invece che nella posta in arrivo del destinatario. |
Pubblica una policy DMARC per ogni dominio che invia email | Blocca i tentativi di impersonificazione del tuo dominio email e impedisce che siano inviate email di phishing a tuo nome. |
Assicurati che i domini o gli IP di invio abbiano FcrDNS configurato | Favorisce la deliverability delle email. Senza FCrDNS, alcuni mailbox provider possono bloccare o consegnare la posta nello spam. |
Usa una connessione TLS per inviare le email | Evita che malintenzionati intercettino le tue email. |
Siamo certi che, dopo aver visto questi vantaggi, ogni email marketer esperto li consideri strumenti indispensabili nel proprio arsenale – a prescindere dall’obbligatorietà.
Per un approfondimento sull’autenticazione email, ti consigliamo la nostra ultima guida: “Perché il successo dell’email marketing dipende dall’autenticazione delle email”.
Cosa dovresti fare adesso?
Il primo step è verificare se il tuo servizio email rispetta i requisiti per l’invio massivo.
Red Sift ti semplifica la vita – in meno di 60 secondi, il nostro Bulk Sender compliance checker gratuito, Red Sift Investigate, ti dice se la tua configurazione email è ottimale.
Basta inviare una mail di test a un indirizzo univoco che ti forniamo, poi analizziamo la tua configurazione in modo dinamico e in tempo reale. Riceverai anche una copia dei risultati da inoltrare al tuo team IT per chiedere supporto alla configurazione!
Come chiedere aiuto al team IT
I marketer possono occuparsi direttamente di alcuni requisiti per l’invio massivo. Puoi verificare la presenza della disiscrizione con un clic sulle tue piattaforme e monitorare il tasso di spam con Google Postmaster Tools e il programma CFL di Yahoo. Circa il 90% dei provider usa già TLS, ma se non fosse così deve essere il fornitore di servizi email (ESP, come Hubspot o Mailchimp) a configurarlo.
Per i requisiti di autenticazione email, ti consigliamo di rivolgerti al team IT. In questa guida dedichiamo una sezione pratica su come coinvolgere correttamente il team IT per assicurare il successo sull’invio massivo: scorri al capitolo successivo!
La tabella qui sotto ti aiuterà a capire quali requisiti si configurano a livello di ESP e/o a livello di dominio.
È importante ricordare che se la tua azienda usa diversi ESP, dovrai configurare questi elementi su ogni piattaforma. Lo stesso vale se si usano più domini.
Dove vanno configurati i requisiti?
Requisito | Configurato a livello ESP/Piattaforma | Configurato a livello DNS |
Implementazione sia di SPF che di DKIM | Sì | Sì |
Invio con dominio `From` allineato in SPF o DKIM | Sì | Sì |
Invio da un dominio con policy DMARC di almeno p=none (incluso tag RUA, come raccomanda Yahoo*) | No | Sì |
Uso di connessione TLS per l’invio email | Sì | No |
DNS forward e reverse valido (FCrDNS) | Sì | Sì |
Disiscrizione con un clic (RFC 8058) | Sì | No |
Basso tasso di segnalazione spam | Sì | No |
Dove andare da qui?
Adattarsi al nuovo scenario dell’invio massivo sarà un processo continuativo. Devi assicurarti che i tuoi contenuti siano di valore per evitare di finire nello spam, che la tua strategia email sia basata sul consenso e lavorare a stretto contatto con il team IT per garantire l’autenticazione corretta di tutte le fonti email attuali e future.
Anche se oggi basta una policy DMARC p=none, è bene tenere sotto controllo possibili aggiornamenti futuri. Il prossimo passo potrebbe essere l’obbligo di p=reject per DMARC, molto più stringente rispetto alla policy attuale. Secondo le best practice del settore per il 2026, si consiglia già di raggiungere p=reject per una protezione totale.
Ti consigliamo di salvare tra i preferiti le linee guida di Microsoft, Google e Yahoo, di seguire il nostro blog per restare aggiornato sulle ultime novità e normative, e di usare regolarmente il nostro Bulk Sender compliance checker gratuito, Red Sift Investigate, così da assicurarti la conformità su tutti i tuoi servizi di invio email.
Come i marketer possono collaborare con i team di sicurezza
Il nostro team marketing di Red Sift ha lavorato in diversi contesti della cybersecurity. Questa esperienza ci ha fornito spunti concreti su come collaborare efficacemente tra marketing e security. In questo capitolo, vogliamo condividere le strategie che abbiamo usato per allineare le attività di marketing alle iniziative di sicurezza.
Con i requisiti di invio massivo di Microsoft in arrivo e quelli di Google e Yahoo già attivi, è il momento ideale per mettere in pratica questi suggerimenti e garantire la conformità senza perdere deliverability.
Step 1: Non pensare alla sicurezza come il reparto dei "no"
Spesso la sicurezza sembra un reparto lontano che blocca l’accesso agli strumenti preferiti. In realtà non è così.
I team di sicurezza sono spesso sotto organico e gestiscono continue emergenze - la maggior parte delle quali non riguarda il marketing. La tua sarà solo una delle richieste urgenti che riceveranno questa settimana.
Tuttavia ogni responsabile della sicurezza mira sempre al bene dell’azienda. Se presenti la questione come un’esigenza di business, e non solo un “nice to have”, diventeranno alleati preziosi.
Step 2: Capisci esattamente cosa serve all’azienda
Il modo più semplice per capire se serve l’aiuto della sicurezza è usare uno strumento per esaminare la configurazione email corrente e verificare se soddisfa i requisiti.
Noi di Red Sift prediligiamo Red Sift Investigate – l’unico tool gratuito che può vedere se la tua infrastruttura email è conforme ai nuovi requisiti di Microsoft, Google e Yahoo.
Basta inviare una mail di test dal tuo strumento di invio massivo (come Hubspot, Mailchimp o Customer.io) a Red Sift Investigate. Riceverai dei risultati da condividere con il team di sicurezza per capire cosa è necessario fare per rispettare la normativa.
I risultati verranno visualizzati con una spunta verde dove sei conforme e una x rossa dove devi intervenire.


Se vuoi approfondire, ci sono altri strumenti utili. Scopri il nostro capitolo sugli strumenti qui.
Step 3: Sii specifico nella richiesta al team di sicurezza
Con i risultati di Red Sift Investigate in mano, sei nella posizione migliore per capire cosa fare per autenticare il tuo dominio.
Se hai dei dubbi sugli errori che vedi - o vuoi semplicemente essere chiaro per il tuo team di sicurezza - consulta la nostra matrice che spiega meglio il significato degli errori trovati. Da lì, puoi formulare una richiesta precisa.
Per esempio, se i risultati di Red Sift Investigate sono simili a questi:


E nella matrice leggi che questo significa “È richiesto un record DMARC.”
Puoi mostrare tutto al team di sicurezza e chiedere come collaborare per impostare il record corretto.
📢Non dimenticare di testare tutti i tuoi servizi email: solo perché la mail di prova di Hubspot va a buon fine, non vuol dire che quella di Mailchimp lo farà.
Step 4: Collega la richiesta a risultati di business
Come già detto, il team di sicurezza ha una lista infinita di priorità, e questa potrebbe non essere in cima. Ma ora è il momento di agire e una buona comunicazione fa la differenza.
Basta una breve ricerca per costruire un caso solido. Considera ad esempio:
- Quanti ricavi ha generato l’email lo scorso anno?
- Quante nuove opportunità o clienti sono arrivate grazie all’ultimo touchpoint email?
- Quanto costerebbe una scarsa deliverability all’azienda?
- Che percentuale di database sarebbe irraggiungibile se non si rispettassero questi requisiti?
Motivare la richiesta dimostrando l’impatto sul business fornisce al team sicurezza una ragione per agire in fretta.
Altri ESP stanno cambiando i requisiti di autenticazione?
Sì. A settembre 2025, il provider francese Laposte.net ha alzato i requisiti di autenticazione. Dal 2026, l’autenticazione sta diventando uno standard globale tra i provider.
Il 100% delle email non autenticate — prive di SPF, DKIM o DMARC — finirà nello spam. In altre parole, SPF, DKIM e DMARC non saranno più opzionali per chi vuole assicurarsi la consegna in inbox.
Monitoreremo con attenzione gli aggiornamenti da Laposte.net e da altri provider, e questa guida verrà aggiornata con ogni nuovo requisito annunciato.
Cosa fare adesso?
Non farti cogliere impreparato: inizia oggi con Red Sift Investigate e coinvolgi subito il team di sicurezza per avviare la collaborazione. Siamo qui per aiutarti e puoi sempre parlare con un esperto Red Sift per iniziare subito il tuo percorso verso la conformità per Microsoft, Google e Yahoo.
Controlla la tua conformità all’invio massivo con Red Sift Investigate. Tutto ciò che devi fare è inviare una mail di prova!




