Sett opp DMARC uten å avvise legitim e-post

For å sette opp DMARC på et bedriftsdomene uten å ramme legitim e-post må du kartlegge alle tjenestene som sender med domenet i det synlige Fra-feltet. Hver utsendelse må bestå SPF eller DKIM med et domene som samsvarer med Fra-domenet. Begynn med policyen p=none og en adresse for rapporter. Gå videre til karantene og avvisning først når legitime utsendelser som feiler, er rettet.

Med p=none ber du ikke mottakeren om å avvise e-post på grunn av DMARC-feil; mottakerens øvrige filtre kan fortsatt påvirke leveringen. Googles oppsettsveiledning anbefaler at SPF eller DKIM er aktivert, og at autentiseringen får virke i minst 48 timer før DMARC-posten legges til. Tiden gir deg også anledning til å kontrollere faktiske meldinger før rapporteringen starter.

Kartlegg avsenderne før du endrer DNS

Start med adressene mottakerne faktisk ser, ikke bare systemet som håndterer de ansattes innbokser. CRM, fakturasystem, nettsted, nyhetsbrevtjeneste og automatiske varsler kan sende e-post med samme Fra-domene. Finn ansvarlig for hver tjeneste og noter hva den sender, hvilket Fra-domene den bruker, og hvem som kan endre autentiseringen. Ta også med utsendelser som bare skjer ved kampanjer, årsoppgjør eller betalingspåminnelser.

Før et enkelt avsenderkart med Fra-domene, SPF-domenet i returadressen, DKIM-domenet i signaturen og tjenesteeier. En kort periode uten rapportert trafikk er ikke bevis for at en sjelden brukt tjeneste er avviklet. Dersom en ekstern utsendingstjeneste kan bruke et eget underdomene, kan det gjøre ansvaret og senere feilsøking tydeligere. Også dette underdomenet må testes med de adressene mottakerne ser.

Få SPF eller DKIM til å samsvare med Fra-domenet

En vellykket SPF- eller DKIM-kontroll er ikke alene nok. DMARC sammenligner domenet i Fra-feltet med domenet som SPF har godkjent, eller domenet i en gyldig DKIM-signatur. Det holder at én av metodene både består kontrollen og har domenesamsvar. En tjeneste kan derfor få SPF=pass for sitt eget returdomene, men likevel feile DMARC når Fra-feltet viser virksomhetens domene.

Send en representativ melding fra hver tjeneste til en postkasse der du kan se hele meldingshodet. Se etter Authentication-Results og sammenlign header.from med smtp.mailfrom for SPF og header.d for DKIM, der mottakeren oppgir disse verdiene. Hvis leverandørens returdomene ikke samsvarer, spør om tjenesten støtter et eget returdomene under virksomhetens domene. Alternativt kan tjenesten signere med virksomhetens domene i DKIM. Send en ny melding etter endringen: en DNS-post viser ikke alene hvilken signatur eller returadresse tjenesten faktisk bruker.

Vanlig domenesamsvar tillater underdomener som hører til samme organisasjonsdomene. Strengere krav om nøyaktig samsvar bør vente til avsenderkartet viser hvordan alle tjenestene bruker returadresser og DKIM-signaturer. Videresending kan bryte SPF fordi en annen tjener leverer meldingen videre; en gyldig DKIM-signatur kan fortsatt gi DMARC-samsvar dersom meldingen ikke er endret slik at signaturen blir ugyldig.

Publiser posten og kontroller DNS-oppslaget

Opprett en postkasse for aggregerte rapporter. I et tenkt eksempel der virksomheten kontrollerer eksempel.no, kan TXT-posten på _dmarc.eksempel.no ha verdien v=DMARC1; p=none; rua=mailto:[email protected]. Bytt både domene og rapportadresse til verdier virksomheten kontrollerer. Noen DNS-paneler ber om hele vertsnavnet, mens andre legger til domenet automatisk når du skriver _dmarc.

Slå opp den publiserte verdien med dig TXT _dmarc.eksempel.no +short. Kontroller SPF med dig TXT eksempel.no +short. For DKIM bruker du selektoren tjenesten oppgir, for eksempel dig TXT velger._domainkey.eksempel.no +short; dersom leverandøren bruker CNAME, slår du opp den posttypen i stedet. Kontroller at DMARC-oppslaget gir den tiltenkte verdien, og at det ikke ligger flere DMARC-poster på samme navn. DNS-kontrollen viser hva som er publisert, mens testmeldingene viser om utsendingstjenestene bruker oppsettet riktig.

Bruk rapportene til å finne legitime feil

Adressen i rua-feltet kan motta aggregerte rapporter fra mottakere som velger å sende dem. Rapportene samler blant annet avsendende IP-adresser, meldingsantall, autentiseringsresultater og mottakerens behandling. De kommer ofte som komprimerte XML-filer, så bruk et verktøy som kan gruppere resultatene etter Fra-domene, avsender og utfall. Rapportene er et kart over observert trafikk, ikke en fullstendig liste over alt virksomheten noen gang sender.

Undersøk først DMARC-feil fra kilder som ligner kjente tjenester i avsenderkartet. Sammenlign IP-adresse, utsendelsesmønster og domeneverdier, og få tjenesteeieren til å bekrefte trafikken før du endrer SPF eller DKIM. En ukjent kilde kan være forfalskning, men rapporten alene forteller ikke hvem som står bak. Manglende rapport fra en mottaker betyr heller ikke at den ikke har mottatt meldinger.

Se dessuten på både autentisering og samsvar i resultatene. SPF=pass for leverandørens domene kan opptre samtidig med DMARC=fail for virksomhetens Fra-domene. Når en legitim strøm feiler, retter du returdomene eller DKIM-signering hos den ansvarlige tjenesten og sammenholder nye rapporter med en ny testmelding. Gjenta kontrollen for underdomener og for meldingstyper som sendes sjelden.

Stram inn først når legitim trafikk består

Bytt til p=quarantine når kjente avsendere er kartlagt, representative meldinger består DMARC, og rapportene ikke viser uforklarte feil fra legitime tjenester. Følg deretter rapporter og leveringsmeldinger gjennom virksomhetens vanlige utsendelsesmønster. Microsofts råd om gradvis utrulling beskriver overgangen fra p=none via p=quarantine til p=reject, med kontroll mellom trinnene for å unngå at legitim e-post blir avvist.

Gå til p=reject når også perioden med karantene viser at de legitime avsenderne fungerer, inkludert sjeldnere utsendelser og aktuelle underdomener. Endre p-verdien i den eksisterende posten og behold rapportadressen. Hvis en legitim strøm rammes, undersøk først hvilken SPF- eller DKIM-identitet den faktisk bruker; sett policyen tilbake til forrige nivå mens feilen rettes.

Ikke regn med at taggen pct begrenser leveringsrisikoen ved en prosentvis utrulling. DMARC-standarden RFC 9989 fjernet pct etter at praktisk bruk viste varierende håndtering hos mottakerne. Avsenderkartet, beståtte testmeldinger og rapporter fra en representativ utsendelsesperiode gir et bedre grunnlag for hvert policyskifte.

Les også: