Den efterlängtade utrullningen är äntligen här! Microsoft skickar DMARC RUA-aggregerade rapporter till sina användare och chansen är stor att du kanske inte har märkt det. Microsoft DMARC-aggregerade rapporter skickas från följande e-postadress: [email protected]. Den råa Microsoft DMARC-samlingsfilen skickas i standard XML-format. Microsoft har äntligen anammat DMARC-rapportering, vilket i huvudsak innebär att nu Hotmail, Outlook, Live och msn.com-användare kommer att kunna njuta av de olika fördelarna med Microsoft DMARC-aggregerade data.

Bearbeta Microsoft DMARC-aggregerade data

PowerDMARC-rapportanalysatorn parsar Microsoft DMARC-aggregerade data till ett organiserat format som hjälper dig att bearbeta dem mer effektivt.  

För att hjälpa användare att utnyttja fördelarna med aggregerade rapportdata som skickas av Microsoft har PowerDMARC:s DMARC-rapportanalysator förkonfigurerats för att ta emot sina rapporter direkt på plattformen. Allt användarna behöver göra är att lägga till sina domäner på PowerDMARC-plattformen tillsammans med att konfigurera DMARC DNS-posten, medan vi bearbetar och presenterar rapporterna på ett enkelt och förståeligt sätt. Här hittar du:

  • DMARC-aggregerade data som skickas från Hotmail-, Outlook-, Live- och msn.com-mottagaradresser som tolkats från det råa XML-filformatet till enkel och läsbar information ordnad i tabeller
  • PowerDMARC är förkonfigurerat för att kringgå RFC-överträdelser, vilket gör det möjligt för oss att ta emot och tolka dina DMARC-data som skickas av Microsoft-servrar utan att du behöver oroa dig för det
  • Registrera flera domäner, övervaka dina e-postkanaler och gör DNS-ändringar direkt från instrumentpanelen med användbara knappar till hands
  • Filtrera resultat till olika kategorier, till exempel per resultat, per sändande källa, per organisation, per land, geolokalisering och detaljerad statistik eller sökresultat per domän i sökfältet
  • Få djupare insikter om dina e-postmeddelandens prestanda och ta snabbt upp försök till domänförfalskning, personifiering eller falska e-postmeddelanden som skickas med dina Microsoft-företagsdomäner. Du kommer också att kunna analysera alla SPF-, DKIM-fel från dina sändande källor.

Ovan visas en skärmdump av våra DMARC-aggregerade rapporter per organisation som visar DMARC RUA-data som skickas från Microsoft.

Problem som du kan ställas inför när du hanterar Microsoft DMARC-aggregerade rapporter på egen hand

Microsoft DMARC-aggregerade e-postmeddelanden är inte RFC-kompatibla

Det primära problemet som användare har stått inför med dessa e-postmeddelanden som innehåller rapporter som skickas av Microsoft är att de inte överensstämmer med RFC-specifikationerna för internetmeddelanden. Medan RFC 5322 kapitel 2.1.1 tydligt anger att en teckenrad inte får överstiga 78 tecken, är BASE64-bifogade data i dessa Microsoft DMARC-aggregerade e-postmeddelanden en kontinuerlig rad utan ordentliga radbrytningar som överskrider gränsen på 78 tecken. Den resulterande RFC-överträdelsen är anledningen till att de flesta av dessa e-postmeddelanden landar i användarens avslagslogg istället för att levereras till deras inkorg. 

Obehandlade XML-filer är svåra att läsa

Precis som DMARC-data som skickas av alla rapporterande organisationer är den råa RUA-filen i utökningsbart markeringsspråk (XML) som är svårt att läsa och förstå.

Förutsättningar för att ta emot Microsoft DMARC RUA

Om du vill ta emot aggregerade rapporter för dina domäner på outlook.com måste du se till att du har en giltig PowerDMARC-post publicerad på din DNS, tillsammans med en definierad DMARC-princip. Rapporterande organisationer skickar sedan aggregerade rapportdata till den angivna webbservern eller e-postadressen. Detta hjälper dig att få synlighet och DMARC-efterlevnad på dina tredjepartsleverantörer av e-post som du annars inte har någon kontroll över. 

Skydda dina domäner på Microsoft Office365 och andra genom att starta din e-postautentiseringsresa idag. Gå ombord med en gratis DMARC-utvärderingsversion eller schemalägg en DMARC-demooch utforska fördelarna med att implementera en robust e-postsäkerhetsställning på din organisation!

Om du har stött på "MTA-STS-policyn saknas: STSFetchResult.NONE " -kommandot när du använder onlineverktyg har du kommit till rätt plats. Idag kommer vi att diskutera hur du åtgärdar det här felmeddelandet och gör dig av med det genom att införliva en MTA-STS-policy för din domän. 

Simple Mail Transfer Protocol, även kallat SMTP, är det vanliga e-postöverföringsprotokollet som används av en majoritet av e-postleverantörerna. Det är inte ett främmande koncept som SMTP har stått inför säkerhetsutmaningar sedan tidernas begynna, utmaningar som de ännu inte har kunnat komma på. Detta beror på att SMTP, för att göra e-postmeddelandena bakåtkompatibla, introducerade opportunistisk kryptering i form av ett STARTTLS-kommando.  Detta innebär i huvudsak, om en krypterad anslutning inte kan förhandlas mellan två kommunicerande SMTP-servrar, återställs anslutningen till en okrypterad och meddelanden skickas med klartext. 

Detta gör e-postmeddelanden som överförs via SMTP sårbara för genomgripande övervakning och cyber-avlyssningsattacker som Man-in-the-middle. Detta är riskabelt för både avsändaren och mottagaren och kan leda till brott mot känsliga data. Det är här MTA-STS sveper in och gör TLS-kryptering obligatorisk i SMTP för att förhindra att e-postmeddelanden levereras över osäkra anslutningar. 

Vad är en MTA-STS-policy?

För att förbättra din SMTP-e-postsäkerhet och få ut mesta delen av autentiseringsprotokoll som MTA-STS bör den sändande servern ha stöd för protokollet och den mottagande servern för e-post bör ha en MTA-STS-princip definierad i sin DNS. Ett påtvingat principläge uppmuntras också att ytterligare förstärka säkerhetsstandarderna. MTA-STS-principen definierar e-postservrarna med MTA-STS i mottagarens domän. 

För att aktivera MTA-STS för din domän som e-postmottagare måste du vara värd för en MTA-STS-principfil i din DNS. Detta gör det möjligt för externa e-postavsändare att skicka e-postmeddelanden till din domän som autentiseras och TLS krypteras med en uppdaterad version av TLS (1.2 eller senare). 

Att inte ha en publicerad eller uppdaterad principfil för din domän kan varaden främsta orsaken till att stöta på felmeddelanden som "MTA-STS-principen saknas: STSFetchResult.NONE", vilket innebäratt avsändarens server inte kunde hämta MTA-STS-principfilen när den frågade mottagarens DNS och fann att den saknades.

Förutsättningar för MTA-STS:

E-postservrar för vilka MTA-STS kommer att aktiveras bör använda en TLS-version av 1.2 eller mer, och bör ha TLS-certifikat på plats som följer gällande RFC-standarder och specifikationer, inte har upphört att gälla och servercertifikat som signeras av en betrodd rotcertifikatutfärdare.

Steg för att åtgärda "MTA-STS-principen saknas"

1. Skapa och publicera en MTA-STS DNS TXT-post 

Det första steget är att skapa en MTA-STS-post för din domän. Du kan skapa en post direkt med en MTA-STS-postgenerator, vilket ger dig en skräddarsydd DNS-post för din domän. 

2. Definiera ett MTA-STS-principläge

MTA-STS erbjuder två principlägen som användare kan arbeta med.

  • Testläge: Det här läget är idealiskt för nybörjare som inte har konfigurerat protokollet tidigare. Med testläget MTA-STS kan du ta emot SMTP TLS-rapporter om problem i MTA-STS-principer, problem med att upprätta krypterade SMTP-anslutningar eller fel vid e-postleverans. Detta hjälper dig att svara på befintliga säkerhetsproblem som rör dina domäner och servrar utan att tvinga fram TLS-kryptering.
  • Framtvingaläge : Även om du fortfarande får dina TLS-rapporter är det under tiden optimalt för användare att genomdriva sin MTA-STS-policy för att göra kryptering obligatorisk medan de tar emot e-postmeddelanden med SMTP. Detta förhindrar att meddelanden ändras eller manipuleras under överföringen.

3. Skapa MTA-STS-principfilen

Nästa steg är att vara värd för MTA-STS-principfiler för dina domäner. Observera att även om innehållet i varje fil kan vara detsamma, är det obligatoriskt att vara värd för principer separat för separata domäner, och en enda domän kan bara ha en enda MTA-STS-principfil. Flera MTA-STS-principfiler som finns för en enda domän kan leda till felkonfigurationer av protokoll. 

Standardformatet för en MTA-STS-principfil anges nedan: 

Filnamn: mta-sts.txt

Maximal filstorlek: 64 KB

version: STSv1

läge: testning

mx: mail.yourdomain.com

mx: *.yourdomain.com

max_age: 806400 

Principfilen som visas ovan är helt enkelt ett exempel.

4. Publicera din MTA-STS-policyfil

Därefter måste du publicera din MTA-STS-principfil på en offentlig webbserver som är tillgänglig för externa servrar. Kontrollera att servern du är värd för filen på stöder HTTPS eller SSL. Förfarandet för detta är enkelt. Förutsatt att domänen är förkonfigurerad med en offentlig webbserver:

  • Lägg till en underdomän i din befintliga domän som bör börja med texten: mta-sts (t.ex. mta-sts.domain.com) 
  • Principfilen pekar på den här underdomänen som du skapade och måste lagras i en .välkänd katalog
  • URL:en för principfilen läggs till i DNS-posten när du publicerar din MTA-STS DNS-post så att servern kan fråga DNS om att hämta principfilen under e-postöverföring

5. Aktivera MTA-STS och TLS-RPT

Slutligen måste du publicera dina MTA-STS- och TLS-RPT DNS-poster i domänens DNS, med TXT som resurstyp, placerad på två separata underdomäner (_smtp._tls och _mta-sts). Detta gör att endast TLS-krypterade meddelanden kan nå inkorgen, som är verifierade och ouppnrämda. Dessutom får du dagliga rapporter om leverans- och krypteringsproblem på en e-postadress eller webbserver som konfigurerats av dig från externa servrar.  

Du kan verifiera giltigheten för dina DNS-poster genom att utföra en MTA-STS-postuppslag efter att din post har publicerats och live.  

Vid varje tillfälle du gör ändringar i innehållet i dina MTA-STS-principfiler måste du uppdatera den både på den offentliga webbservern som du är värd för din fil på, samt DNS-posten som innehåller din principadress. Detsamma gäller för varje gång du uppdaterar eller lägger till i dina domäner eller servrar. 

Hur kan MTA-STS-tjänster hjälpa till att lösa "MTA-STS-policy saknas"?

Manuell implementering av MTA-STS kan vara mödosam och utmanande och lämna utrymme för fel. PowerDMARC:s värdbaserade MTA-STS-tjänster hjälper till att katapultera processen för domänägare, vilket gör protokolldistributionen enkel och snabb. Du kan:

  • Publicera dina CNAME-poster för MTA-STS med några klick
  • Outsourca det hårda arbetet med att underhålla och vara värd för MTA-STS-policyfiler och webbservrar
  • Ändra principläget när du vill, direkt från din skräddarsydda instrumentpanel, utan att behöva komma åt din DNS
  • Vi visar SMTP TLS-rapport JSON-filer i ett organiserat och läsbart format som är bekvämt och begripligt för både tekniska och icke-tekniska personer

Det bästa? Vi är RFC-kompatibla och stöder de senaste TLS-standarderna. Detta hjälper dig att komma igång med felfri MTA-STS-konfiguration för din domän och njuta av dess fördelar samtidigt som du lämnar krångel och komplexitet för oss att hantera för din räkning! 

Hoppas att den här artikeln hjälpte dig att bli av med "MTA-STS-principen saknas: STSFetchResult.NONE" prompt och att konfigurera protokollen korrekt för din domän för att minska kryphålen och utmaningarna i SMTP-säkerhet. 

Aktivera MTA-STS för dina e-postmeddelanden idag genom att ta en gratis DMARC-testversionför e-postautentisering , föratt förbättra ditt försvar mot MITM och andra cyber-avlyssningsattacker!