Autenticazione delle e-mail in Outlook: configurazione di SPF, DKIM e DMARC

La maggior parte dei mittenti segue la guida alla configurazione dell'autenticazione delle e-mail di Outlook, aggiunge i record DNS richiesti, vede i segni di spunta verdi nello strumento di convalida e presume che l'autenticazione sia completata. Poi la deliverability cala, i messaggi iniziano a finire nella cartella "Posta indesiderata" oppure Microsoft segnala problemi di autenticazione che sembrano impossibili, dato che sulla carta tutto appare corretto.

L'autenticazione delle e-mail in Outlook è più complessa della semplice pubblicazione dei record SPF, DKIM e DMARC. Microsoft 365 presenta requisiti di configurazione specifici, errori comuni di configurazione e controlli di autenticazione che possono risultare superati a livello di DNS, ma fallire quando Outlook riceve effettivamente l'e-mail.

In questa guida scoprirai come funziona l'autenticazione delle e-mail in Outlook, come configurare correttamente SPF, DKIM e DMARC per Microsoft 365, come si sono evoluti i requisiti di Microsoft e come verificare che l'autenticazione funzioni effettivamente in condizioni reali di ricezione.

Perché l'autenticazione in Outlook è importante nel 2026 

Se invii e-mail tramite Microsoft 365, Outlook ora richiede che SPF, DKIM e DMARC siano configurati correttamente affinché i tuoi messaggi possano essere considerati affidabili.

Ecco una breve cronologia delle misure adottate per l'autenticazione in Outlook:

• Febbraio 2024: Google e Yahoo hanno iniziato ad applicare requisiti di autenticazione per i mittenti che inviano e-mail in massa, rendendo obbligatori gli standard SPF, DKIM e DMARC per i programmi di posta elettronica con volumi elevati.
• Aprile 2025: Microsoft ha annunciato requisiti simili per i mittenti che inviano messaggi in massa alle caselle di posta di Outlook.com, Hotmail, Live e MSN.
• Maggio 2025: è iniziata l'applicazione iniziale delle norme, con i messaggi non conformi che venivano sempre più spesso reindirizzati alla cartella della posta indesiderata.
• Dopo maggio 2025: Microsoft ha avvertito che la posta non conforme inviata in grandi volumi verrà successivamente respinta fino a quando i record DNS non saranno stati corretti.
• Microsoft identifica tali rifiuti di autenticazione con il codice 550 5.7.515 quando il dominio mittente non soddisfa il livello di autenticazione richiesto.
• 2026: L'autenticazione è ormai lo standard di riferimento. Gli errori di autenticazione possono comportare l'invio nella cartella della posta indesiderata o il rifiuto del messaggio, mentre la reputazione del mittente e il contenuto continuano a determinare se la posta autenticata raggiunga o meno la posta in arrivo.

I requisiti formali di Microsoft sono rivolti ai mittenti con volumi elevati, ma i provider di caselle di posta elettronica utilizzano sempre più spesso l'autenticazione come indicatore di affidabilità per tutte le e-mail.

Per i team di outbound B2B, la realtà pratica è semplice: che si inviino 200 o 20.000 e-mail al giorno, SPF, DKIM e DMARC non sono più facoltativi. Sono le fondamenta su cui si basano tutti gli altri segnali di deliverability.

L'autenticazione da sola non garantisce l'inserimento nella posta in arrivo, ma la mancata autenticazione può impedire del tutto che la tua email raggiunga la posta in arrivo.

Come configurare l'SPF per Outlook / Microsoft 365

L'SPF indica a Outlook quali server sono autorizzati a inviare e-mail per conto del proprio dominio. Per Microsoft 365, ciò significa pubblicare un record SPF che autorizzi l'infrastruttura di invio di Microsoft, insieme a qualsiasi altra piattaforma che invii e-mail utilizzando il proprio dominio.

Quando si configura l'SPF:

• Pubblica un unico record TXT SPF per il dominio.
• Includi il meccanismo SPF di Microsoft: include:spf.protection.outlook.com.
• Aggiungi tutte le piattaforme di invio autorizzate, come il tuo CRM, la piattaforma di marketing, lo strumento di outreach, l'helpdesk o il sistema di fatturazione.
• Ove possibile, utilizzare i meccanismi di inclusione raccomandati dal provider anziché aggiungere manualmente gli indirizzi IP.
• Verificare il registro ogni volta che viene aggiunta una nuova piattaforma di invio.

Un record SPF tipico di Microsoft 365 ha un aspetto simile al seguente:

v=spf1 include:spf.protection.outlook.com ~all

La maggior parte delle organizzazioni dovrà includere ulteriori dichiarazioni relative ad altri strumenti di invio.

Uno dei problemi più comuni relativi all'SPF è il superamento del limite di 10 ricerche DNS. Ogni meccanismo "include:" consuma ricerche e, con l'aggiunta nel tempo di ulteriori strumenti, il record può diventare troppo complesso per essere valutato correttamente dai provider destinatari.

Prima di salvare la configurazione SPF:

• Verifica che per il dominio sia presente un solo record SPF.
• Verificare che siano incluse tutte le piattaforme di invio legittime.
• Verificare che il record rientri nei limiti previsti per la ricerca SPF.
• Dopo aver apportato le modifiche, verifica che l'SPF superi il test con esito positivo.

Una volta configurato correttamente l'SPF, il passo successivo consiste nell'abilitare il DKIM, in modo che Outlook possa verificare che i tuoi messaggi non siano stati alterati durante la consegna.

Una ricerca DNS conferma solo che il record sia valido, ma non garantisce che l'autenticazione SPF venga superata una volta che Outlook riceve effettivamente il messaggio. Lo strumento gratuito SPF Checker di MailReach verifica l'autenticazione end-to-end in condizioni reali di ricezione e aiuta a individuare eventuali problemi di configurazione che gli strumenti basati esclusivamente sul DNS potrebbero trascurare. 

Come configurare DKIM per Outlook / Microsoft 365

DKIM aiuta Outlook a verificare che un'e-mail sia stata effettivamente inviata dal tuo dominio e non sia stata modificata dopo aver lasciato il server di invio. Per Microsoft 365, la configurazione di DKIM richiede alcuni passaggi aggiuntivi poiché, per impostazione predefinita, il tuo dominio personalizzato non viene autenticato automaticamente.

Molti mittenti danno per scontato che DKIM sia già configurato, poiché Microsoft firma la posta in uscita utilizzando la propria infrastruttura. Tuttavia, tale firma predefinita autentica il dominio di Microsoft, non il tuo. Per autenticare il tuo dominio, devi configurare DKIM separatamente.

Quando si configura DKIM:

• Pubblica i due record CNAME DKIM generati da Microsoft 365 (selector1 e selector2).
• Abilita la firma DKIM per il tuo dominio personalizzato nel portale di Microsoft Defender.
• Utilizzare chiavi da 2048 bit ogni volta che Microsoft ne garantisce il supporto.
• Verifica che la firma DKIM sia attiva dopo che i record si sono propagati.
• Configura un record DKIM separato per ogni piattaforma di invio aggiuntiva che utilizza il tuo dominio.

Se il tuo dominio invia e-mail tramite più piattaforme, ciascuna di esse avrà il proprio selettore DKIM e la propria chiave di firma. Un record DKIM creato per Microsoft 365 non autentica automaticamente i messaggi inviati tramite il tuo CRM, la tua piattaforma di outreach, l'helpdesk o il tuo strumento di marketing.

Uno dei problemi di configurazione più comuni è la comparsa del messaggio "DKIM non configurato" anche dopo aver aggiunto i record richiesti. Ciò è spesso dovuto a ritardi nella propagazione del DNS o a selettori configurati in modo errato.

Dopo la configurazione:

• Verifica che entrambi i record CNAME siano stati pubblicati correttamente.
• Verifica che la firma DKIM sia abilitata in Microsoft 365.
• Verifica che il DKIM sia valido sui messaggi recapitati, non solo nel DNS.
• Eseguire nuovamente il test ogni volta che si aggiunge una nuova piattaforma di invio.
• Verifica che il dominio di firma DKIM corrisponda al tuo dominio "Da:" per DMARC.

La presenza di un record DKIM nel DNS non garantisce che il controllo DKIM abbia esito positivo quando Outlook riceve il messaggio. Verificare sempre il risultato dell'autenticazione sulle e-mail consegnate, non limitandosi alla configurazione DNS.

Il DKIM Checker gratuito di MailReach esegue questa verifica end-to-end, evidenziando le discrepanze tra selettore e chiave, compreso un dominio che continua a firmare come onmicrosoft.com, che gli strumenti basati esclusivamente sul DNS segnalano come valido. 

Come configurare DMARC

DMARC si basa su SPF e DKIM. Verifica che almeno uno di questi metodi di autenticazione abbia esito positivo e corrisponda al dominio indicato nell'indirizzo "Da:" visibile. Inoltre, indica ai provider di posta elettronica come comportarsi in caso di autenticazione fallita.

Molte guide alla configurazione di DMARC raccomandano di impostare direttamente il parametro p=reject per garantire la massima protezione. Per la maggior parte delle organizzazioni, specialmente quelle che utilizzano più piattaforme di invio, questa scelta è rischiosa. Se i mittenti legittimi non sono stati autenticati correttamente, una politica DMARC troppo rigida può bloccare e-mail aziendali valide.

Quando si configura DMARC:

• Pubblica un record TXT DMARC su _dmarc.tuodominio.com.
• Inizia con una politica di monitoraggio impostata su p=none.
• Aggiungi un indirizzo di riferimento aggregato utilizzando il tag rua=.
• Verifica che SPF o DKIM siano validi e corrispondano al tuo dominio "Da:".
• Esaminare i rapporti prima di apportare modifiche alle politiche.

Una volta attivata la segnalazione DMARC:

• Esamina i rapporti per identificare tutte le piattaforme che inviano e-mail per conto del tuo dominio.
• Verificare la presenza di errori di autenticazione e di allineamento.
• Risolvere i problemi relativi a SPF, DKIM e all'allineamento dei domini.
• Verificare che tutti i mittenti legittimi superino il controllo DMARC.
• Continuare il monitoraggio finché i risultati non risulteranno costantemente negativi.

Una volta completato il monitoraggio:

• Sposta in p=quarantena per inviare i messaggi non recapitabili alla cartella spam.
• Continuare a esaminare i rapporti e a prestare attenzione a eventuali problemi.
• Imposta p=reject solo quando sei sicuro che tutta la posta legittima superi l'autenticazione.

Avviare il sistema in modalità di monitoraggio ti consente di monitorare le modalità di invio delle e-mail dal tuo dominio e contribuisce a evitare che messaggi legittimi vengano bloccati da una politica troppo restrittiva.

Come verificare se l'autenticazione di Outlook funziona davvero

Molti mittenti si fermano dopo aver verificato il DNS e danno per scontato che tutto funzioni correttamente. Il problema è che un record DNS può esistere pur se l'autenticazione continua a fallire a causa di problemi di allineamento, errori di configurazione, discrepanze nei selettori o impostazioni incomplete.

Seguire la procedura riportata di seguito per verificare l'autenticazione in condizioni reali di ricezione.

Fase 1: Verificare la presenza dei record nel DNS

Inizia verificando che i tuoi record SPF, DKIM e DMARC siano stati pubblicati correttamente.

Verificare che:

• Per il tuo dominio è presente un record TXT SPF.
• I tuoi selettori DKIM sono pubblicati e accessibili.
• È presente un record DMARC su _dmarc.yourdomain.com.
• I record contengono i valori previsti dal tuo provider di posta elettronica.

Ciò conferma che la configurazione è visibile pubblicamente, ma non conferma che l'autenticazione vada a buon fine.

Passaggio 2: inviare un'e-mail vera e propria a Outlook

L'autenticazione viene verificata quando Outlook riceve un messaggio.

Invia un'e-mail di prova dalla stessa piattaforma che utilizzi normalmente per le comunicazioni, il marketing o la corrispondenza aziendale a:

• Una casella di posta Outlook.com
• Una casella di posta Hotmail.com
• Se possibile, una casella di posta aziendale di Microsoft 365

L'utilizzo di caselle di posta reali ti aiuta a verificare come Microsoft elabora i tuoi messaggi nella pratica.

Fase 3: Verifica dei risultati dell'SPF

Aprire il messaggio ricevuto e verificare i risultati dell'autenticazione.

Verificare che:

• L'SPF risulta "Superato".
• Il server mittente è autorizzato dal tuo record SPF.
• Il dominio autenticato corrisponde a quello che ti aspettavi.

Se SPF non funziona, Outlook non è in grado di verificare che il server di invio sia autorizzato a inviare messaggi per conto del proprio dominio.

Fase 4: Verifica dei risultati DKIM

Successivamente, verifica la firma DKIM.

Verificare che:

• Il DKIM risulta "Pass".
• La firma è stata convalidata con successo.
• Il dominio di firma appartiene alla tua organizzazione.
• Si sta utilizzando il selettore corretto.

È possibile che nel DNS sia presente un record DKIM anche se la firma effettiva non supera la verifica; ecco perché è importante verificare la posta recapitata.

Passaggio 5: Verifica dei risultati DMARC

Anche DMARC dovrebbe inoltrare il messaggio ricevuto.

Verificare che:

• DMARC risulta "Pass".
• SPF o DKIM superano il controllo con esito positivo.
• Il dominio autenticato corrisponde al dominio visibile nel campo "Da:".
• Non sono stati segnalati errori di allineamento.

Questo passaggio conferma che Outlook riconosce l'autenticazione esattamente come previsto.

Passaggio 6: Verifica del posizionamento nella Posta in arrivo

L'autenticazione e il posizionamento nella posta in arrivo non sono la stessa cosa.

Anche se SPF, DKIM e DMARC superano tutti i controlli:

• L'e-mail potrebbe comunque finire nella cartella "Posta indesiderata".
• I problemi di reputazione possono influire sul posizionamento.
• I segnali relativi ai contenuti e al coinvolgimento possono influenzare le decisioni di filtraggio.

Verifica se il messaggio arriva in:

• Posta in arrivo
• Spazzatura
• Altre cartelle filtrate

Questo aiuta a stabilire se si tratta di un problema di autenticazione o di reputazione.

Farlo manualmente su più caselle di posta è un’operazione noiosa. Il test gratuito di deliverability delle email di MailReach invia i messaggi attraverso una rete di caselle di posta reali di Google Workspace e Microsoft 365 e mostra se i messaggi finiscono nella posta in arrivo, nella cartella dello spam o in quelle filtrate, insieme ai risultati SPF, DKIM e DMARC e a un elenco di soluzioni in ordine di priorità, in modo da poter distinguere un problema di autenticazione da uno di reputazione con un unico test. 

Passaggio 7: ripetere il test dopo ogni modifica

È necessario verificare l'autenticazione ogni volta che:

• Aggiungi una nuova piattaforma di invio.
• Cambiare provider di posta elettronica.
• Aggiornare i record DNS.
• Abilita un nuovo selettore DKIM.
• Modifica la tua politica DMARC.

Piccoli cambiamenti nella configurazione possono influire sui risultati dell'autenticazione senza generare errori evidenti.

Una ricerca DNS ti dice che i record esistono. Un test di autenticazione nel mondo reale ti dice se Outlook si fida effettivamente di essi. È il secondo che conta.

Errori comuni nell'autenticazione in Outlook (e come risolverli)

La maggior parte dei problemi di autenticazione in Outlook è causata da errori di configurazione che a prima vista sembrano corretti, ma che si rivelano errati quando Microsoft valuta effettivamente l'e-mail. La buona notizia è che la maggior parte di questi problemi segue schemi prevedibili. Una volta che si sa cosa cercare, di solito sono facili da individuare e risolvere.

L'SPF supera il limite di 10 ricerche

I record SPF possono contenere un massimo di 10 ricerche DNS. Ogni istruzione "include:" consuma una parte di tale limite, poiché Outlook deve seguire tali riferimenti per determinare se un server di invio è autorizzato.

Questo problema si manifesta spesso in modo graduale. Un dominio inizia con Microsoft 365, poi aggiunge un CRM, una piattaforma di marketing, un help desk, uno strumento di outreach e alcuni altri servizi. Il record SPF continua a esistere nel DNS, ma una volta superato il limite di ricerca, Outlook non è più in grado di valutarlo completamente. L’SPF potrebbe non funzionare correttamente anche se apparentemente non sembra esserci alcun problema.

Come risolverlo:

• Verificate tutte le piattaforme attualmente autorizzate a inviare e-mail per il vostro dominio.
• Rimuovere le istruzioni `include:` obsolete o inutilizzate.
• Ove possibile, raggruppare gli strumenti di invio.
• Monitorare il numero di ricerche ogni volta che viene aggiunta una nuova piattaforma.
• Verificare nuovamente l'SPF dopo ogni modifica per assicurarsi che sia ancora conforme.

Utilizzo del DKIM predefinito di Microsoft

Microsoft 365 firma automaticamente le e-mail utilizzando una firma DKIM di onmicrosoft.com. Molti mittenti ritengono che ciò significhi che il DKIM sia configurato correttamente.

La firma predefinita di Microsoft autentica il dominio di Microsoft, non il tuo dominio personalizzato. La tua e-mail potrebbe apparire come firmata con DKIM, mentre il tuo dominio rimane non autenticato ai fini dell'allineamento DMARC.

Come risolverlo:

• Pubblica i due record CNAME DKIM generati da Microsoft per il tuo dominio.
• Abilita la firma DKIM per il dominio personalizzato in Microsoft Defender.
• Verifica che DKIM utilizzi il tuo dominio come firmatario anziché onmicrosoft.com.
• Configurare record DKIM distinti per ogni piattaforma di invio aggiuntiva.
• Verifica il DKIM utilizzando messaggi effettivamente recapitati, non solo il DNS.

DMARC supera il test teorico ma non quello di allineamento

La pubblicazione di un record DMARC non implica automaticamente che il test DMARC sia superato.

DMARC richiede che l'autenticazione SPF o DKIM corrisponda al dominio indicato nell'indirizzo "Da:" visibile. Un messaggio può superare il controllo SPF e comunque non superare quello DMARC se l'autenticazione avviene su un dominio diverso.

Si tratta di una causa comune di errori di autenticazione in Outlook, poiché il record esiste, i controlli sembrano configurati, eppure DMARC continua a dare esito negativo durante la consegna.

Come risolverlo:

• Verificare che il dominio autenticato tramite SPF corrisponda al dominio visibile nel campo "Da:".
• Verificare che il dominio di firma DKIM corrisponda al dominio visibile nel campo "Da:".
• Esaminare i rapporti DMARC per individuare eventuali errori di allineamento.
• Verifica le e-mail reali invece di affidarti alle ricerche DNS.
• Risolvi i problemi di allineamento prima di andare oltre p=none.

Passare a p=reject troppo presto

Molte guide alla configurazione di DMARC consigliano di impostare direttamente il parametro p=reject per garantire la massima protezione. Per le organizzazioni che utilizzano più strumenti, ciò può causare problemi in breve tempo.

I sistemi CRM, i sistemi di fatturazione, gli help desk e le applicazioni interne dimenticati spesso continuano a inviare e-mail anche dopo l'attivazione dell'applicazione del protocollo DMARC. Se tali sistemi non vengono autenticati correttamente, le e-mail aziendali legittime potrebbero essere bloccate.

Come risolverlo:

• Inizia con p=none e raccogli i rapporti DMARC.
• Individua tutti i sistemi che inviano e-mail dal tuo dominio.
• Risolvi innanzitutto gli errori di autenticazione e di allineamento.
• Passare a p=quarantena prima di prendere in considerazione p=rifiuto.
• Passare all’applicazione completa solo dopo che un monitoraggio prolungato avrà confermato il transito di posta legittima.

Supponendo che "Record pubblicato" significhi "funzionante"

Una ricerca DNS conferma solo l'esistenza di un record. Non garantisce che Outlook verifichi correttamente SPF, DKIM e DMARC al momento della ricezione di un'e-mail.

Questo crea un falso senso di sicurezza. Nel DNS tutto sembra configurato correttamente, mentre le e-mail continuano a finire nella cartella "Spam" o a non superare i controlli di autenticazione durante la consegna.

Come risolverlo:

• Invia e-mail di prova alle caselle di posta di Outlook e Gmail.
• Verifica i risultati di SPF, DKIM e DMARC nelle intestazioni dei messaggi ricevuti.
• Eseguire un test dopo ogni modifica al DNS o alla piattaforma di invio.
• Controllare regolarmente i risultati dell'autenticazione.
• Utilizzare test di autenticazione end-to-end anziché una verifica basata esclusivamente sul DNS.

Utilizzo di un sottodominio per il cold outreach

Molti mittenti ritengono che l’uso di un sottodominio isoli completamente le comunicazioni di contatto a freddo dalla loro posta elettronica aziendale principale.

Sebbene i sottodomini creino una certa separazione, i provider di caselle di posta elettronica possono comunque associarli al dominio principale. Se le campagne di outreach generano reclami o un scarso coinvolgimento, i segnali di reputazione potrebbero comunque influire sul marchio in generale.

Come risolverlo:

• Utilizza un dominio secondario dedicato per le attività di cold outreach.
• Autenticare il dominio secondario in modo indipendente.
• Preriscaldare il dominio di copertura prima di aumentare il volume.
• Distinguere il traffico relativo alle attività di sensibilizzazione, al marketing e alle transazioni.
• Proteggi il tuo dominio aziendale principale da rischi inutili per la reputazione.

Inseguire le liste nere invece di migliorare la reputazione

Un avviso relativo alla lista nera sembra spesso urgente, ed è per questo che molti mittenti si concentrano innanzitutto sui controlli relativi alla lista nera quando la deliverability cala.

In realtà, Outlook si basa principalmente sui sistemi di reputazione di Microsoft, sui dati relativi ai reclami, sui segnali di interazione e sui risultati dell'autenticazione. La maggior parte delle blacklist pubbliche ha un impatto minimo sul posizionamento nella posta in arrivo di Outlook.

Se le e-mail autenticate finiscono sistematicamente nella cartella "Posta indesiderata", il problema di fondo è solitamente legato alla reputazione, al coinvolgimento o al comportamento di invio, piuttosto che all'inserimento in una lista nera.

Come risolverlo:

• Verificare se la lista nera venga effettivamente utilizzata da Microsoft.
• Concentrati innanzitutto sui tassi di reclamo e sulla reputazione del mittente.
• Migliorare l'autenticazione e la pulizia degli elenchi.
• Controlla la posizione nella casella di posta in arrivo anziché limitarti a verificare lo stato nella lista nera.
• Considerate i controlli della lista nera come un segnale diagnostico, non come una strategia di deliverability.

Mantenimento dell’autenticazione delle e-mail di Outlook nel tempo

I provider di posta elettronica continuano a inasprire i propri requisiti di affidabilità. L’autenticazione sta diventando sempre meno un vantaggio competitivo e sempre più un requisito minimo. I domini che ottengono i risultati migliori sono quelli che controllano regolarmente le proprie fonti di invio, verificano l’autenticazione dopo ogni modifica, monitorano i rapporti DMARC e individuano i problemi prima che questi compromettano la consegna.

Il passo successivo non consiste semplicemente nel pubblicare i record e andare avanti. Si tratta di verificare che Outlook visualizzi le e-mail esattamente come desideri. Ciò significa effettuare test in condizioni reali di ricezione, monitorare l'autenticazione nel tempo e assicurarsi che i nuovi strumenti non introducano silenziosamente dei malfunzionamenti.

Il test di deliverability delle e-mail di MailReach verifica l'autenticazione end-to-end anziché a livello di DNS, mentre i test automatizzati con avvisi su Slack o tramite webhook segnalano eventuali scostamenti nel momento stesso in cui un nuovo strumento supera silenziosamente un record. 

Domande Frequenti

Microsoft 365 configura automaticamente il DKIM? 

Non vale per il tuo dominio personalizzato. Microsoft 365 utilizza di default una chiave onmicrosoft.com predefinita, il che non equivale all'autenticazione del tuo dominio. Devi pubblicare due record CNAME e abilitare la firma DKIM per il tuo dominio nel portale Defender.

Perché le mie e-mail autenticate finiscono ancora nella cartella “Posta indesiderata” di Outlook? 

L'autenticazione, infatti, è solo uno dei tre pilastri della deliverability. Microsoft tiene conto anche della reputazione del mittente (engagement) e dei contenuti. È possibile superare i controlli SPF, DKIM e DMARC ed essere comunque classificati come spam se la propria reputazione è scarsa o se i contenuti fanno scattare i filtri. 

Quali sono i requisiti di Microsoft per i mittenti che inviano messaggi in massa? 

In linea con le norme emanate da Google e Yahoo nel febbraio 2024, Microsoft richiede ai mittenti che inviano grandi volumi di messaggi (circa 5.000 o più messaggi al giorno a Outlook.com, Hotmail e Live) di autenticarsi tramite SPF, DKIM e DMARC, pena l'invio in posta indesiderata e il blocco dei messaggi. Per la posta in uscita B2B, è necessario autenticarsi indipendentemente dal volume.

DMARC è obbligatorio per Outlook? 

Per i mittenti che inviano grandi volumi di messaggi, sì. Per tutti gli altri è vivamente consigliato e sempre più richiesto. Iniziate con l’impostazione p=none per monitorare la situazione, poi passate all’applicazione delle regole man mano che i vostri report confermano che tutti i mittenti legittimi superano il controllo.

email warmup risolve il problema dell'autenticazione in Outlook? 

No. Il “warmup” rafforza la reputazione del mittente, che è un pilastro distinto dall’autenticazione. L’autenticazione riguarda la configurazione del DNS; il “warmup” genera coinvolgimento. Entrambi sono importanti, ma il “warmup” è destinato esclusivamente alle attività di outreach a freddo nel settore B2B.

‍