Le tue email in uscita tornano indietro con codici di errore 550? I destinatari segnalano che i tuoi messaggi finiscono nella cartella spam invece che in posta in arrivo? C'è una ragione precisa. Nel febbraio 2024 Google e Yahoo hanno smesso di considerare facoltativa l'autenticazione delle email: oggi è un requisito obbligatorio. Per qualsiasi azienda che dipende dalla posta elettronica, ignorare questi cambiamenti danneggerà la recapitabilità e, con essa, i ricavi.

Punti chiave:

• Google e Yahoo richiedono ai mittenti in bulk di autenticare la posta in uscita con SPF e DKIM e di pubblicare un record DMARC.
• La soglia dei 5.000 messaggi al giorno per i mittenti in bulk comprende tutto il traffico combinato sul dominio principale.
• I tassi di segnalazione spam in Google Postmaster Tools devono rimanere sotto lo 0,1%; raggiungere lo 0,3% attiva penalità automatiche di recapitabilità sui gateway di ricezione.
• Le email di marketing e le newsletter devono supportare le intestazioni di disiscrizione con un clic secondo la RFC 8058.
• Iniziare con p=none soddisfa la conformità di base, ma passare a p=quarantine o p=reject è importante per prevenire lo spoofing del dominio e costruire la reputazione del dominio a lungo termine.

Cosa è cambiato e perché: le nuove regole di Gmail/Yahoo

Perché esistono queste regole? La causa principale risiede in come la posta elettronica è stata originariamente costruita. Il Simple Mail Transfer Protocol (SMTP), standardizzato nel 1982 tramite la RFC 821, non aveva alcun meccanismo nativo per verificare l'identità del mittente. Qualsiasi server di posta poteva trasmettere un messaggio che dichiarava di provenire da un qualsiasi indirizzo email, e i gateway di ricezione lo accettavano: chiunque poteva quindi falsificare un nome di dominio nell'intestazione visibile con poco sforzo.

Nel corso degli anni gli ingegneri della sicurezza hanno corretto questa lacuna strutturale. SPF è arrivato a metà degli anni 2000 per convalidare gli indirizzi IP di invio rispetto a un elenco DNS pubblico. DKIM è seguito, usando la crittografia a chiave pubblica per consentire ai mittenti di firmare le intestazioni in uscita. Nel 2012 i principali attori del settore hanno pubblicato DMARC per collegare i controlli SPF e DKIM e dare ai proprietari di domini un modo per impostare policy di applicazione.

Per anni i provider di posta hanno trattato questi standard come facoltativi. I domini con SPF e DKIM guadagnavano punti bonus; quelli senza di essi di solito raggiungevano comunque la posta in arrivo, purché l'indirizzo IP fosse pulito.

Questo è terminato nel febbraio 2024. Come stabilito nelle linee guida per i mittenti di Google, i provider di posta hanno trasformato l'autenticazione da suggerimento utile in requisito di accesso vincolante.

Invece di bloccare tutto in una volta la posta non autenticata, i provider hanno applicato le regole in modo graduale. All'inizio del 2024 hanno iniziato a rallentare le velocità di connessione e a restituire codici temporanei di rinvio 4xx sui flussi non autenticati. Nei mesi successivi sono passati a codici di rifiuto 5xx rigorosi e al posizionamento automatico nella cartella spam. Microsoft ha rapidamente allineato i filtri del proprio gateway agli stessi standard per i mittenti ad alto volume e ha successivamente annunciato che Outlook.com applicherà requisiti comparabili di SPF, DKIM e DMARC ai mittenti in bulk nel 2025 — un segnale che queste regole stanno diventando una baseline a livello di settore e non solo una policy di Google e Yahoo.

Chi è considerato mittente in bulk secondo le linee guida Gmail

Google definisce mittente in bulk qualsiasi dominio che invii circa 5.000 o più messaggi in una finestra di 24 ore a account Gmail personali; Yahoo applica uno standard simile. Ma concentrarsi solo su quel numero è un errore comune.

Innanzitutto, il volume è calcolato sull'intero dominio radice, non per indirizzo IP o nome host del server. Se una piattaforma di marketing invia 3.500 newsletter mentre un server applicativo invia 2.000 reset di password o ricevute di fattura sotto lo stesso dominio, la soglia è stata superata.

In secondo luogo, la regola si applica a tutta la posta in uscita, non solo a quella di marketing. Le notifiche di sistema, le ricevute dei clienti e le email aziendali quotidiane concorrono tutte al limite giornaliero. Qualsiasi dominio che invii vicino a 3.000 messaggi al giorno dovrebbe configurare l'autenticazione completa come se avesse già superato il limite.

I requisiti fondamentali per i mittenti

Per soddisfare i requisiti dei mittenti in bulk di Google e Yahoo, l'infrastruttura email deve superare sei verifiche tecniche:

1. Configurare record SPF validi e coppie di chiavi DKIM per tutti i flussi di posta in uscita.
2. Pubblicare un record TXT DMARC valido nel DNS del dominio.
3. Assicurarsi che il dominio nell'intestazione visibile "From:" corrisponda al dominio autenticato da SPF o DKIM.
4. Mantenere i tassi di segnalazione spam degli utenti sotto lo 0,1% in Google Postmaster Tools e non farli mai raggiungere lo 0,3%.
5. Includere intestazioni native di disiscrizione con un clic su tutta la posta di marketing e le newsletter.
6. Assicurarsi che gli IP dei server di invio abbiano record A/AAAA corrispondenti e record DNS inverso (PTR) validi.

Cosa succede in caso di mancata conformità

Il fallimento dei controlli di autenticazione danneggia la reputazione del dominio presso i server di posta riceventi, tipicamente in tre fasi:

1. I server riceventi rispondono con codici di rinvio 4xx; le code del server di posta si riempiono e la consegna viene ritardata di ore.
2. I messaggi attraversano il gateway ma vengono reindirizzati nella cartella spam del destinatario invece che nella posta in arrivo principale.
3. I server di posta interrompono del tutto la connessione e restituiscono errori di hard bounce 5xx.

Come soddisfare ogni requisito: passo per passo

1. Configurare SPF e attenzione al limite di 10 lookup

Aggiungere un record TXT DNS alla radice del dominio che elenchi ogni indirizzo IP autorizzato e ogni fornitore di posta di terze parti. Attenzione al limite di 10 lookup DNS: la RFC di SPF limita i record a un massimo di 10 query DNS esterne (include, a, mx, redirect). Superare questo limite causa un PermError SPF, che i server riceventi trattano come un fallimento di autenticazione. Controllare periodicamente il record e rimuovere gli include obsoleti dei fornitori per restare sotto il limite.

2. Configurare la firma DKIM su tutti i canali in uscita

DKIM firma le intestazioni delle email in uscita con una firma crittografica e deve essere abilitato su ogni piattaforma che invia posta per conto del dominio. Generare una coppia di chiavi DKIM a 2048 bit nel portale del servizio email e pubblicare la chiave pubblica come record CNAME o TXT nel DNS. Una volta propagato il DNS, abilitare la firma nella console di amministrazione e ispezionare le intestazioni grezze di un'email di prova per confermare che l'intestazione DKIM-Signature sia presente e superata.

3. Pubblicare un record DMARC

Per soddisfare il requisito DMARC di base imposto da Gmail e Yahoo, pubblicare un record TXT DMARC su _dmarc.yourdomain.com. Le prime configurazioni dovrebbero iniziare con una policy di monitoraggio (p=none) per raccogliere dati di report senza rischiare la consegna della posta. Prima di andare in produzione, testare la voce DNS con un verificatore di record DMARC pubblico per individuare errori di sintassi.

4. Aggiungere le intestazioni di disiscrizione con un clic RFC 8058

Un semplice link HTML di disiscrizione in fondo all'email non è sufficiente per la posta di marketing. Due intestazioni grezze devono essere inserite nel flusso in uscita:

List-Unsubscribe:
List-Unsubscribe-Post: List-Unsubscribe=One-Click

Quando client come Gmail o Yahoo interpretano queste intestazioni, mostrano un pulsante "Annulla iscrizione" ben visibile accanto al nome del mittente nell'interfaccia della posta in arrivo. Cliccandolo viene inviata una richiesta POST automatica al server, che rimuove immediatamente l'iscritto senza aprire una finestra del browser.

5. Verificare il DNS diretto e inverso

I server riceventi controllano che l'indirizzo IP di invio corrisponda al dominio nel DNS. L'IP deve risolvere verso un nome host valido tramite un record PTR e quel nome host deve risolvere di nuovo verso lo stesso IP tramite un record DNS A standard. Chi gestisce server di posta dedicati o istanze cloud può modificare le impostazioni del DNS inverso nella console del provider o aprire un ticket di supporto per mappare l'IP al nome di dominio completo (FQDN) del server di posta.

6. Monitorare le metriche in Postmaster Tools e nei report DMARC

Creare un account Google Postmaster Tools e verificare la proprietà del dominio tramite un record TXT DNS. La dashboard offre visibilità diretta sulla reputazione del dominio, sui tassi di segnalazione spam e sulle percentuali di successo dell'autenticazione. Mantenere il tasso di segnalazione sotto lo 0,1%; raggiungere lo 0,3% porta Google a instradare la posta nella cartella spam indipendentemente dallo stato di SPF e DKIM. Per monitorare i fallimenti di autenticazione su tutti i provider riceventi e individuare IP di invio non autorizzati, configurare il reporting DMARC automatizzato.

Oltre la conformità: usare le regole per migliorare la recapitabilità

Una policy p=none da sola lascia il dominio senza protezione contro lo spoofing: indica ai server riceventi di registrare i dati di autenticazione, ma non impedisce agli aggressori di impersonare il dominio in attacchi di phishing.

Una volta confermato che tutti i flussi di posta legittimi superano l'allineamento SPF e DKIM, aggiornare la policy DMARC a p=quarantine o p=reject. p=quarantine instrada la posta non autenticata direttamente nella cartella spam, mentre p=reject scarta i messaggi falsificati al gateway di ricezione.

Dopo aver raggiunto l'applicazione DMARC, i mittenti possono pubblicare i Brand Indicators for Message Identification (BIMI), che mostrano un logo del brand verificato accanto ai messaggi nella posta in arrivo dei destinatari, aumentando visibilità e fiducia nel brand.

Domande frequenti sui requisiti per i mittenti in bulk

Qual è la soglia per i mittenti in bulk di Google e Yahoo?

Google e Yahoo definiscono mittenti in bulk i domini che inviano ~5.000 o più messaggi al giorno a account personali. Il volume è calcolato sull'intero dominio principale, sommando tutti i servizi di invio.

Queste regole si applicano anche alle email transazionali?

Sì. Le email transazionali come i reset di password, gli aggiornamenti d'ordine e gli avvisi di sistema devono superare i controlli SPF, DKIM, DMARC e DNS, anche se non richiedono le intestazioni di disiscrizione con un clic.

Una policy DMARC p=none è sufficiente per essere conformi?

Sì, p=none soddisfa i requisiti di base per Google e Yahoo. Tuttavia, monitora soltanto il traffico senza bloccare le impersonazioni, quindi è consigliabile passare a p=quarantine o p=reject.

Cosa succede alle mie email se non soddisfo i requisiti?

I provider di posta limiteranno le connessioni SMTP con codici di errore 4xx, instraderanno le email direttamente nella cartella spam o emetteranno hard bounce 5xx che respingono la posta del tutto.

Quanto tempo serve per riprendersi da tassi di segnalazione spam elevati?

Una volta corretta l'igiene delle liste e riportato il tasso di segnalazione sotto lo 0,1%, servono in genere da 7 a 14 giorni di invii puliti perché Google Postmaster Tools ricostruisca la reputazione del dominio.

Come verifico se il mio record SPF supera il limite di 10 lookup?

Ispezionare il record TXT SPF e contare ogni meccanismo che attiva un lookup DNS. Se il numero totale di query DNS tra record principale e record annidati supera 10, il record SPF fallirà con un PermError.

Fonte: FinTechZoom