Un’email inviata a un account Outlook.com può essere respinta anche se il dominio del mittente ha SPF e DKIM configurati. Dal 5 novembre, amministratori e provider di posta segnalano rifiuti su Outlook.com, Hotmail, Live e MSN quando manca un record DMARC, anche per invii di basso volume. L’errore visualizzato è 550 5.7.1 Message rejected: Message lacks SPF/DKIM/DMARC Auth Records, a volte seguito da AS9031519.
Le segnalazioni descrivono un comportamento irregolare: alcuni messaggi provenienti dallo stesso dominio arrivano, mentre altri vengono respinti; in alcuni casi, il reinvio funziona. MailRoute e Teneo affermano di aver osservato questo schema nei propri sistemi. Microsoft, invece, non ha pubblicato un avviso che confermi un nuovo requisito generale né ha spiegato l’identificativo AS9031519. Questa mancanza di conferme è importante: alcuni utenti dichiarano di ricevere il rifiuto pur avendo configurato tutti e tre i meccanismi.
Un rifiuto che non riguarda tutti i messaggi
MailRoute colloca i primi rimbalzi nei propri registri di posta in uscita al 5 novembre. Secondo l’azienda, lo stesso giorno hanno iniziato a comparire segnalazioni pubbliche da parte di altri amministratori. Teneo descrive rifiuti a partire da quella data e documenta un caso ricevuto sabato 7 novembre alle 18:00 UTC, durante l’invio di un messaggio a un indirizzo outlook.be.
Nel caso di Teneo, il messaggio aveva una firma DKIM del dominio del mittente e il server di invio era autorizzato da SPF; entrambi i controlli sono stati superati. Mancava il record DMARC in _dmarc. Due secondi dopo, secondo l’azienda, un altro messaggio dello stesso dominio ha ricevuto la stessa risposta da un altro server Outlook.
L’errore è apparso anche nelle domande degli utenti pubblicate su Microsoft Q&A. Un cliente ha dichiarato che circa il 50% dei clienti che gli avevano scritto dal giorno precedente riceveva il messaggio di rimbalzo. Un altro ha spiegato che diversi clienti abituali non riuscivano più a inviargli messaggi, sebbene le email di altri mittenti continuassero ad arrivare nella sua casella. Questa differenza è coerente con il carattere parziale descritto da MailRoute e Teneo, ma non consente di concludere che tutti i casi abbiano la stessa causa.
Windows Latest ha riferito di essere riuscito a riprodurre il problema l’8 novembre e ha raccolto le lamentele degli utenti di Outlook.com e Hotmail. Un mittente ha raccontato che un messaggio inviato da Zoho a un account Outlook.com è stato respinto alle 15:50, ma è arrivato ripetendo l’invio alle 16:09; il messaggio consegnato indicava che SPF e DKIM erano stati superati. L’esito del secondo tentativo, da solo, non rivela cosa sia successo al primo.
“Domains with valid SPF, DMARC and DKIM are being rejected. It only happens for a small percentage of the emails (probably depends on which Microsoft server your message gets routed to),”
— ha scritto un utente
La frase proviene da un commento citato da Windows Latest in un forum Microsoft. La pubblicazione ha riportato anche il caso di una persona che ha dichiarato che circa la metà dei clienti che le avevano scritto dal 5 novembre aveva ricevuto un rifiuto. In un altro caso descritto su Microsoft Q&A, un utente ha affermato che i suoi messaggi verso Gmail e un altro account Exchange venivano accettati, mentre Outlook.com rifiutava l’invio.
Il nuovo codice non è l’errore relativo ai volumi elevati
Microsoft documenta effettivamente una policy di autenticazione per i mittenti ad alto volume, ma la sua pagina di supporto fa riferimento al codice 550 5.7.515, non a 550 5.7.1 con AS9031519. La regola ufficiale riguarda i domini che inviano 5.000 messaggi o più ai servizi di posta consumer di Microsoft e utilizzano lo stesso dominio nell’indirizzo From. Per questi mittenti, Microsoft richiede che SPF e DKIM vengano superati, che sia presente DMARC e che almeno SPF o DKIM siano allineati al dominio From.
La pagina di supporto Microsoft spiega che DMARC può essere superato tramite SPF, DKIM o entrambi, purché almeno uno sia allineato al dominio del mittente visibile. Raccomanda inoltre di verificare il percorso di ritorno, la firma DKIM e le impostazioni dei servizi esterni che inviano posta per conto del dominio. Se una piattaforma di fatturazione, un sistema di posta o un relay utilizza una firma o un dominio non allineato, il fatto che SPF o DKIM indichino “pass” potrebbe non essere sufficiente per superare DMARC.
MailRoute e Teneo sostengono che i nuovi rifiuti vadano oltre questa regola: riguarderebbero domini di qualsiasi volume che non pubblicano DMARC. Teneo distingue i due errori in base al codice e al testo restituito e afferma che i propri test sul rifiuto recente non hanno interessato le caselle aziendali di Microsoft 365. Le loro osservazioni si riferiscono ai casi riscontrati; Microsoft non ha confermato di aver introdotto un requisito universale.
La differenza emerge anche nelle risposte su Microsoft Q&A. Una consulente indipendente ha osservato che i requisiti per i mittenti ad alto volume erano entrati in vigore l’anno precedente e che la soglia di volume era rilevante. Altri partecipanti hanno raccontato che i domini ben al di sotto dei 5.000 messaggi giornalieri avevano smesso di consegnare la posta. Le risposte del forum non costituiscono un annuncio di Microsoft e non chiariscono se il nuovo codice corrisponda a un cambiamento intenzionale, a un’implementazione parziale o a un malfunzionamento.
La soluzione già provata da alcuni mittenti
In diversi casi, l’aggiunta di un record TXT DMARC con il valore v=DMARC1; p=none ha permesso di ripristinare la consegna dei messaggi. Frank Lawler, su Microsoft Q&A, ha dichiarato che le sue email da Microsoft 365 a Hotmail venivano respinte nonostante SPF e DKIM fossero configurati correttamente. Dopo aver verificato che il dominio non aveva DMARC nel DNS pubblico, ha pubblicato il record e ha comunicato che Hotmail ha accettato un nuovo invio. David R. ha descritto una prova simile: le sue intestazioni indicavano che i controlli erano superati, ma il record pubblico mancava; dopo averlo aggiunto, il messaggio di prova è arrivato allo stesso account Live.
Anche un utente citato da Windows Latest ha dichiarato di aver scoperto che mancava la voce DMARC della propria organizzazione, di averla configurata con p=none e di aver ottenuto risultati soddisfacenti nei test successivi. Si tratta di esperienze specifiche, non di una garanzia per tutti i messaggi respinti: Microsoft Q&A avverte che l’assenza di DMARC, da sola, non dimostra la causa in ogni caso, e Windows Latest ha raccolto le lamentele di mittenti che sostenevano di avere record validi.
La policy p=none dichiara l’uso di DMARC, ma chiede ai destinatari di non intervenire sui messaggi che non superano la convalida. MailRoute e Teneo la presentano come punto di partenza per risolvere i casi osservati. L’aggiunta del record, tuttavia, non corregge un disallineamento: se né SPF né DKIM vengono superati per il dominio indicato in From, DMARC non viene convalidato solo perché è stata pubblicata la voce.
Per verificare se il record esiste, MailRoute propone di interrogare il record TXT di _dmarc del dominio. Da un terminale, l’esempio è dig +short TXT _dmarc.example.com, sostituendo example.com con il dominio del mittente. L’azienda indica che una risposta che inizia con v=DMARC1 conferma la presenza di un record; l’assenza di risultati significa che la query non ne ha trovato uno. Gli utenti di Microsoft Q&A hanno anche consigliato di controllare il dominio pubblico del mittente con MXToolbox.
Il record viene pubblicato presso il provider DNS del dominio, non nelle impostazioni della casella personale che riceve la posta. Un partecipante di Microsoft Q&A ha spiegato che Microsoft 365 non crea automaticamente un record DMARC per ogni dominio. Nello stesso scambio, un utente ha trovato anche record DMARC duplicati e un errore di sintassi SPF in un altro dominio; per questo è opportuno controllare ogni dominio di invio e non presumere che un singolo account o servizio copra tutti i casi.
Cosa possono fare mittenti e destinatari
Se un messaggio viene respinto, i mittenti possono conservare il rapporto completo di mancata consegna e verificare SPF, DKIM, DMARC e l’allineamento con il dominio From. Microsoft consiglia di usare le intestazioni del messaggio per controllare i risultati dell’autenticazione e di verificare anche i servizi di terze parti. Teneo suggerisce di cercare nei registri il testo del rifiuto e l’identificativo AS9031519; se il problema persiste dopo la pubblicazione di DMARC, consiglia di conservare la risposta completa, compresi il nome del server e la marca temporale.
Il destinatario di Outlook.com non può correggere i record DNS del dominio mittente. In una risposta su Microsoft Q&A, a un utente che chiedeva se potesse modificare qualcosa nel proprio account per ricevere queste email è stato spiegato che il rifiuto avviene prima che il messaggio raggiunga la casella. Il suggerimento è stato di chiedere al mittente o al suo team IT di verificare DMARC; modificare le regole della casella o l’elenco dei mittenti attendibili non corregge la configurazione del dominio da cui proviene il messaggio.
Se il mittente conferma che SPF, DKIM e DMARC vengono superati e sono allineati, Microsoft Q&A suggerisce di inoltrare il caso all’assistenza allegando il rapporto completo di mancata consegna e i dati del messaggio. Windows Latest consiglia inoltre di condividere il messaggio di rimbalzo con il provider di posta o con il supporto Microsoft. In alcuni casi il reinvio può funzionare, ma non identifica la causa né garantisce che il tentativo successivo vada a buon fine.
Resta da chiarire se Microsoft stia applicando deliberatamente un controllo DMARC ai mittenti di qualsiasi dimensione o se alcuni rifiuti siano dovuti a un problema del servizio. MailRoute afferma che, al 6 novembre, non aveva trovato avvisi del postmaster, pubblicazioni sul blog o aggiornamenti di stato relativi al cambiamento. Anche Teneo non aveva trovato, all’8 novembre, una dichiarazione di Microsoft su AS9031519. In assenza di una spiegazione ufficiale, le segnalazioni disponibili continuano a mostrare due situazioni: domini senza DMARC che hanno ripristinato la consegna dopo averlo pubblicato e mittenti che dichiarano di ricevere lo stesso errore pur avendo configurato l’autenticazione.
Fonti: MailRoute, Microsoft Q&A, Microsoft Q&A, Supporto Microsoft, Windows Latest, Teneo SMTP Relay
