DMARC är ett standardprotokoll för e-postautentisering som när det konfigureras ovanpå befintliga SPF- och DKIM-poster hjälper dig att bekräfta om någon av eller båda autentiseringskontrollerna har misslyckats. Låt oss säga att någon skickar ett e-postmeddelande på uppdrag av ditt företag och det misslyckas DMARC, vilket innebär att du kan vidta en auktoritativ åtgärd. Ett av huvudmålen är att hjälpa företag att skydda sina varumärken och behålla sitt rykte. DMARC skyddar e-postmeddelanden under överföring och hjälper till att förhindra förfalsknings- och phishing-attacker genom att avvisa meddelanden som inte uppfyller vissa standarder. E-postservrar kan också rapportera meddelanden som de får från andra e-postservrar för att hjälpa avsändaren att åtgärda eventuella problem.

Att skydda dina e-postmeddelanden är viktigt för att skydda dina kunder från cyberbrottslingar som kan stjäla deras personliga information. I det här blogginlägget förklarar vi vikten av DMARC och vad du kan göra för att implementera det korrekt för din domän.

Varför ska du använda DMARC?

Om du fortfarande är osäker på om du ska använda DMARC, låt oss räkna ner några fördelar som det ger:

  • DMARC handlar om e-postsäkerhet och leveransbarhet. Det ger robust autentiseringsrapportering, minimerar nätfiske och minskar falska positiva identifieringar.
  • Öka leveransbarheten och minska studsande
  • Få omfattande rapporter om hur meddelanden autentiseras
  • DMARC-protokollet hjälper till att identifiera spammare och förhindrar falska meddelanden från att nå inkorgar
  • DMARC hjälper till att minska risken för att dina e-postmeddelanden markeras eller flaggas som skräppost
  • Ger dig bättre synlighet och auktoritet över dina domäner och e-postkanaler

Vem kan använda DMARC?

DMARC stöds av Microsoft Office 365, Google Workspace och andra populära molnbaserade lösningar. Sedan 2010 har DMARC varit en del av e-postautentiseringsprocessen. Dess syfte var att göra det svårare för cyberbrottslingar att skicka skräppostmeddelanden från en giltig adress, vilket hjälpte till att bekämpa epidemin av phishing-attacker. Domänägare av småföretag, såväl som företag, uppmuntras av branschexperter att skapa en DMARC-post för att ge instruktioner för hur deras e-postdomän ska skyddas. Detta i sin tur hjälper till att skydda deras varumärkes rykte och identitet. 

Hur upprättar du domänens DMARC-post? 

Steg för att konfigurera din domän med e-postautentiseringsprotokoll är följande: 

  • Skapa en SPF-post och kontrollera den med hjälp av en SPF-kontroll för att se till att posten är funktionell och saknar eventuella syntaktiska fel
  • Aktivera DKIM-autentisering för din domän
  • Konfigurera slutligen din domän med DMARC och aktivera DMARC-rapportering genom att konfigurera vår DMARC-rapportanalysator gratis

DMARC har inte bara fått stor betydelse under de senaste åren, utan vissa företag strävar efter att göra det obligatoriskt för sina anställda för att förhindra förlust av känsliga uppgifter och resurser. Därför är det dags att du tar hänsyn till dess olika fördelar och skiftar mot en säkrare e-postupplevelse med DMARC. 

DMARC-poster är ett hopkok av olika mekanismer eller DMARC-taggar som kommunicerar specifika instruktioner till e-postmottagande servrar under e-postöverföring. Var och en av dessa DMARC-taggar innehåller ett värde som definieras av domänägaren. Idag kommer vi att diskutera vad DMARC-taggar och vad var och en av dem står för. 

Här är alla tillgängliga DMARC-taggar som en domänägare kan ange i sin DMARC-post:

DMARC-tagg Typ Standardvärde Vad det betyder
v obligatorisk V-taggen representerar DMARC-protokollversionen och har alltid värdet v=DMARC1 
Pct valfri 100 Den här taggen representerar procentandelen e-postmeddelanden som principläget är tillämpligt på. Läs mer om DMARC pct tag
p obligatorisk Den här taggen adresserar DMARC-principläget. Du kan välja mellan avslag, karantän och ingen. Läs mer om vad som är DMARC-principen för att få klarhet i vilket läge du ska välja för din domän.
Sp valfri Principläget som konfigurerats för huvuddomänen(p) Om du anger underdomänprincipen är sp-taggen konfigurerad för att definiera ett principläge för underdomänerna. Läs mer om DMARC sp-taggen för att förstå när du ska konfigurera den. 
Rua Valfritt men rekommenderat Rua-taggen är en valfri DMARC-tagg som anger e-postadressen eller webbservern där rapporteringsorganisationer ska skicka sina DMARC aggregerade rua-data

Exempel: rua=mailto:[email protected];

ruf (ruf) Valfritt men rekommenderat På samma sätt anger ruf-mekanismen den adress till vilken DMARC kriminalteknisk ruf rapport ska skickas. För närvarande skickar inte alla rapporteringsorganisation kriminaltekniska data. 

Exempel: ruf=mailto:[email protected]

Fo valfri 0 Fo-taggen tillgodoser tillgängliga fel/ kriminaltekniska rapporteringsalternativ domänägare kan välja mellan. Om du inte har aktiverat ruf för din domän kan du ignorera detta. 

De tillgängliga alternativen att välja mellan är: 

0: en DMARC-fel/kriminalteknisk rapport skickas till dig om din e-post misslyckas med både SPF- och DKIM-justering

1: en DMARC-fel/kriminalteknisk rapport skickas till dig när din e-post misslyckas med antingen SPF- eller DKIM-justering

d: en DKIM-felrapport skickas om e-postmeddelandets DKIM-signatur misslyckas med valideringen, oavsett justering

s: en SPF-felrapport skickas om e-postmeddelandet misslyckas med SPF-utvärderingen, oavsett justering.

aspf (aspf) valfri Den här DMARC-taggen står för SPF-justeringsläget. Värdet kan vara antingen strikt eller avslappnat(r)
adkim (adkim) valfri På samma sätt står adkim DMARC-taggen för DKIM-justeringsläget, vars värde kan vara antingen strikt eller avslappnat(r) 
Rf valfri afrf (afrf) DMARC rf-taggen anger de olika formaten för kriminalteknisk rapportering.
Ri valfri 86400 Ri-taggen adresserar tidsintervallet i sekunder mellan två på varandra följande aggregerade rapporter som skickas av rapporteringsorganisationen till domänägaren.

För att skapa en post för DMARC direkt, använd vårt gratis DMARC-generatorverktyg. Alternativt, om du har en befintlig post, kontrollera dess giltighet genom att utföra en DMARC-sökning.

Registrera dig idag för en gratis DMARC-testversion för att få expertråd om hur du skyddar din domän från förfalskare.

Om du som domänägare vill ange vad du vill göra med ett e-postmeddelande som misslyckas med autentiseringen kan DMARC-poster hjälpa dig med det. Ett företag kan publicera en textpost i DNS och ange vad de vill ska hända med e-postmeddelanden som misslyckas med källjusteringen genom att avgöra om det ska levereras, sätta den i karantän eller till och med avvisa den direkt. DMARC pct-taggen är en del av den här posten och talar om för en e-postmottagare hur stor procentandel av meddelandena under den här principen som kommer att påverkas.

Vad betyder pct i DMARC?

En TXT-post för alla e-postautentiseringsprotokoll innehåller en massa mekanismer eller taggar som betecknar instruktioner som är dedikerade till e-postmottagande servrar. I en DMARC-post är pct en förkortning för procent som ingår för att ta itu med procentandelen e-postmeddelanden som DMARC-principen som definierats av domänägaren tillämpas på.

Varför behöver du DMARC pct-taggen?

PCT-taggen är ett ofta förbisett, men ändå effektivt sätt att ställa in och testa domänens DMARC-principer. En DMARC-post med en procentuell tagg ser ut ungefär så här: 

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

I DMARC DNS-posten som visas ovan är andelen e-postmeddelanden för vilka DMARC-avvisningsprincipen är tillämplig 100%. 

Den tid det tar för en domän att gå från att inte använda DMARC alls till att använda de mest restriktiva inställningarna är en ramp-up-period. Detta är avsett att ge domäner tid att bli bekväma med sina nya inställningar. För vissa företag kan detta ta några månader. Det är möjligt för domäner att göra en omedelbar uppgradering, men detta är ovanligt på grund av risken för högre fel eller klagomål. Pct-taggen utformades som ett sätt att gradvis genomdriva DMARC-policyer för att minska utrullningsperioden för onlineföretag. Avsikten är att kunna distribuera den för en mindre batch e-postmeddelanden först innan den distribueras helt till hela e-postströmmen som i det fall som visas nedan: 

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

I den här DMARC DNS-posten gäller avvisningsprincipen för DMARC endast 50% av e-postmeddelandena, medan den andra halvan av volymen omfattas av en karantänsprincip för DMARC, vilket är den näst strängaste principen i rad. 

Vad händer om du inte inkluderar en pct-tagg i din DMARC-post?

När du skapar en DMARC-post med en DMARC-postgeneratorkanske du väljer att inte definiera en pct-tagg och lämna det kriteriet tomt. I det här fallet är standardinställningen för pct inställd på 100, vilket innebär att din definierade policy gäller för alla dina e-postmeddelanden. Därför, om du vill definiera en policy för alla dina e-postmeddelanden, skulle ett enklare sätt att gå tillväga vara att lämna pct-kriteriet tomt, som i det här exemplet:

v=DMARC1; p=karantän; rua=mailto:[email protected];

Varning: Om du vill ha en tvingande princip för DMARC ska du inte publicera en post med pct=0

Logiken bakom detta är enkel: om du vill definiera en avvisnings- eller karantänpolicy i din post vill du i huvudsak att policyn ska tas ut på dina utgående e-postmeddelanden. Att ställa in datorn på 0 upphäver din ansträngning eftersom din policy nu gäller för noll e-postmeddelanden. Detta är samma sak som att ha principläget inställt på p=none. 

Notera: För att skydda din domän från att förfalska attacker och stoppa alla chanser att din domän personifieras av angripare, bör den ideala principen vara DMARC vid p = avvisa; pct = 100;

Flytta till DMARC-tvingande på ett säkert sätt genom att starta din DMARC-resa med PowerDMARC. Ta en gratis DMARC-provperiod idag!

Attributet "sp" är kort för underdomänprincip och är för närvarande inte ett allmänt använt attribut. Det gör det möjligt för en domän att ange att en annan DMARC-post ska användas för underdomäner i den angivna DNS-domänen. För att hålla saker enkla rekommenderar vi att attributet "sp" utelämnas från själva organisationsdomänen. Detta leder till en standard princip för återställning som förhindrar förfalskning på underdomäner. Det är viktigt att komma ihåg att underdomänbeteende alltid bestäms av den övergripande organisations principen. 

Underdomäner ärver den överordnade domänens princip om den inte uttryckligen åsidosätts av en underdomänprincippost. Attributet sp kan åsidosätta det här arvet. Om en underdomän har en explicit DMARC-post har den här posten företräde framför DMARC-principen för den överordnade domänen, även om underdomänen använder standardinställningen p=none. Om till exempel en DMARC-princip definieras för prioritet "alla" kommer sp-elementet att påverka DMARC-bearbetningen på underdomäner som inte omfattas av någon specifik princip.

Varför behöver du DMARC-sp-taggen?

Om du har DMARC-posten som: 

v=DMARC1; p=avvisa; sp=ingen; rua=mailto:[email protected];

I det här fallet, medan din rotdomän är skyddad mot förfalskningsattacker, skulle dina underdomäner även om du inte använder dem för att utbyta information fortfarande vara sårbara för personifieringsattacker.

Om du har DMARC-posten som: 

v=DMARC1; p=ingen; sp=avvisa; rua=mailto:[email protected];

I det här fallet, medan du inte förbinder dig till en avvisningsprincip på rotdomänen som du använder för att skicka dina e-postmeddelanden, är dina inaktiva underdomäner fortfarande skyddade mot personifiering. 

Om du vill att domän- och underdomänprinciperna ska vara desamma kan du lämna sp-taggkriteriet tomt eller inaktiverat när du skapar en post, och dina underdomäner ärver automatiskt principen som tas ut på huvuddomänen. 

Om du använder vårt DMARC-postgeneratorverktyg för att skapa en DMARC-post för din domän måste du aktivera knappen för underdomänprincip manuellt och definiera önskad princip, till exempel visar nedan:

 

När du har skapat din DMARC-post är det viktigt att kontrollera giltigheten för din post med hjälp av vårt DMARC-postuppslagsverktyg för att se till att din post är felfri och giltig.

Starta din DMARC-resa med PowerDMARC för att maximera domänens e-postsäkerhet. Ta din kostnadsfria DMARC-provperiod idag!

På grund av hoten som lurar online måste företag bevisa att de är legitima genom att använda starka autentiseringsmetoder. En vanlig metod är via DomainKeys Identified Mail (DKIM), en e-postautentiseringsteknik som använder krypteringsnycklar för att verifiera avsändarens domän. DKIM tillsammans med SPF och DMARC har drastiskt förbättrat e-postsäkerhetsställningen för organisationer globalt.

Läs mer om vad som är DKIM.

När du konfigurerar DKIM för dina e-postmeddelanden är ett av de primära besluten du måste fatta att bestämma DKIM-nyckellängden. I den här artikeln tar vi dig igenom den rekommenderade nyckellängden för bättre skydd och hur du uppgraderar dina nycklar i Exchange Online Powershell.

Vikten av att uppgradera din DKIM-nyckellängd

Att välja 1024 bit eller 2048 bit är ett viktigt beslut som måste fattas när du väljer din DKIM-nyckel. I åratal har PKI (infrastruktur för offentliga nycklar) använt 1024-bitars DKIM-nycklar för sin säkerhet. Men när tekniken blir mer komplex arbetar hackare hårt för att hitta nya metoder för att lamslå säkerheten. På grund av detta har viktiga längder blivit allt viktigare.

När hackare fortsätter att uppfinna bättre sätt att bryta DKIM-nycklar. Nyckelns längd är direkt korrelerad med hur svårt det är att bryta autentiseringen. Att använda en 2048-bitnyckel ger förbättrat skydd och förbättrad säkerhet mot nuvarande och framtida attacker, vilket belyser vikten av att uppgradera din bitness.

Uppgradera dina DKIM-nycklar manuellt i Exchange Online Powershell

  • Börja med att ansluta till Microsoft Office 365 PowerShell som administratör (Kontrollera att Powershell-kontot är konfigurerat för att köra signerade Powershell-skript)
  • Om DKIM är förkonfigurerat kan du uppgradera nycklarna till 2048 bitar och köra följande kommando på Powershell: 

Rotera-DkimSigningConfig -KeySize 2048 -Identitet {Guid för den befintliga signeringskonfetten}

  • Om du inte har implementerat DKIM tidigare kör du följande kommando på Powershell: 

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

  • Slutligen, för att kontrollera att du har konfigurerat DKIM med en uppgraderad bithet på 2048 bitar, kör du följande kommando:

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

Observera: Se till att du är ansluten till Powershell under hela proceduren. Det kan ta upp till 72 timmar innan ändringarna genomförs. 

DKIM räcker inte för att skydda din domän mot förfalskning och BEC. Uppgradera domänens e-postsäkerhet genom att konfigurera DMARC för Office 365.

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!