Stramme inn DMARC fra kartlegging til reject

DMARC-håndheving skal redusere uautorisert bruk av domenet uten å avvise virksomhetens egne fakturaer, skjemaer, kundemeldinger eller nyhetsbrev. Det krever mer enn å bytte p=none til p=reject etter en kalender.

Den gjeldende DMARC-standarden er RFC 9989 , publisert i mai 2026. Den erstatter RFC 7489. Blant endringene er at pct nå er historisk og ikke skal brukes som utrullingsmekanisme.

Hva policyverdiene egentlig ber om

Mottakeren tar den endelige avgjørelsen etter egen lokal policy. quarantine garanterer ikke en bestemt spammappe, og reject er ikke et løfte om at alle mottakere avviser på samme SMTP-steg. En mottaker kan også stoppe en melding som består DMARC av andre grunner.

DMARC består med justert DKIM eller SPF

Meldingen består når minst én av disse er sann:

• DKIM-signaturen består, og d= er justert mot domenet i synlig Fra-felt
• SPF består for konvoluttavsenderen, og dette domenet er justert mot synlig Fra-felt

Det holder ikke at SPF eller DKIM viser pass for et helt annet leverandørdomene. Kontroller alltid justeringen.

Praktisk bør kritiske avsenderstrømmer få justert DKIM selv om SPF også virker. Videresending bryter ofte SPF, mens DKIM kan overleve dersom innholdet ikke endres. E-postlister og gatewayer kan likevel endre meldingen og bryte DKIM.

Nytt i RFC 9989

t=y ber en mottaker bruke ett nivå mildere policy under test: reject blir behandlet som quarantine, og quarantine som none. Men eldre mottakere som følger den forrige standarden kjenner ikke t og kan ignorere taggen mens de håndhever p. Bruk derfor ikke t=y som eneste sikkerhetsnett i en overgangsperiode.

Den robuste utrullingen bruker separate domener eller underdomener, kriteriebaserte faser og en testet tilbakeføringsplan.

Fase 0 – bygg avsenderkartet

Før den første DMARC-posten bygges og valideres , skal virksomheten vite hvem som sender:

Bruk kontrakter, DNS, leverandøroversikt, meldingshoder og DMARC-rapporter. En liste over IP-adresser alene er ikke et avsenderkart; skyløsninger endrer infrastruktur, og samme IP kan brukes av mange kunder.

Fase 1 – rapportering med p=none

Et enkelt utgangspunkt kan være:

_dmarc.example.no TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.no"

Bytt domene og rapportadresse. Adressen må finnes, være overvåket og kunne håndtere komprimerte XML-rapporter. Hvis rapportene går til et annet domene, trengs ekstern godkjenning i mottakerdomenets DNS etter RFC 9990.

Kontroller DNS-posten

• det finnes bare én gyldig DMARC-post på navnet
• v=DMARC1 står først
• posten ligger på _dmarc.<domene>
• rapportadressen er korrekt og godkjent
• autoritative navnetjenere gir samme svar
• parseren viser ingen permanent syntaksfeil

p=none betyr ikke at meldinger garantert leveres. Det betyr at domeneeieren ikke ber om særbehandling basert på DMARC-feilen.

Bli i fase 1 til dataene er representative

Ikke bruk «to til fire uker» som universell regel. Observasjonen må dekke:

• vanlig brukerpost
• månedlig eller kvartalsvis fakturering
• markedsføringsutsendelser
• support, skjema og varsling
• ferie, lønn eller sesongstrømmer som er relevante
• alle regioner eller leverandørnoder
• videresending og lister som virksomheten faktisk bruker

En årlig utsendelse kan testes kontrollert uten å vente et helt år, men den skal ikke glemmes.

Klassifiser hver rapportert kilde

Ikke legg en ukjent IP i SPF bare for å få grønn rapport. Finn tjenesten, eieren og avtalen først.

Fase 2 – håndhev på et avgrenset underdomene

Den mest målbare piloten er et domene med én kjent strøm, for eksempel news.example.no eller billing.example.no. Publiser en egen DMARC-post på dette underdomenet med p=quarantine eller p=reject etter risiko.

Eksempel:

_dmarc.news.example.no TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.no"

En DMARC-post direkte på et underdomene bruker sin egen p. sp i denne posten styrer ikke søsken eller organisasjonsdomenet.

Før piloten:

• Fra-domene er dedikert til den kjente strømmen
• SPF og DKIM er justert og testet
• alle maler og ruter er testet eksternt
• eier og support kjenner feilbildet
• DNS-verdien for tilbakeføring er klargjort
• gammel TTL er forstått

Fase 3 – p=quarantine på organisasjonsdomenet

Når avsenderkartet er komplett og underdomenepiloten er stabil:

_dmarc.example.no TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.no"

Følg både rapporter og driftssignaler:

• avvisnings- og forsinkelseslogger hos avsender
• supportsaker fra mottakere
• faktura, reset, ordre og skjema som ikke kommer frem
• volumendring per avsendertjeneste
• DMARC-feil per synlig Fra-domene
• endringer i DKIM-selector og SPF-domene

Gå ikke videre fordi «ingen klaget». Mange leveringsfeil blir aldri rapportert til avsenderen som en menneskelig klage.

Fase 4 – p=reject

Et mulig sluttpunkt er:

_dmarc.example.no TXT "v=DMARC1; p=reject; sp=reject; np=reject; rua=mailto:dmarc@example.no"

Bruk sp og np bare etter at underdomener er kartlagt. Hvis legitime systemer sender fra underdomener, må de ha egen korrekt autentisering eller en bevisst annen policy.

Når håndhevingen er stabil og domenet har et godt avsenderomdømme, kan BIMI vurderes som et eget merkevareprosjekt . BIMI er ikke en grunn til å skynde seg til reject; autentisering og leveringssikkerhet må være løst først.

Kriterier før reject

• alle legitime avsenderstrømmer har eier
• kritiske strømmer består justert DKIM eller har dokumentert robust alternativ
• representativt volum viser ingen uforklarte legitime feil
• nye leverandører må gjennom en fast e-postautentiseringsprosess
• rapporter og leveringslogger overvåkes etter endringen
• support og økonomi vet hvem de kontakter
• tilbakeføring er testet og kan godkjennes raskt
• domene-, DNS- og e-postadministratorer er sikret

Bruk et feilbudsjett

«99 prosent pass» kan skjule at den ene prosenten er alle fakturaene. Vekt feil etter forretningskonsekvens, ikke bare volum.

Tilbakeføring uten panikkendringer

Hvis legitim post blir påvirket:

1. Identifiser synlig Fra-domene, system, DKIM d=, selector og SPF-domene.
2. Stans eller omdiriger den berørte utsendelsen hvis mulig.
3. Rett eget DKIM-domene, returdomene eller Fra-domene hos riktig leverandør.
4. Bruk en dokumentert mildere p midlertidig hvis omfanget krever det.
5. Bekreft DNS på autoritative navnetjenere.
6. Test en ufarlig melding gjennom samme rute.
7. Følg rapporter, leveringslogger og support etter rettingen.
8. Dokumenter rotårsak og endre onboardingprosessen.

DNS-cache betyr at tilbakeføringen ikke virker øyeblikkelig overalt. Ikke endre SPF, DKIM, DMARC og MX samtidig uten en isolert hypotese.

Vanlige feil

• bruke historiske pct som om de gir sikker prosentutrulling
• stole på t=y som om alle eldre mottakere forstår taggen
• kreve at både SPF og DKIM består når DMARC trenger én justert metode
• se dkim=pass uten å kontrollere header.d
• gjøre SPF større for hver ukjent IP
• glemme skjema, faktura, support og underdomener
• anta at rapporter dekker alle mottakere
• bruke sp=reject uten å kartlegge aktive underdomener
• sende aggregerte rapporter til en ubeskyttet delt postboks
• gå til reject uten leveringslogger og returplan

Endringslogg som kan kopieres

DMARC hos Vymo

Vymos publiserte e-postplaner lover ikke et administrert DMARC-rapportsystem, avsenderkartlegging eller en automatisk overgang til reject. Ikke publiser en streng policy før alle tjenester som bruker kundens domene er kartlagt.

Be om de faktiske e-post- og DNS-forutsetningene hvis domenet bruker Vymo. Oppgi domene, avsendertjenester, rapportløsning og hvem som styrer DNS. Ikke send private nøkler, passord eller rå meldingsinnhold i kontaktskjemaet.

Bruk guiden for DKIM-oppsett og guiden til DMARC-rapporter som arbeidsgrunnlag.