Microsoft adotta DMARC: cosa cambia per la sicurezza email

Un messaggio email può lasciare correttamente il server SMTP, comparire nei log di Postfix o Exim senza errori e sparire comunque nel nulla. È una situazione che molti amministratori hanno iniziato a notare dopo le nuove regole introdotte dai principali provider di posta. Google ha aperto la strada a febbraio 2024, Yahoo ha seguito una linea molto simile e Microsoft ha completato il quadro imponendo controlli più rigidi verso Outlook.com, Hotmail e Live.com. Chi invia migliaia di messaggi al giorno senza una configurazione corretta di SPF, DKIM e DMARC rischia blocchi immediati e problemi di recapito difficili da individuare.

La posta elettronica continua a rappresentare uno dei vettori più sfruttati per phishing, spoofing e frodi aziendali. Secondo diversi report pubblicati negli ultimi anni dai grandi operatori del settore, una quota rilevante delle campagne malevole sfrutta domini contraffatti o identità apparentemente legittime. I protocolli di autenticazione DNS nascono proprio per limitare questo fenomeno. Per molto tempo molti provider hanno tollerato configurazioni incomplete; oggi la tolleranza si riduce rapidamente.

Microsoft allinea le proprie policy a Google e Yahoo

Dal 5 maggio 2025 Microsoft ha iniziato a rifiutare parte dei messaggi provenienti da domini che non rispettano specifici requisiti di autenticazione quando il volume supera circa 5.000 email giornaliere verso indirizzi consumer Microsoft. Parliamo di account Outlook.com, Hotmail, Live e MSN.

La novità non riguarda tanto la presenza dei controlli, già utilizzati da anni nei sistemi antispam, quanto il livello di severità applicato. Un dominio che non supera le verifiche richieste può ricevere il messaggio di errore 550 5.7.515: Microsoft ha documentato ufficialmente questo comportamento nelle proprie pagine di supporto.

Va detto però che la soglia dei 5.000 messaggi giornalieri non è così elevata come potrebbe sembrare. Un negozio WooCommerce con campagne automatiche di recupero carrelli abbandonati, notifiche ordine, email promozionali e comunicazioni ai clienti può raggiungere rapidamente volumi significativi senza essere una grande azienda.

SPF, DKIM e DMARC: cosa controllano realmente i provider

SPF definisce quali server possono spedire posta per conto di un dominio. L’informazione risiede in un record TXT DNS che inizia normalmente con la stringa v=spf1. Quando un server riceve un messaggio controlla che l’indirizzo IP mittente sia autorizzato dalla policy pubblicata.

DKIM introduce invece una firma crittografica nel messaggio. Il server mittente firma alcune intestazioni e parti del contenuto utilizzando una chiave privata; il destinatario recupera dal DNS la chiave pubblica corrispondente e verifica l’integrità della firma. Se qualcuno modifica il messaggio durante il percorso, la validazione fallisce.

DMARC aggiunge un ulteriore strato: oltre a verificare SPF e DKIM, controlla il cosiddetto allineamento tra il dominio visibile nel campo From e il dominio che ha superato i controlli di autenticazione. È proprio questo aspetto che genera molti problemi nelle installazioni reali.

In pratica, avere SPF o DKIM configurati correttamente non sempre basta: se il dominio autenticato non coincide con quello mostrato al destinatario, la validazione DMARC può comunque fallire. Microsoft considera questo parametro particolarmente importante.

Perché molti sistemi condivisi continuano a fallire

Molti amministratori controllano i log del server, vedono la consegna completata e concludono che il problema si trovi altrove. Il fatto è che il server mittente e il sistema destinatario valutano aspetti differenti: il server SMTP verifica la consegna tecnica mentre Outlook, Gmail o Yahoo valutano invece reputazione, autenticazione e coerenza delle intestazioni (header). Lo abbiamo spiegato nell’articolo in cui spieghiamo come configurare il proprio server di posta per l’invio delle email e cosa succede quando ci si trasforma in provider di posta.

Le configurazioni di hosting condiviso rappresentano spesso il caso più delicato: alcuni domini non pubblicano alcun record SPF; altri utilizzano servizi esterni per newsletter, CRM o email transazionali senza aggiornare correttamente il DNS. In questi casi il servizio terzo spedisce messaggi legittimi ma da indirizzi IP non autorizzati.

Una situazione frequente riguarda piattaforme come Mailchimp, Brevo, SendGrid o Amazon SES: l’azienda configura la spedizione, imposta un indirizzo personalizzato e considera il lavoro concluso. In realtà manca ancora la pubblicazione delle chiavi DKIM personalizzate oppure l’allineamento richiesto da DMARC.

Molti pannelli di controllo, inclusi cPanel, Plesk e ISPConfig, consentono di generare automaticamente chiavi DKIM RSA da 1024 o 2048 bit. L’attivazione però non sempre è automatica, inoltre il record pubblico deve comparire correttamente nel DNS autorevole del dominio.

Come verificare rapidamente la configurazione del dominio

Una verifica preliminare richiede pochi minuti. Da terminale, su Linux o da WSL (Windows Subsystem for Linux) è possibile utilizzare il comando dig per interrogare direttamente il DNS:

dig TXT esempio.it

La presenza di v=spf1 identifica il record SPF; tutto ciò che segue definisce quali sistemi possono inviare posta per conto del dominio. Se il comando non restituisce alcun record SPF oppure mostra più record SPF distinti, è necessario intervenire. La presenza di record SPF multipli rappresenta infatti un errore di configurazione che può compromettere la validazione.

DMARC utilizza un sottodominio dedicato chiamato _dmarc. Per verificare la sua presenza basta eseguire:

dig TXT _dmarc.esempio.it

DKIM richiede un controllo leggermente più complesso perché il record DNS dipende dal cosiddetto selector, ovvero un identificatore scelto dal server o dal provider che firma i messaggi. La struttura DNS segue lo schema selector._domainkey.esempio.it. Supponiamo che il selettore sia default: in tal caso il comando sarà:

dig TXT default._domainkey.esempio.it

Un risultato tipico può apparire in questo modo:

v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQ...

La chiave pubblica DKIM si trova all’interno del parametro p= con i provider che utilizzano generalmente chiavi RSA da 2048 bit, considerate più robuste rispetto alle vecchie implementazioni da 1024 bit. Il problema principale è individuare il selettore corretto: in ambienti Microsoft 365 si incontrano spesso selector1 e selector2; in cPanel il nome predefinito può essere default. Mailchimp, Brevo, SendGrid, Amazon SES e altri servizi utilizzano spesso nomi personalizzati.

Come usare MXToolbox e gli altri strumenti online

Gli strumenti web permettono di ottenere una diagnosi ancora più approfondita. MXToolbox, ad esempio, verifica automaticamente SPF, DKIM, DMARC, blacklist e configurazione SMTP. EasyDMARC e DMARC Analyzer forniscono inoltre controlli specifici sull’allineamento DMARC e sulla corretta interpretazione delle policy pubblicate.

Un vantaggio importante consiste nell’individuazione di errori meno evidenti. Ad esempio:

• record SPF sintatticamente validi ma incompleti;
• record DKIM pubblicati nel DNS ma non utilizzati dal server di invio;
• policy DMARC che non prevedono alcun indirizzo per la ricezione dei report;
• problemi di allineamento tra il dominio presente nel campo From e quello utilizzato durante l’autenticazione.

Microsoft mette inoltre a disposizione strumenti di analisi per Microsoft 365 che consentono di verificare configurazioni SPF, DKIM e DMARC direttamente dall’interfaccia amministrativa del tenant (Microsoft 365 Admin Center, Impostazioni, Domini, DNS; per DKIM da Microsoft Defender Portal, Email & Collaboration, Policies & Rules, Threat Policies, Email Authentication Settings, DKIM o direttamente da Microsoft 365 DKIM Management).

Il limite dei dieci lookup SPF: uno dei problemi più frequenti

Molti amministratori configurano SPF aggiungendo progressivamente servizi esterni senza considerare una limitazione prevista dallo standard. La specifica SPF, definita con la RFC 7208, impone un massimo di dieci interrogazioni DNS durante la valutazione del record.

Un record SPF che include diversi include: all’apparenza sembra corretto ma ciascuno di essi può generare ulteriori interrogazioni DNS verso altri record SPF che a loro volta contengono nuovi include:. Quando il numero complessivo supera 10 lookup, il controllo SPF termina con un errore denominato PermError. Alcuni server destinatari trattano questa situazione come un fallimento dell’autenticazione e possono rifiutare il messaggio oppure penalizzarne la reputazione.

Per verificare rapidamente il numero effettivo di lookup è possibile utilizzare strumenti dedicati come MXToolbox SPF Record Check oppure analizzatori SPF online che espandono automaticamente tutti gli include presenti.

Va detto però che il problema emerge soprattutto nelle organizzazioni che utilizzano contemporaneamente Microsoft 365, Google Workspace, piattaforme newsletter, sistemi CRM, software di marketing automation e servizi transazionali. Ogni nuovo fornitore tende a richiedere l’aggiunta di uno o più include SPF e nel tempo il record può diventare sorprendentemente complesso.

La verifica più importante è quella sul messaggio reale

Controllare i record DNS rappresenta soltanto il primo passo: la verifica definitiva consiste nell’inviare un messaggio verso un account Gmail, Outlook.com oppure Microsoft 365 e analizzarne le intestazioni complete.

Nei dettagli del messaggio devono comparire risultati positivi per SPF, DKIM e DMARC. Gmail, ad esempio, mostra chiaramente se i controlli risultano “PASS” oppure “FAIL”. Outlook e Microsoft 365 riportano informazioni analoghe all’interno delle intestazioni Authentication-Results.

In pratica il DNS può apparire perfetto mentre il server continua a spedire messaggi senza firma DKIM oppure utilizzando un dominio diverso da quello visualizzato nel campo From. Per questo motivo la verifica delle intestazioni rimane il controllo più affidabile per capire se l’autenticazione funziona davvero e se il dominio soddisfa i requisiti richiesti dai principali provider di posta elettronica.

La posta autenticata non è più un’opzione

Per anni SPF, DKIM e DMARC sono stati considerati strumenti di hardening consigliati soprattutto alle organizzazioni più strutturate. Oggi la situazione è diversa.

Google applica controlli stringenti dal 2024; Yahoo ha adottato una linea simile e Microsoft ha trasformato l’autenticazione in un requisito operativo concreto per i mittenti ad alto volume. Apple, pur con criteri differenti, filtra da tempo i messaggi che mostrano segnali di autenticazione deboli o incoerenti.

Chi gestisce un dominio aziendale dovrebbe considerare SPF, DKIM e DMARC come componenti essenziali dell’infrastruttura email, al pari del certificato TLS per un sito web. Senza questi elementi la consegna non è più garantita, indipendentemente dalla qualità del server SMTP utilizzato.

La parte insidiosa è che il problema spesso si manifesta quando il danno è già avvenuto: un cliente non riceve una fattura, una richiesta commerciale rimane senza risposta oppure una comunicazione importante non arriva mai a destinazione. Dal punto di vista del destinatario sembra che il mittente non abbia scritto nulla; dal punto di vista del mittente, invece, il messaggio risultava inviato correttamente.