DMARC er en standard e -postgodkjenningsprotokoll som, når den er konfigurert på toppen av eksisterende SPF- og DKIM -poster, hjelper deg med å bekrefte om en eller begge godkjenningskontrollene har mislyktes. La oss si at noen sender en e -post på vegne av din bedrift, og den mislykkes med DMARC, noe som betyr at du kan iverksette en autoritativ handling. DMARC er designet for å stoppe spam og nettfisking i sine spor ved å hjelpe bedrifter med å håndtere e -postsikkerhet. Et av hovedmålene er å hjelpe selskaper med å beskytte merkevarene sine og opprettholde sitt rykte. DMARC beskytter e -post under transport og forhindrer spoofing og phishing -angrep ved å avvise meldinger som ikke oppfyller visse standarder. E -postservere kan også rapportere meldinger de mottar fra andre e -postservere for å hjelpe avsenderen med å løse eventuelle problemer.

Beskyttelse av e -postene dine er viktig for å holde kundene trygge for cyberkriminelle som kan stjele deres personlige informasjon. I dette blogginnlegget forklarer vi viktigheten av DMARC og hva du kan gjøre for å implementere det riktig for domenet ditt.

Hvorfor bør du bruke DMARC?

Hvis du fortsatt er usikker på om du skal bruke DMARC, la oss telle ned noen fordeler som det gir:

  • DMARC handler om e -postsikkerhet og leveringsdyktighet. Det gir robust autentiseringsrapportering, minimerer phishing og reduserer falske positiver.
  • Øk leveransen og reduser sprett
  • Motta omfattende rapporter om hvordan meldinger blir autentisert
  • DMARC -protokollen hjelper til med å identifisere spammere og forhindrer at falske meldinger når innbokser
  • DMARC bidrar til å redusere sjansen for at e -postene dine blir merket eller flagget som søppelpost
  • Gir deg bedre synlighet og autoritet over domenene dine og e -postkanalene

Hvem kan bruke DMARC?

DMARC støttes av Microsoft Office 365, Google Workspace og andre populære skybaserte løsninger. Siden 2010 har DMARC vært en del av e -postgodkjenningsprosessen. Målet var å gjøre det vanskeligere for cyberkriminelle å sende spam -e -post fra en gyldig adresse, og bidra til å bekjempe epidemien av phishing -angrep. Domeneeiere av små bedrifter, så vel som bedrifter, oppfordres av bransjeeksperter til å lage en DMARC -post for å gi instruksjoner for hvordan e -postdomenet deres skal beskyttes. Dette bidrar igjen til å beskytte merkevarenes rykte og identitet. 

Hvordan oppretter du domenets DMARC -post? 

Fremgangsmåten for å konfigurere domenet ditt med e -postgodkjenningsprotokoller er som følger: 

  • Lag en SPF -post og kontroller den med en SPF -kontroller for å sikre at posten er funksjonell og uten mulige syntaktiske feil
  • Aktiver DKIM -godkjenning for domenet ditt
  • Endelig konfigurer domenet ditt med DMARC og aktiver DMARC -rapportering ved å konfigurere DMARC -rapportanalysatoren vår gratis

DMARC har ikke bare fått betydelig betydning de siste årene, men noen selskaper streber etter å gjøre det obligatorisk for sine ansatte for å forhindre tap av sensitive data og ressurser. Derfor er det på tide at du tar hensyn til de forskjellige fordelene og går mot en tryggere e -postopplevelse med DMARC. 

DMARC -poster er en sammensetning av forskjellige mekanismer eller DMARC -tagger som kommuniserer spesifikke instruksjoner til e -postmottakende servere under postoverføring. Hver av disse DMARC -taggene inneholder en verdi som er definert av domeneeieren. I dag skal vi diskutere hva som er DMARC -tagger og hva hver av dem står for. 

Her er alle tilgjengelige DMARC -tagger som en domeneeier kan angi i DMARC -posten:

DMARC -tag Type Standardverdi Hva det betyr
v påbudt, bindende V -taggen representerer DMARC -protokollversjonen og har alltid verdien v = DMARC1 
pct valgfri 100 Denne taggen representerer prosentandelen e -poster som policy -modusen gjelder for. Les mer om DMARC pct -tag
s påbudt, bindende Denne taggen adresserer DMARC policy -modus. Du kan velge mellom avvisning, karantene og ingen. Lær mer om hva som er DMARC -retningslinjene for å få klarhet i hvilken modus du skal velge for domenet ditt.
sp valgfri Retningslinjemodus konfigurert for hoveddomenet (p) SP -taggen angir underdomenet, og er konfigurert til å definere en policy -modus for underdomenene dine. Lær mer om DMARC sp -tag for å forstå når du skal konfigurere den. 
rua Valgfritt, men anbefales Rua -taggen er en valgfri DMARC -tag som angir e -postadressen eller webserveren der rapporteringsorganisasjoner skal sende sine DMARC -aggregerte ruadata

Eksempel: rua = mailto: [email protected];

ruf Valgfritt, men anbefales På samme måte spesifiserer ruf -mekanismen adressen som DMARC rettsmedisinsk ruf -rapport skal sendes. Foreløpig sender ikke alle rapporterende organisasjoner rettsmedisinske data. 

Eksempel: ruf = mailto: [email protected]

fo valgfri 0 Fo -taggen henvender seg til de tilgjengelige feilene/rettsmedisinske rapporteringsalternativer domeneeiere kan velge mellom. Hvis du ikke har aktivert ruf for domenet ditt, kan du ignorere dette. 

De tilgjengelige alternativene å velge mellom er: 

0: en DMARC -feil/rettsmedisinsk rapport blir sendt til deg hvis e -posten din mislykkes med både SPF og DKIM -justering

1: en DMARC -feil/rettsmedisinsk rapport blir sendt til deg når e -posten din ikke klarer SPF- eller DKIM -justering

d: en DKIM -feilrapport sendes hvis e -postens DKIM -signatur mislykkes validering, uavhengig av justeringen

s: en SPF -feilrapport sendes hvis e -posten mislykkes med SPF -evaluering, uavhengig av justeringen.

aspf valgfri Denne DMARC -taggen står for SPF -justeringsmodus. Verdien kan være enten streng (er) eller avslappet (r)
adkim valgfri På samme måte står adkim DMARC -taggen for DKIM -justeringsmodus, hvis verdi enten kan være streng (er) eller avslappet (r) 
rf valgfri afrf DMARC rf -taggen angir de forskjellige formatene for rettsmedisinsk rapportering.
ri valgfri 86400 Ri -taggen adresserer tidsintervallet i sekunder mellom to påfølgende samlede rapporter sendt av rapporteringsorganisasjonen til domeneeieren.

For å lage en post for DMARC umiddelbart, bruk vårt gratis DMARC -generatorverktøy . Alternativt, hvis du har en eksisterende post, sjekk dens gyldighet ved å utføre et DMARC -oppslag .

Registrer deg i dag for en gratis DMARC -prøveperiode for å få ekspertråd om hvordan du beskytter domenet ditt mot forfalskninger.

Hvis du som domeneeier vil spesifisere hva du skal gjøre med en e -post som ikke godkjenner autentisering, kan DMARC -poster hjelpe deg med det. Et selskap kan publisere en tekstpost i DNS og spesifisere hva de vil at skal skje med e -postmeldinger som ikke klarer kildejustering ved å bestemme om de skal levere den, sette den i karantene eller til og med avvise den. DMARC pct -taggen er en del av denne posten og forteller en e -postmottaker hvor mange prosent av meldingene under denne policyen som vil bli påvirket.

Hva betyr pct i DMARC?

En TXT -post for en hvilken som helst e -postgodkjenningsprotokoll inneholder en haug med mekanismer eller koder som angir instruksjoner dedikert til e -postmottakende servere. I en DMARC -post er pct et akronym for prosent som er inkludert for å adressere prosentandelen e -poster som DMARC -policyen som er definert av domeneeieren, brukes på.

Hvorfor trenger du DMARC pct -taggen?

PCT-taggen er en ofte oversett, men likevel effektiv måte å sette opp og teste domenets DMARC-retningslinjer på. En DMARC -post med en prosentmerke ser omtrent slik ut: 

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

I DMARC DNS -posten vist ovenfor er prosentandelen e -poster som DMARC -retningslinjene for avvisning gjelder for 100%. 

Tiden det tar før et domene går fra å ikke bruke DMARC i det hele tatt, til å bruke de mest restriktive innstillingene, er en oppstartsperiode. Dette er ment å gi domener tid til å bli komfortabel med sine nye innstillinger. For noen virksomheter kan dette ta noen måneder. Det er mulig for domener å gjøre en umiddelbar oppgradering, men dette er uvanlig på grunn av risikoen for høyere feil eller klager. PCT-koden ble designet som en måte å gradvis håndheve DMARC-retningslinjer for å redusere utrullingsperioden for online virksomheter. Hensikten er å kunne distribuere den for en mindre mengde e -poster først før den distribueres fullstendig til hele e -poststrømmen, som i tilfellet vist nedenfor: 

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

I denne DMARC DNS -posten gjelder avvisningspolicyen for DMARC bare 50% av e -postene, mens den andre halvdelen av volumet er underlagt en karantene -politikk for DMARC, som er den nest strengeste politikken i rekken. 

Hva vil skje hvis du ikke inkluderer en pct -tag i DMARC -posten?

Mens du oppretter en DMARC -post ved hjelp av en DMARC -registreringsgenerator , kan du velge å ikke definere en pct -kode og la det kriteriet stå tomt. I dette tilfellet er standardinnstillingen for pct satt til 100, noe som betyr at din definerte policy vil gjelde for alle e -postene dine. Derfor, hvis du vil definere en policy for alle e -postene dine, ville en enklere måte å gå frem på er å la pct -kriteriet stå tomt, som i dette eksemplet:

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

Advarsel : Hvis du vil ha en håndhevet policy for DMARC, ikke publiser en post med pct = 0

Logikken bak dette er enkel: Hvis du vil definere en avvisning eller karantene -politikk i posten, vil du i hovedsak at policyen skal belastes din utgående e -post. Å sette din PC til 0 annullerer din innsats ettersom retningslinjene dine nå gjelder for null e -post. Dette er det samme som å ha policy -modusen satt til p = none. 

Merk : For å beskytte domenet ditt mot spoofing -angrep og forhindre sjanser for at domenet ditt etterlignes av angripere, bør den ideelle politikken være DMARC på p = reject; pct = 100;

Skift til DMARC -håndhevelse trygt ved å starte din DMARC -reise med PowerDMARC. Ta en gratis DMARC -prøveperiode i dag!

Attributtet "sp" er en forkortelse for underdomener og er for øyeblikket ikke et mye brukt attributt. Det tillater et domene å spesifisere at en annen DMARC -post skal brukes for underdomener til det angitte DNS -domenet. For å gjøre ting enkelt, anbefaler vi at 'sp' -attributtet utelates fra selve organisasjonsdomenet. Dette vil føre til en tilbakevendende standardpolicy som forhindrer forfalskning på underdomener. Det er viktig å huske at underdomenets atferd alltid bestemmes av den overordnede organisasjonspolitikken. 

Underdomener arver hoveddomene sine retningslinjer med mindre det eksplisitt blir tilsidesatt av en underdomeneregistreringspost. 'Sp' -attributtet kan overstyre denne arven. Hvis et underdomene har en eksplisitt DMARC -post, vil denne posten gå foran DMARC -policyen for det overordnede domenet, selv om underdomenet bruker standardinnstillingen p = none. For eksempel, hvis en DMARC -policy er definert for prioritet "alle", vil "sp" -elementet påvirke DMARC -behandling på underdomener som ikke dekkes av noen spesifikke retningslinjer.

Hvorfor trenger du DMARC sp -taggen?

Hvis du har DMARC -posten din som: 

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

I dette tilfellet, mens rotdomenet ditt er beskyttet mot forfalskningsangrep, vil underdomenene dine, selv om du ikke bruker dem til å utveksle informasjon, fortsatt være sårbare for etterligningsangrep.

Hvis du har DMARC -posten din som: 

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

I dette tilfellet, mens du ikke forplikter deg til å avvise retningslinjer for rotdomenet du bruker til å sende e -postene dine, er dine inaktive underdomener fortsatt beskyttet mot etterligning. 

Hvis du vil at domenen din og underdomenet skal være de samme, kan du la sp -tag -kriteriet stå tomt eller deaktivert mens du oppretter en post, og underdomenene dine vil automatisk arve policyen som pålegges på hoveddomenet. 

Hvis du bruker vårt DMARC -registreringsgeneratorverktøy for å lage en DMARC -post for domenet ditt, må du manuelt aktivere knappen for underdomener og definere ønsket policy, som viser nedenfor:

 

Etter at du har opprettet DMARC-posten din, er det viktig å sjekke gyldigheten av posten din ved hjelp av vårt DMARC-oppslagsverktøy for å sikre at posten er feilfri og gyldig.

Start din DMARC -reise med PowerDMARC for å maksimere domenets e -postsikkerhet. Ta din gratis DMARC -prøveperiode i dag!

På grunn av truslene som lurer på nettet, må bedrifter bevise at de er legitime ved å bruke sterke autentiseringsmetoder. En vanlig metode er gjennom DomainKeys Identified Mail (DKIM), en e -postgodkjenningsteknologi som bruker krypteringsnøkler for å bekrefte avsenderens domene. DKIM sammen med SPF og DMARC har drastisk forbedret e -postsikkerhetsstillingene til organisasjoner globalt.

Les mer om hva som er DKIM .

Mens du konfigurerer DKIM for e -postene dine, er en av de viktigste beslutningene du må ta å bestemme DKIM -nøkkellengden. I denne artikkelen tar vi deg gjennom anbefalt nøkkellengde for bedre beskyttelse og hvordan du oppgraderer nøklene dine i Exchange Online Powershell.

Viktigheten av å oppgradere DKIM -nøkkellengden

Å velge 1024 bit eller 2048 bit er en viktig beslutning som må tas når du velger DKIM -nøkkelen. I årevis har PKI (offentlig nøkkelinfrastruktur) brukt 1024 biters DKIM -nøkler for sikkerheten. Etter hvert som teknologien blir mer kompleks, jobber hackere imidlertid hardt for å finne nye metoder for å ødelegge sikkerheten. På grunn av dette har nøkkellengder blitt stadig viktigere.

Etter hvert som hackere fortsetter å finne opp bedre måter å bryte DKIM -nøkler på. Lengden på nøkkelen er direkte korrelert med hvor vanskelig det er å bryte autentiseringen. Ved hjelp av en 2048 biters nøkkel gir forbedret beskyttelse og forbedret sikkerhet mot nåværende og fremtidige angrep, og understreker viktigheten av å oppgradere bitness.

Manuell oppgradering av DKIM -nøklene i Exchange Online Powershell

  • Start med å koble til Microsoft Office 365 PowerShell som administrator (Sørg for at Powershell -kontoen din er konfigurert til å kjøre signerte Powershell -skript)
  • Hvis DKIM er forhåndskonfigurert, kjører du følgende kommando på Powershell for å oppgradere nøklene til 2048 bits: 

Rotate -DkimSigningConfig -KeySize 2048 -Identity {Veiledning for den eksisterende signeringskonfigurasjonen}

  • Hvis du ikke har implementert DKIM tidligere, kjører du følgende kommando på Powershell: 

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

  • Til slutt, for å bekrefte at du har konfigurert DKIM med en oppgradert bitness på 2048 bits, kjører du følgende kommando:

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

Merk : Sørg for at du er koblet til Powershell gjennom hele prosedyren. Det kan ta opptil 72 timer før endringene er implementert.

DKIM er ikke nok til å beskytte domenet ditt mot forfalskning og BEC. Oppgrader domenets e -postsikkerhet ved å konfigurere DMARC for office 365 .

Den etterlengtede utrullingen er endelig her! Microsoft sender samlede DMARC RUA -rapporter til sine brukere, og det er sannsynlig at du kanskje ikke har lagt merke til det. Microsoft DMARCs samlede rapporter sendes fra følgende e -postadresse : [email protected] Den rå Microsoft DMARC -aggregeringsfilen sendes i standard XML -format. Microsoft har endelig omfavnet DMARC -rapportering, noe som i hovedsak betyr at nå Hotmail-, Outlook-, Live- og msn.com -brukere vil kunne glede seg over de forskjellige fordelene med Microsoft DMARC -aggregerte data.

Behandler aggregerte data fra Microsoft DMARC

PowerDMARC rapportanalysator analyserer Microsoft DMARCs samlede data i et organisert format som vil hjelpe deg med å behandle dem mer effektivt.  

For å hjelpe brukerne med å dra fordeler av samlede rapportdata sendt av Microsoft, har PowerDMARCs DMARC -rapportanalysator blitt forhåndskonfigurert til å motta rapportene sine direkte på plattformen. Alt brukerne trenger å gjøre er å legge til domenene sine på PowerDMARC -plattformen sammen med å konfigurere DMARC DNS -posten, mens vi behandler og presenterer rapportene på en enkel og forståelig måte. Her finner du:

  • DMARC -aggregerte data sendt fra Hotmail-, Outlook-, Live- og msn.com -mottakeradresser analysert fra rå XML -filformat til enkel og lesbar informasjon organisert i tabeller
  • PowerDMARC er forhåndskonfigurert til å omgå RFC -brudd, slik at vi kan motta og analysere DMARC -dataene dine sendt av Microsoft -servere uten at du trenger å bekymre deg for det
  • Registrer flere domener, overvåke e -postkanalene dine og foreta DNS -endringer direkte fra dashbordet med brukbare knapper på fingertuppene
  • Filtrer resultatene i forskjellige kategorier, for eksempel per resultat, per senderkilde, per organisasjon, per land, geolokalisering og detaljert statistikk eller søkeresultater per domene i søkefeltet
  • Få dypere innsikt i ytelsen til e -postene dine, og få raskt opp forsøk på domenespoofing, etterligning eller falske e -postmeldinger som sendes med Microsofts forretningsdomener. Du vil også kunne analysere eventuelle SPF, DKIM -feil fra sendingskildene dine.

Vist ovenfor er et skjermbilde av våre DMARC -samlede rapporter per organisasjon som viser DMARC RUA -data sendt fra Microsoft.

Problemer du kan stå overfor mens du håndterer Microsoft DMARC -aggregatrapporter på egen hånd

Microsoft DMARC-aggregerte e-poster er ikke RFC-kompatible

Det primære problemet som brukere har stått overfor med disse e -postene som inneholder rapporter som sendes av Microsoft, er at de ikke er i samsvar med RFC -spesifikasjonene for Internett -e -post. Selv om RFC 5322 kapittel 2.1.1 tydelig sier at en linje med tegn ikke må overskride 78 tegn, er BASE64 -vedleggsdataene i disse Microsoft DMARC -aggregatene en kontinuerlig linje uten riktige linjeskift som overskrider grensen på 78 tegn. Det resulterende RFC -bruddet er grunnen til at de fleste av disse e -postene havner i brukerens avvisingslogg i stedet for å bli levert til innboksen. 

Rå XML -filer er vanskelig å lese

I likhet med DMARC -dataene som er sendt av alle rapporterende organisasjoner, er RUA -filen i utvidbart kodespråk (XML) som er vanskelig å lese og forstå.

Forutsetninger for å motta Microsoft DMARC RUA

For å motta samlede rapporter for domenene dine på outlook.com må du sørge for at du har en gyldig PowerDMARC -post publisert på DNS, sammen med en definert DMARC -policy. Rapporterende organisasjoner sender deretter samlede rapportdata til din angitte webserver eller e -postadresse. Dette vil hjelpe deg med å få synlighet og DMARC-samsvar med e-postleverandører fra tredjeparter som du ellers ikke har kontroll over. 

Beskytt domenene dine på Microsoft Office365 og andre ved å starte e -postgodkjenningsreisen din i dag. Kom ombord med en gratis DMARC -prøveversjon eller planlegg en DMARC -demo , og utforsk fordelene ved å implementere en robust e -postsikkerhetsstilling i organisasjonen din!