Come configurare MTA-STS e TLS-RPT: impedire l'intercettazione delle e-mail

Miliardi di e-mail circolano ogni giorno su Internet e una parte significativa di esse viaggia ancora senza crittografia obbligatoria. Questa portata rende la posta elettronica uno degli obiettivi più appetibili per l'intercettazione, dove i messaggi possono essere letti o alterati durante il trasferimento senza che il mittente o il destinatario se ne accorgano.

Il punto debole risiede nel modo in cui vengono consegnate le e-mail. Il protocollo SMTP si basa su una crittografia opportunistica, che consente agli aggressori di rimuovere o manomettere il comando STARTTLS e forzare una connessione in chiaro. Questi attacchi di downgrade SMTP aprono la porta all'intercettazione man-in-the-middle, consentendo agli aggressori di monitorare il traffico, acquisire contenuti sensibili o reindirizzare i messaggi attraverso server da loro controllati.

Contattateci Prenota una demo

Tabella dei contenuti

    1. Mail Transfer Agent-Strict Transport Security (MTA-STS)
    2. Assicurare la crittografia con MTA-STS
    3. L'anatomia di un attacco MITM
    4. Il file di politica MTA-STS
    5. Come pubblicare il file delle politiche MTA-STS
    6. Registrazione DNS di MTA-STS
    7. Configurare MTA-STS per il proprio dominio
    8. CSfide dell'implementazione manuale di MTA-STS
    9. Come testare e convalidare la configurazione MTA-STS
    10. Servizi MTA-STS ospitati da PowerDMARC
    11. Segnalazione SMTP TLS (TLS-RPT)
    12. Protezione del trasporto delle e-mail con MTA-STS
    13. Domande frequenti

Mail Transfer Agent-Strict Transport Security (MTA-STS) colma questa lacuna richiedendo connessioni TLS crittografate tra i server di posta in uscita e in entrata e rifiutando la consegna quando non è possibile stabilire un canale sicuro. Anziché sperare che la crittografia venga utilizzata, MTA-STS la impone, rendendola essenziale per le organizzazioni che desiderano configurare MTA-STS come parte della loro strategia di sicurezza della posta elettronica.

crittografia tls

Mail Transfer Agent-Strict Transport Security (MTA-STS)

MTA-STS, proprio come suggerisce il nome, è un protocollo che consente il trasporto crittografato di messaggi tra due server di posta SMTP. MTA-STS specifica ai server di invio che le e-mail devono essere inviate solo tramite una connessione crittografata TLS e non devono essere consegnate affatto nel caso in cui non sia stata stabilita una connessione protetta tramite il comando STARTTLS. Migliorando la sicurezza delle e-mail in transito, MTA-STS aiuta a mitigare gli attacchi Man-In-The-Middle (MITM) come gli attacchi SMTP downgrade e gli attacchi DNS spoofing.

Leggi di più

Assicurare la crittografia con MTA-STS

Le e-mail vengono trasmesse tra i server utilizzando SMTP, un protocollo che supporta la crittografia ma non la richiede per impostazione predefinita. Ciò crea una falla che consente la trasmissione dei messaggi senza protezione. MTA-STS colma questa lacuna rendendo la crittografia un requisito obbligatorio anziché un'opzione.

Per comprendere come funziona la crittografia durante la consegna delle e-mail, si consideri un server di posta che invia un messaggio a [email protected]. Il Mail Transfer Agent (MTA) mittente esegue innanzitutto una query DNS per recuperare i record MX per powerdmarc.com, identificando quali server di posta sono responsabili della ricezione del messaggio. L'MTA mittente si connette quindi a uno di questi server e verifica se supporta la crittografia TLS utilizzando il comando STARTTLS. Se TLS è disponibile, l'e-mail viene inviata tramite una connessione crittografata. In caso contrario, il server mittente non riesce a negoziare una connessione sicura e, senza applicazione, potrebbe ricorrere all'invio del messaggio in testo normale.

MTA-STS modifica questo comportamento di consegna applicando rigorosi requisiti di sicurezza durante la comunicazione da server a server:

MTA-STS istruisce i server di posta in uscita a consegnare i messaggi solo tramite una connessione crittografata TLS. Se non è possibile stabilire la crittografia, il messaggio non viene consegnato. Ciò elimina il fallback silenzioso al testo in chiaro che rende possibile l'intercettazione.

Il server di posta ricevente deve presentare un certificato TLS valido e il nome di dominio su tale certificato deve corrispondere al dominio definito nella politica MTA-STS. Ciò garantisce che il server mittente comunichi con la destinazione corretta e non con un host che ne sta impersonando l'identità.

Le politiche MTA-STS vengono recuperate tramite HTTPS da un server web sicuro. Il recupero della politica attraverso un canale crittografato e autenticato impedisce agli aggressori di modificare o falsificare le istruzioni della politica durante il transito.

Applicando la crittografia e convalidando sia i certificati che le istruzioni delle politiche, MTA-STS blocca gli attacchi SMTP downgrade che si basano sulla rimozione o sull'alterazione del comando STARTTLS. I server di invio non accettano più fallback non sicuri quando dovrebbe esistere una connessione sicura.

servizi mta sts ospitati
ospitato MTA STS

MTA-STS viene implementato pubblicando un record DNS che indirizza i server di posta in uscita a recuperare un file di policy da un sottodominio designato. Il file di policy è accessibile tramite HTTPS, convalidato utilizzando certificati TLS e contiene i nomi host approvati dei server di posta del destinatario. Il protocollo istruisce i server SMTP in uscita a richiedere una connessione crittografata e a verificare che il dominio elencato sul certificato TLS corrisponda al dominio definito nel file di policy. Se MTA-STS è applicato, nel caso in cui non sia possibile negoziare un canale crittografato, il messaggio non viene consegnato.

L'anatomia di un attacco MITM

Essenzialmente, un attacco MITM ha luogo quando un attaccante sostituisce o cancella il comando STARTTLS per far tornare la connessione protetta ad una non protetta, senza crittografia TLS. Questo viene definito un attacco di downgrade. Dopo aver eseguito con successo un attacco di downgrade, l'attaccante può accedere e visualizzare il contenuto delle e-mail senza ostacoli.

Un attaccante MITM può anche sostituire i record MX nella risposta della query DNS con un server di posta a cui ha accesso e di cui ha il controllo. L'agente di trasferimento della posta in questo caso consegna l'e-mail al server dell'attaccante, permettendogli di accedere e manomettere il contenuto dell'e-mail. L'e-mail può essere successivamente inoltrata al server del destinatario previsto, senza essere rilevata. Questo è noto come un attacco di spoofing DNS.

Attacco di downgrade SMTP

Segnali di avvertimento

Gli attacchi MITM spesso operano in modo silenzioso, ma alcuni modelli possono segnalare che qualcosa non va durante la consegna delle e-mail. Un segnale di allarme comune è rappresentato da errori di consegna imprevisti o ritardi nella comunicazione con domini specifici, soprattutto quando tali domini in precedenza accettavano i messaggi senza problemi. Anche un improvviso aumento degli errori di negoziazione TLS, il ripiego su connessioni non crittografate o ripetuti errori STARTTLS possono indicare un'interferenza durante la trasmissione.

Un altro indicatore è il comportamento incoerente dell'instradamento della posta. Le e-mail possono sembrare passare attraverso server sconosciuti, oppure i registri possono mostrare connessioni a host che non corrispondono ai record MX pubblicati del destinatario previsto. Nei casi più avanzati, i messaggi arrivano alterati, troncati o inoltrati attraverso sistemi intermedi senza una spiegazione chiara.

Il rilevamento dipende in larga misura dalla visibilità. Il monitoraggio dei log delle connessioni SMTP aiuta a identificare ripetuti errori di crittografia o discrepanze nei certificati. TLS-RPT aggiunge un ulteriore livello fornendo report quando i server non riescono a stabilire connessioni TLS sicure, segnalando problemi quali tentativi di downgrade, certificati non validi o errori nell'applicazione delle policy. 

Tutti questi segnali aiutano a rivelare attività MITM che altrimenti rimarrebbero nascoste durante il normale flusso di posta elettronica.

Il file di politica MTA-STS

Il file di policy MTA-STS è essenzialmente un semplice file di testo, simile al seguente:

versione: STSv1
modo: applicare
mx: mx1.powerdmarc.com
mx: mx2.powerdmarc.com
mx: mx3.powerdmarc.com
max_age: 604800

Nota: il campo versione deve essere incluso all'inizio del file di testo, mentre gli altri campi possono essere incorporati in qualsiasi ordine.

Il file delle politiche utilizza coppie chiave-valore con ciascun valore codificato su una riga separata nel file di testo, come mostrato sopra. La dimensione di questo file può arrivare fino a 64 KB. Il nome del file delle politiche deve essere mta-sts.txt. I file delle politiche devono essere aggiornati ogni volta che si aggiungono o si modificano i server di posta nel proprio dominio.

Nota: Impostare MTA-STS in modalità enforce può causare la mancata consegna di alcune email. Perciò è consigliabile impostare la modalità di policy su testing e optare per un max_age basso per assicurarsi che tutto funzioni correttamente prima di passare a enforce policy. Raccomandiamo di impostare TLS-RPT per la vostra policy anche in modalità testing per ricevere una notifica nel caso in cui le email siano inviate in chiaro. 

Politica MTA-STS

Come pubblicare il file delle politiche MTA-STS

Per pubblicare il file di policy MTA-STS, il server web che ospita il file deve:

  • Supporto HTTPS/SSL

    Il file di policy deve essere fornito tramite un server web abilitato per HTTPS per garantire che venga recuperato in modo sicuro dai server di posta in uscita.

  • Utilizza un certificato rilasciato da un'autorità di certificazione affidabile.

    Il certificato del server deve essere firmato e convalidato da un'autorità di certificazione root di terze parti in modo che gli MTA mittenti possano autenticare l'origine della politica.

  • Ospita il file su un sottodominio mta-sts dedicato

    È necessario configurare un server web pubblico con il sottodominio mta-sts aggiunto al proprio dominio, che viene utilizzato esclusivamente per la pubblicazione della politica MTA-STS.

  • Posizionare il file della policy nella directory richiesta.

    Il file di policy deve essere denominato mta-sts.txt e pubblicato all'interno della directory .well-known sul sottodominio mta-sts.

  • Assicurarsi che il file delle politiche sia accessibile pubblicamente all'URL corretto.

    Gli MTA mittenti devono essere in grado di recuperare il file da un percorso formattato come
    https://mta-sts.yourdomain.com/.well-known/mta-sts.txt senza autenticazione o reindirizzamenti.

ospitato MTA STS

Registrazione DNS di MTA-STS

Un record DNS TXT per MTA-STS è pubblicato sul DNS del vostro dominio per specificare che il vostro dominio supporta il protocollo MTA-STS e per segnalare il refresh dei valori memorizzati nella cache degli MTA in caso di modifica della policy. Il record DNS MTA-STS è posizionato nel sottodominio _mta-sts come in: _mta-sts.powerdmarc.com. Il record TXT deve iniziare con v=STSv1, e il valore "id" può contenere fino a 32 caratteri alfanumerici, inclusi nel modo seguente:

 v=STSv1; id=30271001S00T000;

Nota: il valore id del record TXT deve essere aggiornato ad un nuovo valore ogni volta che si fanno dei cambiamenti alla policy. 

Il record DNS MTA-STS è usato per: 

  • Specificare il supporto per MTA-STS per il dominio
  • Segnala all'MTA di recuperare nuovamente la politica tramite HTTPS nel caso in cui la politica venga alterata

Si noti che con il record DNS MTA-STS TXT, il file di policy può essere memorizzato dagli MTA per un periodo di tempo più lungo senza dover recuperare nuovamente la policy a meno che non sia stata alterata, pur continuando ad eseguire una query DNS ogni volta che viene ricevuta una mail per il dominio.

Configurare MTA-STS per il proprio dominio

Al fine di abilitare MTA-STS per il vostro dominio dovrete:

  • Aggiungete un record DNS di tipo cname a mta-sts.example.comdiretto verso il server web abilitato HTTPS che ospita il file di policy MTA-STS.

  • Aggiungete un record DNS di tipo txt o cname a _mta-sts.example.com che specifica il supporto per MTA-STS per il vostro dominio.

  • Impostare un server web abilitato HTTPS con un certificato valido per il tuo dominio.

  • Abilita SMTP TLS Reporting per il tuo dominio per rilevare i problemi nella consegna delle e-mail a causa di fallimenti nella crittografia TLS.

spf record lookup icona powerdmarc

Sfide dell'implementazione manuale di MTA-STS

L'implementazione manuale di MTA-STS non si limita alla pubblicazione di un singolo record DNS. Richiede il coordinamento dell'infrastruttura web, dei certificati, delle politiche e della manutenzione continua, il che può comportare diverse difficoltà se non gestito con attenzione.

  • Requisiti per un server web abilitato HTTPS

    Le politiche MTA-STS devono essere ospitate su un server HTTPS accessibile al pubblico con un certificato TLS valido. Ciò richiede la fornitura di infrastrutture, la corretta configurazione del TLS, il rinnovo tempestivo dei certificati e la garanzia di un'elevata disponibilità.

    Soluzione: le organizzazioni con un'infrastruttura web limitata possono ridurre la complessità utilizzando un servizio MTA-STS ospitato che gestisce automaticamente server e certificati.

  • Manutenzione continua dei file delle politiche

    Qualsiasi modifica alla configurazione del server di posta richiede l'aggiornamento del file delle politiche MTA-STS. Se il file non è aggiornato, una volta abilitata l'applicazione, le e-mail legittime potrebbero non essere recapitate.

    Soluzione: la gestione centralizzata delle politiche o gli strumenti automatizzati aiutano a garantire che gli aggiornamenti vengano applicati immediatamente e con precisione.

  • Aggiornamenti dei record DNS e controllo delle versioni

    Il record MTA-STS TXT deve essere aggiornato con un nuovo valore ID ogni volta che la politica cambia. Aggiornamenti mancanti o errati possono ritardare l'aggiornamento della politica e causare un'applicazione incoerente.

    Soluzione: l'automazione riduce il rischio di errore umano e mantiene i record DNS allineati alle modifiche delle politiche.

  • Visibilità limitata sui casi di mancata consegna

    Senza TLS-RPT, i problemi di consegna relativi alla crittografia potrebbero non essere rilevati. Anche con TLS-RPT abilitato, i report JSON grezzi possono essere difficili da interpretare senza conoscenze specialistiche.

    Soluzione: le piattaforme di reporting che analizzano e visualizzano i report TLS facilitano l'individuazione dei guasti e consentono di reagire rapidamente.

  • Maggiori costi operativi e sforzi di coordinamento

    L'implementazione manuale richiede il coordinamento tra i team DNS, e-mail e sicurezza, aumentando il rischio di configurazioni errate e ritardi.

    Soluzione: i team dovrebbero valutare se dispongono del tempo e delle competenze necessarie per mantenere MTA-STS a lungo termine o se un approccio gestito si adatta meglio alle loro priorità operative.

Come testare e convalidare la configurazione MTA-STS

Il test è una fase fondamentale prima di passare una politica MTA-STS alla modalità di applicazione. Una volta abilitata l'applicazione, i server di invio ricevono l'istruzione di rifiutare la consegna delle e-mail se non è possibile stabilire una connessione TLS sicura. Senza una corretta convalida, gli errori di configurazione possono portare alla perdita involontaria di messaggi, rendendo essenziali test accurati per mantenere una consegna affidabile delle e-mail.

  • Controlli di propagazione DNS

    Dopo aver pubblicato il record MTA-STS TXT e le relative voci DNS, verificare che vengano risolti correttamente dai resolver DNS pubblici. Una propagazione incompleta o ritardata può indurre i server di invio a fare affidamento su criteri obsoleti o memorizzati nella cache, causando un comportamento incoerente durante la consegna.

  • Accessibilità dei file di policy

    Verificare che il file delle politiche MTA-STS sia accessibile tramite HTTPS nella posizione prevista sul sottodominio mta-sts. Il file dovrebbe essere raggiungibile senza reindirizzamenti, requisiti di autenticazione o errori di certificato. Qualsiasi interruzione nell'accesso può impedire ai server di invio di recuperare la politica.

  • Verifica del supporto TLS

    Verificare che tutti gli host MX elencati nella politica supportino TLS e presentino certificati validi conformi ai requisiti della politica. Il successo della negoziazione TLS garantisce che le connessioni crittografate possano essere stabilite in modo coerente una volta abilitata l'applicazione.

Servizi MTA-STS ospitati da PowerDMARC

PowerDMARC rende la vostra vita molto più facile gestendo tutto questo per voi, completamente in background. Una volta che vi aiutiamo a configurarlo, non dovrete mai più pensarci.

  • Ti aiutiamo a pubblicare i tuoi record di cname con pochi clic

  • Ci prendiamo la responsabilità di mantenere il server web e di ospitare i certificati

  • Attraverso i nostri servizi MTA-STS ospitati, l'implementazione da parte vostra si riduce alla semplice pubblicazione di alcuni record DNS

  • È possibile apportare modifiche ai criteri MTA-STS istantaneamente e con facilità, attraverso la dashboard di PowerDMARC, senza dover apportare manualmente modifiche al DNS

  • I servizi MTA-STS ospitati da PowerDMARC sono conformi a RFC e supportano gli ultimi standard TLS

  • Dalla generazione dei certificati e del file di politica MTA-STS all'applicazione della politica, vi aiutiamo a eludere le tremende complessità legate all'adozione del protocollo

Segnalazione SMTP TLS (TLS-RPT)

Al fine di rendere più sicura e crittografata tramite TLS la connessione tra due server SMTP in comunicazione, è stato introdotto MTA-STS per applicare la crittografia e impedire che le e-mail vengano consegnate in chiaro quando non è possibile stabilire una connessione sicura. Tuttavia, rimane irrisolto un problema: come avvisare i proprietari dei domini quando i server remoti riscontrano problemi di consegna delle e-mail causati da errori TLS. È qui che entra in gioco TLS-RPT, che integra MTA-STS fornendo rapporti diagnostici che supportano il monitoraggio e la risoluzione dei problemi di comunicazione del server, come certificati TLS scaduti, configurazioni errate del server di posta o negoziazioni TLS non riuscite.

I rapporti TLS aiutano a rilevare e rispondere ai problemi nella consegna delle e-mail attraverso un meccanismo di segnalazione sotto forma di file JSON. Questi file JSON possono essere complicati e indecifrabili per una persona non tecnica.

PowerDMARC aiuta a semplificare i file JSON sotto forma di documenti semplici, completi e leggibili con grafici e tabelle per tua comodità. I rapporti diagnostici per il tuo dominio vengono visualizzati anche in due formati sulla dashboard di PowerDMARC:per risultato e per fonte di invio.

 

powerdmarc tls rpt

Cosa fa TLS-RPT

TLS-RPT è progettato per segnalare gli errori di consegna delle e-mail correlati alla crittografia TLS tra i server di posta. Il suo scopo principale è quello di fornire ai proprietari dei domini visibilità sulle situazioni in cui i messaggi non possono essere consegnati in modo sicuro, aiutando a identificare problemi che altrimenti rimarrebbero nascosti durante la normale comunicazione SMTP.

Attraverso questi report, TLS-RPT aiuta a identificare problemi quali negoziazioni TLS non riuscite tra server di invio e ricezione, certificati TLS scaduti o non validi ed errori di configurazione su entrambi i lati dello scambio di posta. Queste informazioni consentono agli amministratori di individuare con precisione i punti in cui la crittografia non funziona correttamente e di intraprendere azioni correttive.

I report TLS-RPT vengono generati e inviati da agenti di trasferimento della posta conformi, in genere su base giornaliera, fornendo una visibilità continua sullo stato di salute della consegna sicura delle e-mail.

grafici json

Come abilitarlo

TLS-RPT viene abilitato pubblicando un record DNS TXT nella posizione _smtp._tls richiesta per il tuo dominio. Questo record segnala il supporto per la segnalazione TLS e specifica la destinazione in cui devono essere inviati i rapporti diagnostici.

Il record TXT definisce uno o più indirizzi di segnalazione, in genere endpoint e-mail o HTTPS, che i server di posta conformi utilizzano per inviare dati TLS-RPT. Una volta creato il record, la segnalazione inizia automaticamente senza alcuna modifica al comportamento del server di posta.

TLS-RPT può essere configurato manualmente aggiungendo il record TXT direttamente al DNS o tramite piattaforme che forniscono una configurazione basata su interfaccia utente. L'utilizzo di un'interfaccia gestita semplifica l'implementazione gestendo la creazione e la convalida dei record, riducendo il rischio di errori di sintassi o configurazioni errate.

Leggi di più

Protezione del trasporto delle e-mail con MTA-STS

L'e-mail rimane un canale di comunicazione fondamentale, ma senza una crittografia obbligatoria è vulnerabile agli attacchi di downgrade e MITM che possono esporre il contenuto dei messaggi o interromperne la consegna. Proteggere le e-mail in transito è essenziale per preservare la riservatezza e mantenere la fiducia tra i server di posta in uscita e in entrata.

MTA-STS rafforza il trasporto delle e-mail richiedendo la crittografia TLS e rifiutando la consegna quando non è possibile stabilire connessioni sicure. Eliminando il ripiego alla comunicazione non crittografata, contribuisce a garantire che i messaggi vengano consegnati solo attraverso canali autenticati e protetti, migliorando la coerenza e l'affidabilità negli scambi da server a server.

Il successo dell'adozione di MTA-STS dipende da un'attenta preparazione. Le politiche devono essere configurate con precisione, l'infrastruttura di supporto deve essere convalidata e l'applicazione deve essere introdotta gradualmente dopo accurati test. Saltare questi passaggi può causare errori di consegna indesiderati, in particolare quando le politiche vengono trasferite troppo rapidamente in modalità di applicazione.

Prima di abilitare l'applicazione, le organizzazioni dovrebbero rivedere il loro attuale livello di sicurezza della posta elettronica, confermare la predisposizione TLS su tutti i server di posta e assicurarsi che i file DNS e delle politiche siano pubblicati correttamente. Il monitoraggio continuo e la convalida periodica rimangono importanti nel tempo, poiché le configurazioni dei server cambiano e i certificati scadono, contribuendo a garantire che le politiche MTA-STS continuino a proteggere efficacemente la consegna della posta elettronica.

Domande frequenti

Il pannello di controllo di PowerDMARC vi permette di impostare automaticamente MTA-STS e TLS-RPT per il vostro dominio pubblicando solo tre record CNAME nel DNS del vostro dominio. Dall'hosting dei file di policy MTAS-STS e dei certificati alla manutenzione del server web, ci occupiamo di tutto in background senza che voi dobbiate apportare alcuna modifica al vostro DNS. Il deployment di MTA-STS da parte vostra con PowerDMARC è ridotto a pochi clic.

Puoi distribuire e gestire MTA-STS per tutti i tuoi domini dal tuo account PowerDMARC, attraverso un unico pannello di vetro. Nel caso in cui qualcuno di quei domini stia usando server di posta ricevente che non supportano STARTTLS, ciò si rifletterà nei tuoi rapporti TLS, a condizione che tu abbia abilitato TLS-RPT per quei domini.

È sempre consigliabile impostare la modalità della politica MTA-STS su test durante le fasi iniziali di implementazione in modo da poter monitorare le attività e ottenere visibilità nel vostro ecosistema di posta elettronica prima di passare a una politica più aggressiva come enforce. In questo modo, anche se le email non vengono inviate su una connessione criptata TLS, verrebbero comunque inviate in chiaro. Tuttavia, assicurati di abilitare TLS-RPT per ricevere una notifica se ciò accade.

TLS-RPT è un ampio meccanismo di segnalazione che ti permette di ricevere una notifica nel caso in cui una connessione protetta non possa essere stabilita e l'e-mail non sia stata consegnata. Questo ti aiuta a rilevare i problemi nella consegna delle e-mail o le e-mail consegnate su una connessione non protetta in modo da poterli mitigare e risolvere prontamente.

Dovete notare che mentre MTA-STS assicura che le e-mail siano trasferite su una connessione cifrata TLS, nel caso in cui una connessione protetta non sia negoziata, l'e-mail potrebbe non essere consegnata affatto. Questo però è necessario perché assicura che le e-mail non vengano consegnate su un percorso non crittografato. Per evitare tali problemi, è consigliabile impostare una policy MTA-STS su una modalità di test e abilitare TLS-RPT per il tuo dominio inizialmente, prima di procedere alla modalità MTA-STS enforce. 

Potete facilmente cambiare la vostra modalità MTA-STS dalla dashboard di PowerMTA-STS selezionando la modalità di policy desiderata e salvando le modifiche senza il bisogno di fare alcun cambiamento al vostro DNS.

È possibile disattivare MTA-STS per il proprio dominio impostando la modalità di policy su "none" (nessuna), specificando così agli MTA che il proprio dominio non supporta il protocollo, oppure eliminando il record DNS TXT MTA-STS. 

I record MX per il file di policy MTA-STS dovrebbero includere le voci per tutti i server di posta ricevente utilizzati dal vostro dominio.

Prenota una demo oggi stesso
email sicura powerdmarc

Prova di 15 giorniPrenota una demo