Kontroll av DMARC-oppføring

Forståelsen av DMARC-oppføringer og deres komponenter

En DMARC-oppføring (Domain-based Message Authentication, Reporting, and Conformance) er en TXT-oppføring i domenenavnsystemet (DNS) som hjelper e-postmottakere med å avgjøre hvordan de skal håndtere e-postmeldinger som utgir seg for å sende fra ditt domene. Ved å analysere oppføringen kan en domeneadministrator kontrollere regler for e-postautentisering, justering av identifikatorer og rapporteringsmottakere.

For at en DMARC-oppføring skal være gyldig, må den starte med den nøyaktige, kasusfølsomme verdien v=DMARC1. Denne verdien må alltid være den aller første termen i oppføringen. Hvis denne rekkefølgen ikke overholdes, eller hvis verdien skrives annerledes, vil mottakende e-postservere ignorere hele oppføringen.

Verktøyet Kontroll av DMARC-oppføring analyserer strukturen i en oppføring du limer inn. Den maksimale lengden som støttes for inndata er under 20 000 tegn. Hvis du limer inn DNS TXT-deler i anførselstegn, vil verktøyet automatisk slå disse sammen før analysen utføres.

---

DMARC-policyer og deres innvirkning på domener

Kjernen i DMARC er policy-instruksjonene som forteller mottakeren hva som skal gjøres med e-post som feiler i autentiseringen. Disse defineres gjennom tre spesifikke tagger:

• Hoveddomenepolicy (p): Angir regelen for hoveddomenet. Hvis ingen p-tagg er til stede i oppføringen, vil policyen for domenet falle tilbake til none. En policy med p=none overvåker kun feil, og ber ikke mottakere om å sette meldinger i karantene eller avvise e-post som feiler autentiseringen.
• Underdomenepolicy (sp): Definerer regler spesifikt for underdomener.
• Policy for ikke-eksisterende underdomener (np): Definerer regler for underdomener som ikke eksisterer i DNS.

Når spesifikke tagger mangler i en oppføring, benytter mottakende systemer en definert fallback-rekkefølge for underdomener. Underdomenepolicyen faller tilbake fra np til sp, og til slutt til hovedpolicyen p dersom mer spesifikke tagger er fraværende.

Under testing kan taggen t=y (testmodus) endre hvordan mottakere tolker instruksjonene. Verdien t=y senker strengheten i policyen under testperioden: en quarantine-instruksjon nedgraderes til none, og en reject-instruksjon nedgraderes til quarantine.

---

Identifikatorjustering og rapportering

For at en e-post skal bestå DMARC, må identitetene i SPF (Sender Policy Framework) og DKIM (DomainKeys Identified Mail) stemme overens med domenet i e-postens "Fra"-felt. Dette kalles identifikatorjustering (alignment). DMARC-oppføringen kan spesifisere om denne justeringen skal være streng eller avslappet for henholdsvis SPF (aspf) og DKIM (adkim).

Rapportering er en annen kritisk funksjon i DMARC, som lar domeneadministratorer motta data om e-post som sendes på vegne av deres domene. Det finnes to typer rapporter:

1. Aggregerte rapporter (rua): Sendes som XML-filer og gir statistisk oversikt over sendemønstre og autentiseringsstatus. Hvis ingen gyldig rua-adresse er oppgitt, blir ikke aggregerte rapporter etterspurt av mottakerne.
2. Feilrapporter (ruf): Sendes fortløpende når enkeltmeldinger feiler autentiseringen.

Taggen fo (alternativer for feilrapportering) brukes til å finjustere når feilrapporter skal genereres. Det er verdt å merke seg at fo-taggen ignoreres fullstendig av mottakere dersom det ikke er konfigurert en gyldig ruf-adresse for feilrapporter i oppføringen.

---

Historiske tagger og utdaterte formater

DMARC-standarden har utviklet seg, og enkelte tagger og formater som tidligere var i bruk, regnes nå som historiske eller foreldede. Mottakende systemer som følger den gjeldende standarden kan ignorere disse:

• Prosentverdi (pct): Denne taggen ble brukt til å begrense policydekningen til en viss prosentandel av e-poststrømmen. I dag regnes pct-verdier som historiske, og de begrenser kun policydekningen for mottakere som fortsatt følger eldre DMARC-spesifikasjoner.
• Størrelsesbegrensning på rapporter (!size): Tidligere kunne man legge til et !size-suffiks på en rapport-URI (for eksempel en e-postadresse i rua eller ruf) for å angi maksimal filstørrelse. Dette suffikset er nå foreldet og skal ignoreres av moderne mottakere.

---

Slik tolkes analyseresultatene

Når du kjører en kontroll av en DMARC-oppføring, vil verktøyet dele opp informasjonen i oversiktlige seksjoner for å avdekke eventuelle syntaksfeil eller uhensiktsmessige policyvalg.

DMARC-sammendrag

Denne delen gir en rask oversikt over de viktigste innstillingene i oppføringen:

• p: Den aktive policyen for hoveddomenet.
• sp: Policyen som gjelder for underdomener.
• np: Policyen for ikke-eksisterende underdomener.
• DKIM / SPF: Status for justeringsinnstillingene for SPF og DKIM.
• rua / ruf: Antall unike e-postadresser som er konfigurert for mottak av rapporter.
• pct (RFC 7489): Eventuelle historiske prosentverdier som er oppdaget.

Tolkede termer

Dette er en tabell som lister opp hver enkelt tagg som ble funnet i oppføringen, med følgende kolonner:

• Term: Navnet på DMARC-taggen.
• Verdi eller kvalifikator: Verdien som er tildelt taggen.
• Type: Statusen til taggen, som kan være enten aktiv (RFC 9989), historisk (RFC 7489), ukjent eller ugyldig.

---

Merknader om syntaks og policy

Verktøyet vil flagge spesifikke problemer eller observasjoner knyttet til oppføringens oppbygning. Her er de potensielle feilmeldingene og merknadene som kan vises under analysen:

• Skriv inn en støttet DMARC-oppføring. – Vises hvis inndataene ikke kan tolkes som en DMARC-oppføring.
• Lim inn en DMARC-oppføring først. – Vises hvis du forsøker å kjøre en kontroll uten innhold.
• Denne oppføringen er uvanlig stor. Hold den under 20 000 tegn. – Vises hvis inndataene overskrider lengdegrensen.
• Oppføringen må begynne med v=DMARC1. – Vises hvis den obligatoriske versjonstaggen mangler helt i starten.
• Term ‹position›: v=DMARC1 må være den første termen. – Vises hvis versjonstaggen er plassert lenger ut i strengen.
• ×2: ‹tag› (‹position›) – Vises hvis en tagg er definert mer enn én gang i samme oppføring.
• name=value ✕ (‹position›) – Vises hvis en tagg er feilaktig formatert og ikke følger mønsteret med semikolonseparerte navn/verdi-par.
• ‹tag›=∅ (‹position›) – Vises hvis en tagg er oppgitt, men mangler en tilhørende verdi.
• ‹tag›=‹detail› ✕ (‹position›) – Vises hvis verdien til en spesifikk tagg er ugyldig.
• URI ✕: ‹tag› (‹position›) – Vises hvis en oppgitt rapportadresse i rua eller ruf har ugyldig syntaks.
• Ukjent: ‹tag› (‹position›) – Vises hvis det finnes en tagg som ikke er registrert i DMARC-standarden, noe som gjør at mottakere vil ignorere den.
• RFC 7489 → RFC 9989: ‹tag› (‹position›) – Vises hvis taggen er definert som historisk i den gjeldende standarden.
• p → none – Vises som en merknad om at manglende p-tagg gjør at policyen faller tilbake til none.
• p=none – Informerer om at p=none kun overvåker og ikke ber mottakere om å blokkere eller isolere e-post.
• t=y: reject → quarantine; quarantine → none – Informerer om at testmodus er aktiv og reduserer policyens strenghet.
• rua=∅ – Merknad om at ingen gyldig rua-adresse er oppgitt, slik at aggregerte rapporter ikke vil bli sendt.
• fo → ∅ (ruf=∅) – Merknad om at fo-taggen ignoreres fordi det mangler en gyldig mottakeradresse for feilrapporter.
• pct=‹detail›% (RFC 7489) – Merknad om at prosentverdien er historisk og kun vil påvirke eldre mottakere.
• DNS TXT-deler i anførselstegn ble slått sammen før analysen. – Bekrefter at oppstykket DNS-tekst har blitt satt sammen for kontrollen.
• !size → ∅ (RFC 9989) – Merknad om at størrelsesbegrensningen på rapport-URI-en er foreldet og vil bli ignorert av moderne mottakere.

---

Personvern og databehandling

Når du bruker dette verktøyet, foregår all databehandling lokalt i din egen nettleser. DMARC-oppføringen du limer inn blir verken lastet opp, lagret eller sendt eksternt. Inndataene skrives ikke til nettleserens permanente lagring, og det sendes ingen nettverksforespørsler knyttet til innholdet i oppføringen.

---

Ofte stilte spørsmål (FAQ)

Merknader om syntaks og policy: p / sp / np?

Dersom hovedpolicyen settes til p=none, vil e-postmottakere kun overvåke feil uten å blokkere meldinger. Hvis du bruker testmodus med t=y, vil mottakerne nedgradere en quarantine-policy til none, og en reject-policy til quarantine. Når det gjelder underdomener, vil mottakende systemer lete etter mer spesifikke regler i rekkefølgen np (ikke-eksisterende underdomener), deretter sp (underdomener), og til slutt falle tilbake på hovedpolicyen p dersom de mer spesifikke taggene mangler.

RFC 9989: pct / rf / ri?

Nei. Denne siden kontrollerer bare teksten du limer inn. Den spør ikke DNS, utvider ikke leverandøroppføringer, tester ikke en avsender-IP og bekrefter ikke hva en mottakende e-postserver vil returnere. I henhold til den oppdaterte standarden RFC 9989 regnes tagger som pct, rf og ri som historiske (historic), mens tagger som np, psd og t er definert som aktive (active).

Beviser et feilfritt resultat at DMARC-oppsettet mitt fungerer?

Nei. Denne siden kontrollerer bare teksten du limer inn. Den spør ikke DNS, utvider ikke leverandøroppføringer, tester ikke en avsender-IP og bekrefter ikke hva en mottakende e-postserver vil returnere. Verktøyet verifiserer utelukkende at syntaksen, taggene og de oppgitte policy-verdiene i den innlimte strengen er formelt korrekte og følger gjeldende standarder.