I record DMARC sono un insieme di vari meccanismi o tag DMARC che comunicano istruzioni specifiche ai server di ricezione della posta elettronica durante il trasferimento. Ognuno di questi tag DMARC contiene un valore che è definito dal proprietario del dominio. Oggi discuteremo cosa sono i tag DMARC e cosa significano ciascuno di essi. 

Ecco tutti i tag DMARC disponibili che il proprietario di un dominio può specificare nel suo record DMARC:

Tag DMARC Tipo Valore predefinito Cosa significa
v obbligatorio Il tag v rappresenta la versione del protocollo DMARC e ha sempre il valore v=DMARC1 
pct opzionale 100 Questo tag rappresenta la percentuale di email a cui la modalità di policy è applicabile. Per saperne di più sul tag DMARC pct
p obbligatorio Questo tag indirizza la modalità della politica DMARC. Puoi scegliere tra rifiutare, mettere in quarantena e nessuno. Per saperne di più su cos'è la politica DMARC per ottenere chiarezza su quale modalità selezionare per il tuo dominio.
sp opzionale La modalità di politica configurata per il tuo dominio principale (p) Specificando la policy del sottodominio, il tag sp è configurato per definire una modalità di policy per i tuoi sottodomini. Scopri di più sul tag DMARC sp per capire quando dovresti configurarlo. 
rua Opzionale ma raccomandato Il tag rua è un tag DMARC opzionale che specifica l'indirizzo e-mail o il server web in cui le organizzazioni segnalanti devono inviare i loro Dati rua aggregati DMARC

Esempio: rua=mailto:[email protected];

ruf Opzionale ma raccomandato Allo stesso modo, il meccanismo ruf specifica l'indirizzo a cui il Rapporto DMARC forense ruf deve essere inviato. Attualmente, non tutte le organizzazioni di segnalazione inviano dati forensi. 

Esempio: ruf=mailto:[email protected]

fo opzionale 0 Il tag fo si rivolge alle opzioni di segnalazione guasti/forensi disponibili che i proprietari del dominio possono scegliere. Se non hai abilitato ruf per il tuo dominio, puoi ignorare questo. 

Le opzioni disponibili tra cui scegliere sono: 

0: un rapporto DMARC failure/forensic ti viene inviato se la tua email fallisce sia l'allineamento SPF che DKIM

1: un rapporto DMARC failure/forensic viene inviato al vostro quando la vostra email fallisce l'allineamento SPF o DKIM

d: un rapporto di fallimento DKIM viene inviato se la firma DKIM dell'email fallisce la validazione, indipendentemente dall'allineamento

s: un rapporto di fallimento SPF viene inviato se l'email fallisce la valutazione SPF, indipendentemente dall'allineamento.

aspf opzionale Questo tag DMARC indica il modo di allineamento SPF. Il valore può essere strict(s) o relaxed(r)
adkim opzionale Allo stesso modo, il tag adkim DMARC indica la modalità di allineamento DKIM, il cui valore può essere strict (s) o relaxed (r) 
rf opzionale afrf Il tag DMARC rf specifica i vari formati per la segnalazione forense.
ri opzionale 86400 Il tag ri si riferisce all'intervallo di tempo in secondi tra due rapporti aggregati consecutivi inviati dall'organizzazione di segnalazione al proprietario del dominio.

Per creare un record per DMARC istantaneamente, usa il nostro generatore DMARC gratuito. In alternativa, se hai un record esistente, controlla la sua validità effettuando una ricerca DMARC.

Iscriviti oggi stesso per una prova gratuita di prova DMARC per ottenere i consigli degli esperti su come proteggere il tuo dominio dagli spoofers.

Se voi, come proprietario di un dominio, volete specificare cosa fare con un'email che fallisce l'autenticazione, i record DMARC possono aiutarvi in questo. Un'azienda può pubblicare un record di testo nel DNS e specificare cosa vogliono che accada alle e-mail che falliscono l'allineamento alla fonte, determinando se consegnarle, metterle in quarantena o anche rifiutarle del tutto. Il tag DMARC pct è parte di questo record e dice a un destinatario di email quale percentuale di messaggi sotto questa politica sarà interessata.

Cosa significa pct in DMARC?

Un record TXT per qualsiasi protocollo di autenticazione e-mail contiene una serie di meccanismi o tag che significano istruzioni dedicate ai server di ricezione e-mail. In un record DMARC, pct è un acronimo di percentuale che viene incluso per indicare la percentuale di email a cui viene applicata la politica DMARC definita dal proprietario del dominio.

Perché avete bisogno del tag DMARC pct?

Il tag pct è un modo spesso trascurato, ma comunque efficace per impostare e testare le politiche DMARC del vostro dominio. Un record DMARC con un tag percentuale assomiglia al seguente: 

v=DMARC1; p=reject; pct=100; rua=mailto:[email protected];

Nel record DNS DMARC mostrato sopra, la percentuale di email per le quali la politica di rifiuto DMARC è applicabile è del 100%. 

Il tempo necessario a un dominio per passare dal non usare affatto DMARC all'usare le impostazioni più restrittive è un periodo di ramp-up. Questo ha lo scopo di dare ai domini il tempo di prendere confidenza con le loro nuove impostazioni. Per alcune aziende, questo potrebbe richiedere alcuni mesi. È possibile per i domini fare un aggiornamento istantaneo, ma questo è poco comune a causa del rischio di maggiori errori o reclami. Il tag pct è stato progettato come un modo per applicare gradualmente le politiche DMARC per ridurre il periodo di roll-out per le aziende online. L'intento è quello di essere in grado di distribuirlo per un piccolo gruppo di email prima di distribuirlo completamente all'intero flusso di posta come nel caso mostrato di seguito: 

v=DMARC1; p=reject; pct=50; rua=mailto:[email protected];

In questo record DNS DMARC, la politica di rifiuto per DMARC si applica solo al 50% delle e-mail, mentre l'altra metà del volume è soggetta a una politica di quarantena per DMARC, che è la seconda politica più severa in linea. 

Cosa succede se non si include un tag pct nel record DMARC?

Mentre si crea un record DMARC usando un generatore di record DMARCsi potrebbe scegliere di non definire un tag pct e lasciare questo criterio vuoto. In questo caso, l'impostazione predefinita per pct è impostata a 100, il che significa che la vostra politica definita si applicherà a tutte le vostre email. Quindi, se vuoi definire una policy per tutte le tue email, un modo più semplice per farlo sarebbe quello di lasciare il criterio pct vuoto, come in questo esempio:

v=DMARC1; p=quarantena; rua=mailto:[email protected];

Attenzione: Se vuoi una politica forzata per DMARC, non pubblicare un record con pct=0

La logica dietro questo è semplice: se volete definire una politica di rifiuto o di quarantena nel vostro record, volete essenzialmente che la politica sia applicata alle vostre email in uscita. Impostando il vostro pct a 0 annullate il vostro sforzo in quanto la vostra policy è ora applicabile a zero emails. Questo è lo stesso che avere la vostra policy impostata a p=none. 

Nota: Al fine di proteggere il tuo dominio da attacchi di spoofing e fermare qualsiasi possibilità che il tuo dominio sia impersonato da aggressori, la politica ideale dovrebbe essere DMARC a p=reject; pct=100;

Passate all'applicazione DMARC in modo sicuro iniziando il vostro viaggio DMARC con PowerDMARC. Fate una prova gratuita prova DMARC oggi stesso!

L'attributo "sp" è l'abbreviazione di subdomain policy e non è attualmente un attributo molto usato. Permette a un dominio di specificare che un diverso record DMARC dovrebbe essere usato per i sottodomini del dominio DNS specificato. Per mantenere le cose semplici, raccomandiamo che l'attributo 'sp' sia omesso dal dominio organizzativo stesso. Questo porterà ad una politica predefinita di fallback che impedisce lo spoofing sui sottodomini. È importante ricordare che il comportamento dei sottodomini è sempre determinato dalla politica organizzativa prevalente. 

I sottodomini ereditano la policy del dominio padre a meno che non sia esplicitamente annullata da un record di policy del sottodominio. L'attributo 'sp' può sovrascrivere questa eredità. Se un sottodominio ha un record DMARC esplicito, questo record avrà la precedenza sulla policy DMARC del dominio padre, anche se il sottodominio usa l'impostazione di default p=none. Per esempio, se una politica DMARC è definita per la priorità 'all', l'elemento 'sp' influenzerà l'elaborazione DMARC sui sottodomini non coperti da alcuna politica specifica.

Perché avete bisogno del tag DMARC sp?

Se hai il tuo record DMARC come: 

v=DMARC1; p=reject; sp=none; rua=mailto:[email protected];

In questo caso, mentre il vostro dominio principale è protetto contro gli attacchi di spoofing, i vostri sottodomini, anche se non li usate per scambiare informazioni, sarebbero comunque vulnerabili agli attacchi di impersonificazione.

Se hai il tuo record DMARC come: 

v=DMARC1; p=nessuno; sp=reject; rua=mailto:[email protected];

In questo caso, mentre non ti stai impegnando in una politica di rifiuto sul dominio principale che usi per inviare le tue email, i tuoi sottodomini inattivi sono ancora protetti contro l'impersonificazione. 

Se vuoi che le politiche del tuo dominio e del tuo sottodominio siano le stesse, puoi lasciare il criterio del tag sp vuoto o disabilitato mentre crei un record, e i tuoi sottodomini erediteranno automaticamente la politica applicata al dominio principale. 

Se stai usando il nostro generatore di record DMARC per creare un record DMARC per il tuo dominio, devi abilitare manualmente il pulsante della politica del sottodominio e definire la tua politica desiderata, come mostrato qui sotto:

 

Dopo aver creato il tuo record DMARC è importante controllare la validità del tuo record usando il nostro strumento di ricerca del record DMARC per assicurarsi che il vostro record sia privo di errori e valido.

Inizia il tuo viaggio DMARC con PowerDMARC per massimizzare la sicurezza delle email del tuo dominio. Fai la tua prova gratuita prova DMARC oggi stesso!

A causa delle minacce in agguato online, le aziende devono dimostrare di essere legittime impiegando metodi di autenticazione forti. Un metodo comune è attraverso DomainKeys Identified Mail (DKIM), una tecnologia di autenticazione e-mail che utilizza chiavi di crittografia per verificare il dominio del mittente. DKIM insieme a SPF e DMARC ha drasticamente migliorato la posizione di sicurezza delle email delle organizzazioni a livello globale.

Leggi di più su cos'è DKIM.

Durante la configurazione di DKIM per le tue e-mail, una delle decisioni principali che devi prendere è determinare la lunghezza della chiave DKIM. In questo articolo, ti guideremo attraverso la lunghezza della chiave consigliata per una migliore protezione e come aggiornare le chiavi in Exchange Online Powershell.

Importanza di aggiornare la lunghezza della chiave DKIM

Scegliere 1024 bit o 2048 bit è una decisione importante che deve essere presa quando si sceglie la chiave DKIM. Per anni, le PKI (public key infrastructure) hanno usato chiavi DKIM a 1024 bit per la loro sicurezza. Tuttavia, poiché la tecnologia sta diventando più complessa, gli hacker stanno lavorando duramente per trovare nuovi metodi per paralizzare la sicurezza. Per questo motivo, la lunghezza delle chiavi è diventata sempre più importante.

Mentre gli hacker continuano a inventare modi migliori per rompere le chiavi DKIM. La lunghezza della chiave è direttamente correlata a quanto sia difficile rompere l'autenticazione. L'utilizzo di una chiave a 2048 bit fornisce una maggiore protezione e una migliore sicurezza contro gli attacchi attuali e futuri, evidenziando l'importanza di aggiornare la vostra bitness.

Aggiornamento manuale delle chiavi DKIM in Exchange Online Powershell

  • Iniziate collegandovi a Microsoft Office 365 PowerShell come amministratore (assicuratevi che il vostro account Powershell sia configurato per eseguire script Powershell firmati)
  • Nel caso in cui DKIM sia preconfigurato, per aggiornare le vostre chiavi a 2048 bit eseguite il seguente comando su Powershell: 

Rotate-DkimSigningConfig -KeySize 2048 -Identity {Guid del Signing Config esistente}

  • Nel caso in cui non abbiate implementato DKIM in precedenza, eseguite il seguente comando su Powershell: 

New-DkimSigningConfig -DomainName <Domain for which config is to be created> -KeySize 2048 -Enabled $true

  • Infine, per verificare che avete configurato con successo DKIM con un bitness aggiornato di 2048 bit, eseguite il seguente comando:

Get-DkimSigningConfig -Identity <Domain for which the configuration was set> | Format-List

Nota: Assicuratevi di essere connessi a Powershell durante il completamento della procedura. Le modifiche possono richiedere fino a 72 ore per essere implementate.

DKIM non è sufficiente per proteggere il tuo dominio da spoofing e BEC. Migliora la sicurezza e-mail del tuo dominio configurando DMARC per office 365.

Il tanto atteso roll-out è finalmente arrivato! Microsoft sta inviando rapporti aggregati DMARC RUA ai suoi utenti ed è probabile che non ve ne siate accorti. I rapporti aggregati Microsoft DMARC vengono inviati dal seguente indirizzo e-mail: [email protected]. Il file grezzo Microsoft DMARC aggregato viene inviato in formato XML standard. Microsoft ha finalmente abbracciato la segnalazione DMARC, il che significa essenzialmente che ora gli utenti di Hotmail, Outlook, Live e msn.com potranno godere dei vari benefici dei dati aggregati Microsoft DMARC.

Elaborazione dei dati aggregati Microsoft DMARC

L'analizzatore di rapporti PowerDMARC analizza i dati aggregati Microsoft DMARC in un formato organizzato che vi aiuterà a processarli in modo più efficiente.  

Per aiutare gli utenti ad avvalersi dei vantaggi dei dati aggregati dei report inviati da Microsoft, l'analizzatore di report DMARC di PowerDMARC analizzatore di rapporti DMARC è stato preconfigurato per ricevere i loro rapporti direttamente sulla piattaforma. Tutto ciò che gli utenti devono fare è aggiungere i loro domini sulla piattaforma PowerDMARC insieme alla configurazione del record DMARC DNS, mentre noi elaboriamo e presentiamo i rapporti in modo facile e comprensibile. Qui troverete:

  • Dati aggregati DMARC inviati da indirizzi di destinatari Hotmail, Outlook, Live e msn.com analizzati dal formato grezzo del file XML in informazioni semplici e leggibili organizzate in tabelle
  • PowerDMARC è preconfigurato per bypassare le violazioni RFC, permettendoci di ricevere ed analizzare i tuoi dati DMARC inviati dai server Microsoft senza che tu te ne debba preoccupare
  • Registra più domini, monitora i tuoi canali e-mail e apporta modifiche ai DNS direttamente dal dashboard con pulsanti attivabili a portata di mano
  • Filtrare i risultati in categorie assortite come per risultato, per fonte di invio, per organizzazione, per paese, geolocalizzazione, e statistiche dettagliate o risultati di ricerca per dominio sulla barra di ricerca
  • Ottieni approfondimenti sulle prestazioni delle tue e-mail e individua rapidamente i tentativi di spoofing del dominio, di impersonificazione o le false e-mail inviate utilizzando i tuoi domini aziendali Microsoft. Sarai anche in grado di analizzare qualsiasi errore SPF e DKIM dalle tue fonti di invio.

Sopra è mostrata una schermata dei nostri rapporti aggregati DMARC per organizzazione che mostra i dati DMARC RUA inviati da Microsoft.

Problemi che potresti dover affrontare mentre gestisci da solo i rapporti aggregati Microsoft DMARC

Le e-mail aggregate Microsoft DMARC non sono conformi a RFC

Il problema principale che gli utenti hanno affrontato con queste e-mail contenenti rapporti inviati da Microsoft è che non sono conformi alle specifiche RFC per le e-mail internet. Mentre RFC 5322 capitolo 2.1.1 afferma chiaramente che una riga di caratteri non deve superare i 78 caratteri, i dati BASE64 degli allegati in queste e-mail aggregate Microsoft DMARC sono una linea continua senza interruzioni di riga adeguate che supera il limite di 78 caratteri. La violazione RFC risultante è la ragione per cui la maggior parte di queste e-mail stanno finendo nel registro dei rifiuti dell'utente invece di essere consegnate alla loro casella di posta. 

I file XML grezzi sono difficili da leggere

Proprio come i dati DMARC inviati da tutte le organizzazioni di segnalazione, il file RUA grezzo è in un linguaggio di markup estensibile (XML) che è difficile da leggere e capire.

Prerequisiti per ricevere Microsoft DMARC RUA

Per ricevere rapporti aggregati per i vostri domini su outlook.com, dovete assicurarvi di avere un record PowerDMARC valido pubblicato sul vostro DNS, insieme a una politica DMARC definita. Le organizzazioni di reporting invieranno quindi i dati dei report aggregati al vostro server web o indirizzo e-mail specificato. Questo vi aiuterà ad ottenere visibilità e conformità DMARC sui vostri fornitori di posta elettronica di terze parti, sui quali altrimenti non avreste alcun controllo. 

Proteggi i tuoi domini su Microsoft Office365 e altri iniziando il tuo viaggio di autenticazione e-mail oggi. Salite a bordo con una prova gratuita di prova DMARC o programmate una demo DMARCed esplora i vantaggi dell'implementazione di una solida postura di sicurezza e-mail nella tua organizzazione!

Nel caso in cui vi siate imbattuti nella "Manca la politica MTA-STS: STSFetchResult.NONE "durante l'utilizzo di strumenti online, siete venuti nel posto giusto. Oggi parleremo di come risolvere questo messaggio di errore e sbarazzarsi di esso incorporando una politica MTA-STS per il vostro dominio.

Simple Mail Transfer Protocol, alias SMTP, è il protocollo standard di trasferimento della posta elettronica utilizzato dalla maggior parte dei fornitori di servizi e-mail. Non è un concetto estraneo che SMTP ha affrontato sfide di sicurezza fin dall'alba dei tempi, sfide che non sono stati in grado di risolvere fino ad ora. Questo perché, al fine di rendere le e-mail compatibili all'indietro, SMTP ha introdotto la crittografia opportunistica sotto forma di un comando STARTTLS. Questo significa essenzialmente che, nel caso in cui una connessione criptata non possa essere negoziata tra due server SMTP comunicanti, la connessione viene riportata ad una non criptata, e i messaggi vengono inviati in chiaro. 

Questo rende le e-mail trasferite via SMTP vulnerabili al monitoraggio pervasivo e agli attacchi di intercettazione informatica come il Man-in-the-middle. Questo è rischioso sia per il mittente che per il destinatario e può portare alla violazione di dati sensibili. È qui che MTA-STS entra in gioco e rende la crittografia TLS obbligatoria in SMTP per impedire che le e-mail vengano consegnate su connessioni non sicure. 

Cos'è una politica MTA-STS?

Per migliorare la sicurezza delle e-mail SMTP e sfruttare al massimo i protocolli di autenticazione come MTA-STS, il server di invio dovrebbe avere il supporto per il protocollo e il server di ricezione delle e-mail dovrebbe avere una politica MTA-STS definita nel proprio DNS. Una modalità di politica forzata è anche incoraggiata per amplificare ulteriormente gli standard di sicurezza. La politica MTA-STS definisce i server di posta elettronica che usano MTA-STS nel dominio del destinatario. 

Per abilitare MTA-STS per il tuo dominio come destinatario di email, devi ospitare un file di policy MTA-STS nel tuo DNS. Questo permette ai mittenti di e-mail esterni di inviare e-mail al tuo dominio che sono autenticate e criptate TLS con una versione aggiornata di TLS (1.2 o superiore). 

Non avere un file di policy pubblicato o aggiornato per il vostro dominio può essere la ragione principale per imbattersi in messaggi di errore come "Manca la policy MTA-STS: STSFetchResult.NONE", che implica che il server del mittente non ha potuto recuperare il file di policy MTA-STS quando ha interrogato il DNS del destinatario, trovandolo mancante.

Prerequisiti per MTA-STS:

I server di posta elettronica per i quali MTA-STS sarà abilitato dovrebbero usare una versione TLS di 1.2 o più, e dovrebbero avere certificati TLS in atto che aderiscono agli attuali standard e specifiche RFC, non sono scaduti, e certificati di server che sono firmati da un'autorità di certificazione root affidabile.

Passi per risolvere "La politica MTA-STS è mancante".

1. Creazione e pubblicazione di un record TXT di MTA-STS DNS 

Il primo passo è quello di creare un record MTA-STS per il tuo dominio. Potete creare un record istantaneamente usando un generatore di record MTA-STS, fornendovi un record DNS su misura per il vostro dominio. 

2. Definire una modalità di politica MTA-STS

MTA-STS offre due modalità di politica con cui gli utenti possono lavorare.

  • Modalità di test: Questa modalità è ideale per i principianti che non hanno configurato il protocollo prima. La modalità di test MTA-STS permette di ricevere rapporti SMTP TLS su problemi nelle politiche MTA-STS, problemi nello stabilire connessioni SMTP criptate, o fallimento nella consegna delle e-mail. Questo ti aiuta a rispondere ai problemi di sicurezza esistenti relativi ai tuoi domini e server senza applicare la crittografia TLS.
  • Applicare la modalità: Mentre si ricevono ancora i rapporti TLS, nel corso del tempo è ottimale per gli utenti applicare la loro politica MTA-STS per rendere obbligatoria la crittografia durante la ricezione di e-mail utilizzando SMTP. Questo impedisce che i messaggi vengano modificati o manomessi durante il transito.

3. Creare il file di policy MTA-STS

Il passo successivo è quello di ospitare i file di policy MTA-STS per i vostri domini. Notate che mentre il contenuto di ogni file può essere lo stesso, è obbligatorio ospitare le policy separatamente per domini separati, e un singolo dominio può avere solo un singolo file di policy MTA-STS. Più file di policy MTA-STS ospitati per un singolo dominio possono portare a configurazioni errate del protocollo. 

Il formato standard per un file di policy MTA-STS è dato di seguito: 

Nome del file: mta-sts.txt

Dimensione massima del file: 64 KB

versione: STSv1

modo: test

mx: mail.yourdomain.com

mx: *.yourdomain.com

max_age: 806400 

Nota: Il file di policy mostrato sopra è semplicemente un esempio.

4. Pubblicare il file di policy MTA-STS

Successivamente, dovete pubblicare il vostro file di policy MTA-STS su un server web pubblico che sia accessibile ai server esterni. Assicuratevi che il server su cui ospitate il vostro file supporti HTTPS o SSL. La procedura per questo è semplice. Supponendo che il vostro dominio sia preconfigurato con un server web pubblico:

  • Aggiungi un sottodominio al tuo dominio esistente che dovrebbe iniziare con il testo: mta-sts (per esempio mta-sts.domain.com) 
  • Il tuo file di policy punterà a questo sottodominio che hai creato e deve essere memorizzato in un .well-known
  • L'URL per il file di policy è aggiunto alla voce DNS durante la pubblicazione del record DNS MTA-STS in modo che il server possa interrogare il DNS per recuperare il file di policy durante il trasferimento della posta elettronica

5. Attivare MTA-STS e TLS-RPT

Infine, dovete pubblicare i vostri MTA-STS e TLS-RPT nel DNS del vostro dominio, usando TXT come tipo di risorsa, posizionati su due sottodomini separati (_smtp._tls e _mta-sts). Questo permetterà solo ai messaggi criptati TLS di raggiungere la tua casella di posta, che sono verificati e non manomessi. Inoltre, riceverai quotidianamente dei rapporti sui problemi di consegna e crittografia su un indirizzo e-mail o un server web configurato da te, da server esterni.

Potete verificare la validità dei vostri record DNS eseguendo una ricerca di record MTA-STS dopo che il vostro record è pubblicato e attivo.  

Nota: Ogni volta che fate delle modifiche al contenuto dei vostri file di policy MTA-STS, dovete aggiornarlo sia sul server web pubblico su cui ospitate il vostro file, sia sulla voce DNS che contiene il vostro URL di policy. Lo stesso vale per ogni volta che aggiornate o aggiungete ai vostri domini o server.

Come possono i servizi MTA-STS ospitati aiutare a risolvere il problema "La politica MTA-STS è mancante"?

L'implementazione manuale di MTA-STS può essere ardua e impegnativa e lasciare spazio agli errori. PowerDMARC MTA-STS in hosting aiutano a catapultare il processo per i proprietari di domini, rendendo l'implementazione del protocollo facile e veloce. Voi potete:

  • Pubblica i tuoi record CNAME per MTA-STS con pochi clic
  • Esternalizzare il duro lavoro coinvolto nel mantenimento e nell'hosting dei file delle politiche MTA-STS e dei server web
  • Cambiate la modalità della vostra politica ogni volta che lo desiderate, direttamente dalla vostra dashboard personalizzata, senza dover accedere al vostro DNS
  • Mostriamo i file JSON dei rapporti SMTP TLS in un formato organizzato e leggibile dall'uomo che è comodo e comprensibile sia per le persone tecniche che per quelle non tecniche.

La cosa migliore? Siamo conformi alle RFC e supportiamo gli ultimi standard TLS. Questo ti aiuta a iniziare con una configurazione MTA-STS senza errori per il tuo dominio, e a godere dei suoi benefici lasciando a noi le seccature e le complessità da gestire per tuo conto! 

Spero che questo articolo vi abbia aiutato a sbarazzarvi del messaggio "Manca la policy MTA-STS: STSFetchResult.NONE", e a configurare correttamente i protocolli per il vostro dominio per mitigare le lacune e le sfide della sicurezza SMTP. 

Abilita MTA-STS per le tue email oggi stesso prendendo un autenticazione e-mail prova DMARCper migliorare le tue difese contro il MITM e altri attacchi di intercettazione informatica!