DMARC

DMARC er en serie med beskyttelsesmekanismer som kan benyttes ved å legge inn spesielle innslag i Domain Name System (DNS).

Med DMARC får man i hovedsak tre ting:

• Beskyttelse mot e-postforfalskning av egne domener
• Blokkering av forfalsket e-post fra andres domener
• Automatisk rapportering av forfalsket e-post til eieren av domenet

Når en e-post kommer inn til mottakende e-postserver kan e-postserveren slå opp i DNS og finne informasjon om hva eieren av domenet til avsenderen sier man skal gjøre med e-posten.

Et fullverdig DMARC-oppsett er et samspill mellom tre typer regler: SPF, DKIM og DMARC.

Her er en oversikt over måtene man kan sette regler for e-postdomener. Med e-postdomene menes det som kommer etter "@" i adressen.

Har e-posten gyldig avsender? Sender Policy Framework (SPF)

Domenet som står i e-postadressen til avsenderen kan slås opp i DNS. Dersom eieren av domenet har lagt inn SPF-regler for domenet i DNS, vil svaret derfra si noe om det skal komme e-poster fra dette domenet, med mulighet til å spesifisere hvilke IP-adresser som er gyldige avsenderadresser.

Hva skal mottaker gjøre med e-posten?

I en SPF-regel kan man indikere til mottaker hva de skal gjøre med e-posten.

Disse reglene kommer vanligvis rett foran ordet "all", som indikerer slutten på et SPF-innslag.

Eksempel i DNS med ugyldiggjøring av all e-post fra domenet

Denne regelen sier at e-poster from kommer fra domenet example.com, for eksempel admin@example.com, ikke skal regnes som gyldig. Mottakende e-postserver kan da velge å slette slike e-poster før de havner i en innboks.

Eksempel i DNS med validering av all e-post fra domenet

Denne regelen sier at e-poster som kommer fra domenet example.com, for eksempel admin@example.com, skal regnes som gyldig, selv om de ikke kommer fra server med adresse 176.32.103.205.

Eksempel i DNS med ugyldiggjøring av e-post som ikke kommer fra spesifikke adresser

Her sier regelen at dersom e-posten ikke kommer fra den spesifiserte IPv4-adressen eller IPv6-adressen eller fra adressene som pekes på av example.org, så skal e-posten regnes som ugyldig.

Dette er bare et par eksempler, men i virkeligheten trenger man ikke stort flere regler for SPF. Om man likevel har mer kompliserte behov har man finkornet kontroll. Les mer om alle elementene i en SPF-regel her.

SPF-tips

• Alle hoveddomener anbefales å ha SPF-innslag
• Hoveddomener som det ikke skal sendes e-post på vegne av bør ha SPF-innslag "v=spf1 -all"
• Alle underdomener som det skal sendes e-post på vegne av bør også ha SPF-innslag. For eksempel staff.example.com i tillegg til hoveddomenet (her example.com).
• For underdomener som det _ikke_ skal sendes e-post på vegne av anbefaler vi å ikke legge inn SPF-innslag forutsatt at man har DMARC-oppføring med policy p=reject.
• Her er link til beskrivelse av SPF-syntaks.
• Internet.nl har en testside som sjekker om man har gyldig syntaks, og om den er sikker (bruk boksen "Test your email").

Er avsender autorisert for å sende denne e-posten? Domain Keys Identified Mail (DKIM)

En alternativ måte å fortelle en mottakende e-postserver at avsenderen er gyldig er å legge inn en digital signatur i e-postene som sendes ut. Denne signaturen kan sjekkes av den mottakende e-postserveren ved å slå opp i DNS etter en DKIM-regel.

Eksempel på DKIM-informasjon i en e-post

Tilsvarende eksempel på DKIM-innslag i DNS

Merk her at DKIM-informasjonen i e-posten forteller hvor den mottakende e-postserveren skal slå opp, som alltid har følgende mønster:

<s-feltet i e-posten>._domainkey.<d-feltet i e-posten>

I vårt eksempel blir det:

Videre så blir bh-feltet fra e-posten og p-feltet fra DKIM-innslaget i DNS brukt sammen til å verifisere at avsenderen er gyldig, ettersom de ble opprettet av eieren av domenet og er kryptografisk avhengig av hverandre. Dersom signaturen ikke stemmer, kan mottakerserveren velge å slette e-posten før den havner i en innboks.

DKIM-tips

• DKIM-signering er nødvendig for å validere e-post som blir automatisk videresendt. Office 365 støtter DKIM-signering.
• Spørreundersøkelser og andre tjenester for masseutsendelser kan være en utfordring. Flere slike tjenester støtter DKIM-signering.
• Lag DKIM-innslag for alle domener (for eksempel intranet.example.com), ikke bare hoveddomener (example.com)
• Det er lurt å bytte ut signaturen med jevne mellomrom for å beskytte seg mot kryptografiske svakheter.

Er avsender gyldig, og adressene riktig? Send rapport! - DMARC

Alle e-poster inneholder to sett med til og fra felt, akkurat som et brev har avsender og mottaker både på konvolutten og selve brevet. Ett av dem brukes til å få e-posten dit den skal, og ett vises til brukeren som informasjon. Ulempen med å kun ha enten SPF eller DKIM er at avsenderadressen som sjekkes ikke er den som vises til brukeren, og avsender kan dermed likevel lure mottakeren.

Her kommer DMARC inn. DMARC validerer dersom enten SPF eller DKIM validerer og avsenderdomenet stemmer overens med den adressen som blir presentert i e-postklienten. Da vet mottaker at avsenderadressen tilhører den som sendte e-posten.

Hva skal skje med e-post som ikke er gyldig ifølge DMARC? Igjen legger man inn regler i DNS for domenet man ønsker å sende e-post fra, og mottaker kan sjekke disse. Det viktigste elementet i en DMARC-regel er policy, som sier hva som skal skje med e-posten.

Eksempel på DMARC-regel i DNS som ikke ber om blokkering

Her ser vi en DMARC-regel for example.com. Et domene i en DMARC-regel vil alltid ha formatet: _dmarc.<domenet>

som her blir:

I denne regelen har vi sagt at selv om DMARC ikke validerer så skal det ikke gjøres noe med den, vi tillater med andre ord at ingen av reglene blir fulgt.

Eksempel på DMARC regel i DNS som ber om blokkering

Her ser vi en DMARC-regel der eieren av domenet har sagt at dersom DMARC ikke validerer så skal e-posten avvises. Med andre ord, dersom DKIM eller SPF ikke validerer eller domenet til avsenderen ikke stemmer med det som vises til brukeren, så ber eieren av domenet om at e-posten avvises.

En vesentlig del av DMARC er at man kan be om at brudd på reglene rapporteres. Dette kan spesifiseres i DMARC-regelen.

Eksempel på DMARC regel i DNS som ber om blokkering og sender både rapporter og kopi av ugyldige e-poster

Rapporten man får ved å spesifisere rua-feltet er en samling med rapporter om godkjente og avviste e-poster, mens adressen i ruf-feltet får en e-post med kopi av den ugyldige e-posten som vedlegg.

Dersom man ønsker å benytte samme rapporterings-adresse for andre hoveddomener, må man legge inn en egen regel som beskriver dette:

Eksempel på DMARC-innslag i DNS som muliggjør sending av rapporter som omhandler example.net til adresser fra example.com

DMARC-tips

• Begynn med å sette p=none på alle domener og be om aggregatrapporter for å slippe gjennom all e-post, men samtidig motta rapport på at det har skjedd noe.
• For domener som ikke skal sende e-post bør man legge inn: p=reject
• Hvis du har domener som skal behandles likt av DMARC, kan man opprette ett DMARC-innslag og flere CNAME-innslag som peker til denne. På den måten er det mulig å endre DMARC-record for mange domener samtidig. Eksempel:

  

• DMARC for et domene gjelder også for subdomener som ikke har satt egen DMARC-regel.
• Det finnes kommersielle tjenester som kan bidra til å gi god oversikt i DMARC-rapportene. Vi anbefaler at man bruker en slik.
• Dmarc-standarden er beskrevet her.
• Det finnes flere gode verktøy for å teste om man har korrekt DMARC-syntaks. Et slikt er på internet.nl i boksen "Test your email".