DMARC-post forklart – navn, tagger og validering

En DMARC-post er en TXT-post som knytter domenet i e-postens synlige Fra-felt til autentiseringsresultatene fra SPF og DKIM. Posten kan be om rapporter og uttrykke hvordan mottakeren bør vurdere meldinger som ikke består.

I mai 2026 erstattet RFC 9989 den gamle RFC 7489. Mange generatorer og blogginnlegg viser fortsatt historiske tagger. Denne guiden bruker den gjeldende standarden og skiller mellom gyldig syntaks og trygg policyinnføring.

Hvor DMARC-posten skal ligge

For e-post med synlig Fra-adresse kari@dittfirma.no begynner mottakeren med et TXT-oppslag på:

_dmarc.dittfirma.no

I et DNS-panel kan navnefeltet være _dmarc, fordi panelet legger til sonen automatisk. Andre paneler forventer hele navnet. Kontroller det publiserte resultatet, ikke bare det som står i skjemaet.

En vanlig kontroll er:

dig _dmarc.dittfirma.no TXT +short

DMARC-verdien skal ikke ligge på rotdomenet, www eller et DKIM-selector-navn. En TXT-tekst som begynner med v=DMARC1 på feil navn blir ikke brukt som policy for Fra-domenet.

Det skal finnes høyst én DMARC-policy på hvert oppslagsnavn. Hvis et oppslag gir flere poster som starter med DMARC-versjonen, blir de forkastet. En ny policy skal derfor erstatte den gamle verdien, ikke publiseres ved siden av den.

Trenger du hjelp til å tolke navn, verdier og anførselstegn før du setter en policy, les grunnlaget for TXT-poster .

En minimal overvåkingspost

Et mulig startpunkt er:

v=DMARC1; p=none; rua=mailto:dmarc-rapporter@dittfirma.no

Bytt ut domenet og bruk en rapportadresse som faktisk finnes og behandles maskinelt. Verdien betyr:

• v=DMARC1 identifiserer DMARC og må stå først
• p=none uttrykker ingen ønsket særbehandling ved DMARC-feil
• rua= ber deltagende mottakere sende aggregerte rapporter til adressen

p=none er observasjon, ikke håndheving. Det stanser ikke domeneforfalskning på egen hånd, og det garanterer heller ikke at en melding leveres. Mottakere vurderer fortsatt omdømme, innhold og andre sikkerhetssignaler.

Før posten publiseres bør dere ha aktiv SPF og DKIM, et avsenderregister og en mottaker for rapportene. Den operative planen fra kartlegging til DMARC-håndheving dekker rekkefølgen.

Aktive DMARC-tagger i RFC 9989

Vanlige bedrifter skal normalt ikke sette psd=y. Taggen finnes for operatører av offentlige suffiksdomener og for avgrensing i DMARCs DNS tree walk. Ikke kopier den fra en avansert generator uten å forstå organisasjonsgrensen den erklærer.

p angir domeneeierens vurdering

Dette er et signal til mottakeren. quarantine betyr ikke at alle mottakere bruker samme søppelpostmappe, og reject tvinger ikke alle systemer til identisk SMTP-oppførsel. Gjeldende standard krever at mottakere bruker mer analyse enn DMARC-policyen alene ved avvisning.

Gå ikke direkte til p=reject fordi en nettbasert generator foreslår det. Før håndheving må alle legitime avsendere – inkludert faktura, CRM, nyhetsbrev, skjemaer, supportsystem og sjeldne varsler – bestå gjennom alignet SPF eller DKIM.

rua gir aggregerte rapporter

rua angir hvor mottakere kan sende maskinlesbare, aggregerte rapporter. De inneholder summerte autentiseringsresultater og volum, ikke en full kopi av hver melding.

Flere adresser skilles med komma:

v=DMARC1; p=none; rua=mailto:dmarc@dittfirma.no,mailto:arkiv@rapporter.example

Ikke legg til en ekstern adresse uten avtale og godkjenning. Når rapportmottakeren tilhører et annet organisasjonsdomene, krever RFC 9990 normalt en bekreftende DNS-post hos mottakerdomenet. Uten den kan avsendere av rapporter ignorere adressen.

Rapportene er komprimerte XML-data og bør maskinbehandles. En ubemannet postkasse som fylles opp er ikke rapportoppfølging. Se guiden til DMARC-rapporter, ekstern godkjenning og sikker XML-behandling .

ruf og fo krever en personvernvurdering

ruf ber om meldingsspesifikke feilrapporter. Slike rapporter kan inneholde mer informasjon om den opprinnelige meldingen enn aggregerte rapporter, og mange mottakere sender dem ikke av personvernhensyn.

fo påvirker bare ønsket om feilrapporter når ruf også er satt. Det endrer ikke om en melding består DMARC. Før ruf tas i bruk bør dere avklare:

• hvem som har tilgang til rapportene
• hvilke personopplysninger eller forretningsdata som kan forekomme
• lagringstid og sletting
• behandlingsgrunnlag og leverandøravtaler
• hvordan skadelige eller falske rapporter håndteres

For mange små bedrifter gir rua den viktigste oversikten med lavere datarisiko.

adkim og aspf styrer alignment

DMARC består når minst én autentisert identitet både får pass og er alignet med domenet i synlig Fra-felt.

Med standardverdien r, avslappet alignment, kan identitetene dele samme organisasjonsdomene. Med s, streng alignment, må domenene være identiske.

Anta synlig Fra-domene dittfirma.no:

Ikke sett adkim=s og aspf=s som en refleks. Streng alignment kan være riktig for en kontrollert arkitektur, men kan også bryte legitime underdomener. Test hver avsenderstrøm i meldingshodet før standardverdiene endres.

sp og np styrer underdomener

En policy på organisasjonsdomenet kan også gjelde underdomener.

• sp uttrykker policy for eksisterende underdomener når den overordnede posten anvendes.
• np uttrykker policy for underdomener som ikke finnes i DNS.
• Hvis de mangler, arves verdien gjennom reglene i standarden.

Et mulig håndhevingsoppsett etter full kartlegging er:

v=DMARC1; p=reject; sp=reject; np=reject; rua=mailto:dmarc-rapporter@dittfirma.no

Dette er et eksempel, ikke en startverdi. Underdomener kan brukes av markedsføring, faktura, kundesystemer eller leverandører. En streng sp eller np skal først publiseres når DNS-navn, Fra-domener og autentisering er kartlagt.

En egen DMARC-post direkte på news.dittfirma.no bruker sin egen p for dette Fra-domenet. sp i en post på underdomenet styrer ikke søsken som faktura.dittfirma.no.

t erstatter ikke kontrollert utrulling

RFC 9989 introduserte t=y som testmodus. Ved en policy som quarantine ber testmodus om behandling ett nivå lavere, altså som none; ved reject ber den om behandling som quarantine. Taggen påvirker ikke rapportgenerering.

Dette er nytt i 2026. Eldre DMARC-implementasjoner kan ignorere en ukjent t-tagg og anvende p som skrevet. Stol derfor ikke på t=y som eneste vern mot feil i et ellers strengt policybytte.

Den mest forutsigbare utrullingen er fortsatt:

1. p=none med fungerende rapportering
2. retting av alle legitime avsendere
3. avgrenset og målt p=quarantine
4. p=reject først etter representativ drift og definert tilbakeføring

Ikke bruk pct, ri eller rf i nye poster

pct, ri og rf er historiske i RFC 9989.

• pct ble brukt til prosentvis policyanvendelse, men ble inkonsistent implementert.
• ri ba tidligere om et rapportintervall.
• rf anga rapportformat.

En gammel parser kan fortsatt vise dem, men nye policyer skal bygges med aktive tagger. Fjern dem som del av en kontrollert endring; ikke kombiner oppryddingen med en utestet overgang til strengere p.

Slik validerer dere posten

Kontroller DNS

1. Finn aktive autoritative navnetjenere.
2. Spør hver av dem etter TXT på nøyaktig _dmarc.<fra-domene>.
3. Kontroller at bare én DMARC-policy returneres.
4. Bekreft at v=DMARC1 står først og har riktig store og små bokstaver.
5. Parse verdien med et verktøy som kjenner RFC 9989.
6. Kontroller ekstern rapportgodkjenning dersom rua peker utenfor domenet.

Et eksempel på direkte autoritativ kontroll:

dig dittfirma.no NS +short
dig @ns1.dnsleverandor.example _dmarc.dittfirma.no TXT +short

Bytt ut eksempelnavnene. En kontroll i DNS-panelet beviser ikke hva Internett får som svar.

Kontroller en ekte melding

DNS-posten kan være syntaktisk riktig mens legitime meldinger fortsatt feiler alignment. Send fra hver avsenderstrøm til en ekstern mottaker og åpne originalmeldingen. Kontroller i mottakerens betrodde Authentication-Results:

• hvilket synlig Fra-domene DMARC vurderte
• om DMARC ga pass eller fail
• SPF-resultatet og SPF-domenet
• DKIM-resultatet og header.d
• hvilken mekanisme som ga alignment

Test personpost, faktura, nettskjema, nyhetsbrev og andre systemer separat.

Feil som gjør posten svak eller ugyldig

Velg riktig neste guide

For samspillet mellom mekanismene, les SPF, DKIM og DMARC forklart . For DNS-syntaksen til de underliggende metodene, bruk SPF-post forklart og DKIM-post forklart .

Har dere en DMARC-feil, kan dere sende domenenavnet, den offentlige TXT-verdien og et anonymisert autentiseringsresultat via kundeservice . Ikke send passord, private DKIM-nøkler eller innhold fra kundemeldinger.