Kontrol af DMARC-post

Forståelse af DMARC-poster og deres opbygning

En DMARC-post (Domain-based Message Authentication, Reporting, and Conformance) er en DNS TXT-post, som domæneadministratorer bruger til at beskytte deres e-mail-domæner mod misbrug og phishing. Posten fungerer som en instruktion til modtagende mailservere om, hvordan de skal håndtere e-mails, der fejler godkendelsen via SPF (Sender Policy Framework) og DKIM (DomainKeys Identified Mail).

For at en modtagende mailserver kan tolke instruktionerne korrekt, skal DMARC-posten være struktureret nøjagtigt efter gældende standarder. En DMARC-post består af en række termer (tags) adskilt af semikolon, hvor hver term angiver en specifik indstilling eller politik. Værktøjet Kontrol af DMARC-post analyserer disse termer direkte i din browser for at verificere syntaksen, politikvalg og rapporteringsopsætningen.

---

DMARC-politikker og deres indvirkning (p, sp, np)

Kernen i enhver DMARC-post er definitionen af politikker, som bestemmer modtagerens håndtering af e-mails, der ikke består godkendelsen. DMARC opererer med tre forskellige niveauer af politikker, som dækker hoveddomænet, underdomæner og ikke-eksisterende underdomæner:

• Hoveddomænets politik (p): Angiver standardpolitikken for domænet. Hvis der ikke er angivet nogen p-term i posten, falder domænepolitikken automatisk tilbage til none. Værktøjet vil i så fald vise noten "p → none". En politik med p=none overvåger udelukkende fejl og anmoder ikke modtagere om at sætte e-mails i karantæne eller afvise dem. Dette udløser noten "p=none".
• Underdomæners politik (sp): Definerer politikken specifikt for underdomæner. Hvis denne udelades, falder politikken tilbage til værdien i p.
• Ikke-eksisterende underdomæners politik (np): Definerer politikken for underdomæner, der ikke eksisterer i DNS. Hvis denne term mangler, falder politikken tilbage i rækkefølgen fra np til sp og til sidst til p.

Under testforløb kan termen t=y (testtilstand) anvendes. Denne indstilling reducerer strengheden af politikkerne under test: en quarantine-politik sænkes til none, og en reject-politik sænkes til quarantine. Værktøjet markerer dette med noten "t=y: reject → quarantine; quarantine → none".

---

Identifikatorjustering og rapporteringsopsætning

DMARC kræver, at afsenderdomænet i e-mailens "From"-hoved stemmer overens (aligner) med de domæner, der er godkendt via SPF og DKIM. Justeringen (alignment) kan konfigureres som enten streng eller afslappet for både SPF (aspf) og DKIM (adkim).

Rapportering er en central del af DMARC, som giver domæneejere indsigt i, hvem der sender mail på deres vegne:

• Aggregerede rapporter (rua): Bruges til at modtage daglige oversigtsrapporter i XML-format. Hvis der ikke er angivet en gyldig rua-adresse, anmodes der ikke om aggregerede rapporter, hvilket udløser noten "rua=∅".
• Fejlrapporter (ruf): Bruges til at modtage detaljerede oplysninger om specifikke e-mails, der fejler godkendelsen.
• Fejlindstillinger (fo): Denne term bestemmer betingelserne for generering af fejlrapporter. Hvis der ikke er angivet en gyldig ruf-adresse til fejlrapporter, ignoreres fo-termen helt, hvilket resulterer i noten "fo → ∅ (ruf=∅)".

Historisk set kunne modtagere begrænse omfanget af DMARC-politikken til en vis procentdel af e-mails ved hjælp af pct-termen. I moderne implementeringer betragtes pct-værdier som historiske og begrænser kun dækningen hos modtagere, der stadig følger ældre specifikationer. Dette markeres med noten "pct=‹detail›% (RFC 7489)". Desuden er !size-suffikset på en rapport-URI forældet og bør ignoreres af moderne modtagere, hvilket udløser noten "!size → ∅ (RFC 9989)".

---

Almindelige syntaksfejl og valideringsregler

For at en DMARC-post kan tolkes korrekt af modtagende mailservere, skal den overholde en række strenge syntaksregler:

1. Krav til startsekvens: Posten skal begynde med den store/små bogstavsfølsomme værdi v=DMARC1. Hvis dette mangler, vises fejlen "Posten skal begynde med v=DMARC1.".
2. Placering af version: Termen v=DMARC1 skal være den absolut første term i posten. Hvis den findes i en anden position, vises fejlen "Term ‹position›: v=DMARC1 skal være den første term.".
3. Unikke termer: En term må ikke optræde flere gange i samme post. Dubletter udløser fejlen "×2: ‹tag› (‹position›)".
4. Korrekt formatering: Termer skal være formateret som navn=værdi-par adskilt af semikolon. Fejlagtigt strukturerede termer udløser "name=value ✕ (‹position›)".
5. Tomme værdier: En term skal indeholde en værdi. Hvis den er tom, vises "‹tag›=∅ (‹position›)".
6. Ugyldige værdier og URI'er: Hvis en term indeholder en værdi, der ikke understøttes, vises "‹tag›=‹detail› ✕ (‹position›)". Hvis en rapporterings-URI i rua eller ruf er ugyldig, vises "URI ✕: ‹tag› (‹position›)".

Værktøjet identificerer også ukendte termer ("Ukendt: ‹tag› (‹position›)") samt historiske termer, der er forældede i den nuværende standard ("RFC 7489 → RFC 9989: ‹tag› (‹position›)"). Hvis du indsætter en post, hvor DNS TXT-dele er omgivet af anførselstegn, vil værktøjet automatisk samle disse dele før analysen og vise noten "DNS TXT-dele i anførselstegn blev samlet før analysen.".

---

Fortolkning af analyseresultaterne

Når du har indtastet en DMARC-post og klikket på Kontrollér DMARC-post, præsenterer værktøjet resultaterne i en struktureret oversigt:

DMARC-oversigt

Dette afsnit opsummerer de vigtigste indstillinger i din post:

• sp: Viser den konfigurerede politik for underdomæner.
• np: Viser den konfigurerede politik for ikke-eksisterende underdomæner.
• DKIM / SPF: Viser indstillingerne for identifikatorjustering.
• rua / ruf: Angiver antallet af specificerede rapportadresser.
• pct (RFC 7489): Viser den eventuelle procentdel, der er angivet for historiske implementeringer.

Analyserede termer

En tabel, der lister hver funden term med følgende kolonner:

• Term: Navnet på DMARC-tagget.
• Værdi eller kvalifikator: Den tilhørende værdi.
• Type: Angiver status for termen, herunder om den følger den nyeste standard (RFC 9989), den ældre standard (RFC 7489), er Ukendt eller direkte ugyldig (✕ DMARC).

---

Sikkerhed og databehandling i browseren

Når du bruger dette værktøj til at kontrollere dine DMARC-poster, sker al databehandling lokalt i din browser. Din DMARC-post bliver i din browser, og værktøjet uploader eller gemmer den ikke. Der sendes ingen anmodninger relateret til din post ud over din egen maskine, og inputtet gemmes ikke i browserens permanente lager.

---

Ofte stillede spørgsmål (FAQ)

Noter om syntaks og politik: p / sp / np?

Hvis en DMARC-post mangler en p-term, falder politikken tilbage til none (p=none). Under testforløb kan t=y reducere politikkens styrke, så reject bliver til quarantine, og quarantine bliver til none. Hvis mere specifikke politik-tags mangler for underdomæner, falder modtagerens fortolkning tilbage i rækkefølgen np (ikke-eksisterende underdomæner) til sp (underdomæner) og til sidst til p (hoveddomænet).

RFC 9989: pct / rf / ri?

I henhold til den opdaterede standard RFC 9989 betragtes termer som pct, rf og ri nu som historiske (RFC 7489), mens termer som np, psd og t er aktive (RFC 9989). Modtagende systemer, der følger den nyeste standard, kan vælge at ignorere de historiske termer.

Beviser et fejlfrit resultat, at min DMARC-opsætning virker?

Nej. Denne side kontrollerer kun den tekst, du indsætter. Den forespørger ikke DNS, udvider ikke udbyderposter, tester ikke en afsender-IP og bekræfter ikke, hvad en modtagende mailserver returnerer. Værktøjet er udelukkende en syntaktisk og strukturel validator af den rå tekststreng, du angiver.

Hvad er grænsen for størrelsen på den DMARC-post, jeg kan indsætte?

Værktøjet understøtter DMARC-poster på op til 20.000 tegn. Hvis du indsætter en post, der overskrider denne grænse, vil du modtage fejlmeddelelsen: "Denne post er usædvanligt stor. Hold den under 20.000 tegn.".