Una mail può partire senza intoppi, comparire nei log di Postfix o Exim come consegnata e poi svanire nel nulla. È il paradosso con cui molti amministratori hanno fatto i conti da quando i grandi provider hanno stretto le regole sull’autenticazione email, mettendo al centro protocolli come DMARC, SPF e DKIM. Google ha aperto le danze a febbraio 2024, Yahoo ha seguito una rotta quasi identica e Microsoft ha chiuso il cerchio imponendo controlli più severi verso Outlook.com, Hotmail e Live.com. Chi spedisce migliaia di messaggi al giorno con una configurazione approssimativa rischia blocchi immediati e problemi di recapito difficili da scovare.
La posta elettronica resta uno dei canali più sfruttati per phishing, spoofing e frodi aziendali. Una fetta consistente delle campagne malevole, stando ai report dei grandi operatori del settore, gira attorno a domini contraffatti o identità all’apparenza legittime. I protocolli di autenticazione DNS nascono proprio per arginare questo fenomeno. Per anni molti provider hanno chiuso un occhio sulle configurazioni incomplete. Adesso quella tolleranza si è praticamente esaurita.
Microsoft allinea le sue policy a Google e Yahoo
Dal 5 maggio 2025 Microsoft ha cominciato a respingere parte dei messaggi provenienti da domini che non rispettano determinati requisiti di autenticazione, quando il volume supera i 5.000 messaggi giornalieri verso indirizzi consumer. Parliamo di account Outlook.com, Hotmail, Live e MSN. La vera novità non è la presenza dei controlli, già attivi da anni nei sistemi antispam, ma il livello di severità con cui vengono applicati. Un dominio che non passa le verifiche può incassare l’errore 550 5.7.515, comportamento che Microsoft ha documentato nelle proprie pagine di supporto. E quella soglia dei 5.000 messaggi non è alta come sembra: un negozio WooCommerce con recupero carrelli abbandonati, notifiche ordine, email promozionali e comunicazioni ai clienti la raggiunge in fretta, anche senza essere una grande azienda.
SPF, DKIM e DMARC: cosa controllano davvero i provider
SPF stabilisce quali server possono spedire posta per conto di un dominio. L’informazione vive in un record TXT del DNS che parte di solito con la stringa v=spf1. Quando un server riceve un messaggio, verifica che l’IP del mittente sia autorizzato dalla policy pubblicata.
DKIM aggiunge una firma crittografica al messaggio. Il server mittente firma alcune intestazioni e parti del contenuto con una chiave privata; il destinatario recupera dal DNS la chiave pubblica e controlla l’integrità della firma. Basta una modifica lungo il tragitto e la validazione salta. DMARC mette un altro mattone: oltre a verificare SPF e DKIM, controlla l’allineamento tra il dominio mostrato nel campo From e quello che ha effettivamente superato i controlli. Ed è qui che casca l’asino in tante installazioni reali. Avere SPF o DKIM a posto non basta sempre: se il dominio autenticato non coincide con quello che vede il destinatario, DMARC fallisce comunque. Microsoft, su questo parametro, è particolarmente esigente.
Le configurazioni di hosting condiviso sono spesso il punto più fragile. Certi domini non pubblicano alcun record SPF, altri si appoggiano a servizi esterni per newsletter, CRM o email transazionali senza aggiornare il DNS. Il servizio terzo spedisce messaggi legittimi, ma da IP non autorizzati. Capita di continuo con piattaforme come Mailchimp, Brevo, SendGrid o Amazon SES: si configura la spedizione, si imposta un indirizzo personalizzato e si considera il lavoro finito. In realtà mancano ancora le chiavi DKIM personalizzate o l’allineamento richiesto da DMARC.
Verifiche e trappole da conoscere
Pannelli come cPanel, Plesk e ISPConfig generano automaticamente chiavi DKIM RSA da 1024 o 2048 bit, ma l’attivazione non è sempre automatica e il record pubblico deve comparire nel DNS autorevole. Una verifica rapida si fa da terminale con il comando dig, interrogando il record TXT del dominio per SPF, il sottodominio dedicato per DMARC e lo schema basato sul selector per DKIM. Attenzione ai record SPF multipli: sono un errore che manda all’aria la validazione.
C’è poi il limite dei dieci lookup SPF, fissato dalla RFC 7208. Ogni include richiamato può generare altre interrogazioni a catena e, superate le 10, il controllo termina con un PermError che alcuni server interpretano come fallimento. Il guaio salta fuori soprattutto nelle realtà che usano insieme Microsoft 365, Google Workspace, piattaforme newsletter, CRM e servizi transazionali: ogni nuovo fornitore chiede il suo include e il record si gonfia senza che nessuno se ne accorga. Strumenti come MXToolbox, EasyDMARC e DMARC Analyzer aiutano a smascherare errori meno visibili, dai record SPF validi ma incompleti alle policy DMARC senza alcun indirizzo per i report.
La prova del nove resta una sola: spedire un messaggio reale verso Gmail, Outlook.com o Microsoft 365 e leggere le intestazioni complete. Gmail mostra senza giri di parole se i controlli risultano PASS o FAIL; Outlook e Microsoft 365 riportano dati analoghi negli header Authentication-Results. Il DNS può sembrare perfetto mentre il server continua a spedire senza firma DKIM o con un dominio diverso da quello nel campo From.