Kontrol af DKIM-post

Indsæt en DKIM TXT-post for at inspicere dens version, nøgletype, offentlige nøgle, tjenester og citerede DNS-bidder.

DKIM rekord
Indsæt en tagliste såsomv=DKIM1;k=rsa;p=…. Citerede TXT-bidder og zone-filparenteser accepteres og tilsluttes.

DKIM analyse

Indsæt en DKIM-post, og tjek den derefter.

Optag noter

    version
    Nøgletype
    Nøglestørrelse
    Tjenester

    Parserede felter

    TagVærdi
    Indsæt en DKIM-post for at inspicere den.

    Din DKIM-registrering forbliver i din browser.BroBroGo uploader eller gemmer det ikke.

    FAQ

    Hvorfor opdeles lange DKIM-poster i citerede strenge?

    En DNS TXT-post kan indeholde flere tegnstrenge, hvor hver streng er begrænset til255bytes.DNS forbinder strengene i rækkefølge, så alle chunks skal forblive inde i én TXT-record.

    Hvilke DKIM-nøgletyper genkender denne kontrol?

    Den genkender RSA og Ed25519 offentlige nøgler, kontrollerer deres Base64 form og rapporterer RSA nøgler under1024bits som ugyldige og nøgler under2048bits som svagere end anbefalet.

    Beviser et rent resultat, at DKIM virker?

    Nej. Denne side kontrollerer kun den posttekst, du indsætter. Den forespørger ikke DNS, verificerer ikke en meddelelsessignatur, bekræfter vælgernavnet eller beviser, at postmodtagere kan hente posten.

    DKIM-postens rolle i e-mailautentificering

    DomainKeys Identified Mail (DKIM) er en standardiseret metode til e-mailautentificering, der gør det muligt for en organisation at påtage sig ansvaret for afsendelsen af en meddelelse. Dette sker ved at tilføje en digital signatur til e-mailens header, som modtagende mailservere kan verificere. Autentificeringen beskytter mod e-mail-spoofing og sikrer, at meddelelsens indhold ikke er blevet ændret under transporten.

    Selve fundamentet for denne proces er en DKIM TXT-post, som domæneadministratoren udgiver i sit domænes DNS-indstillinger. Når en modtagende server modtager en e-mail, henter den denne TXT-post for at få fat i den offentlige nøgle, som er nødvendig for at verificere signaturen. Hvis konfigurationen af denne post indeholder syntaksfejl, forældede algoritmer eller for svage nøgler, kan modtagende servere ikke validere e-mails, hvilket ofte fører til, at legitime beskeder afvises eller lander i spammappen.

    Opbygning og komponenter af en DKIM TXT-post

    En DKIM-post består af en række tags adskilt af semikolon, hvor hvert tag definerer en specifik egenskab for nøglen og de tilladte tjenester. En typisk post kan se således ud: v=DKIM1; k=rsa; p=….

    De vigtigste komponenter i posten omfatter:

    • Version (v): Angiver den anvendte DKIM-version. Hvis dette tag er til stede, skal det være det første tag i posten, og værdien skal være nøjagtigt DKIM1.
    • Nøgletype (k): Definerer den kryptografiske algoritme, der er anvendt til nøgleparret. Værktøjet understøtter og genkender her rsa og ed25519.
    • Offentlig nøgle (p): Indeholder den Base64-kodede offentlige nøgle. Hvis dette felt efterlades tomt, signalerer det en tilbagekaldt nøgle.
    • Tjenester (s): Angiver, hvilke tjenester posten gælder for, hvor den tilladte værdi skal indeholde email eller *.
    • Hash-algoritmer (h): Angiver de tilladte hash-algoritmer, hvor det kræves, at konfigurationen tillader sha256.

    Kryptografiske nøgler og sikkerhedskrav

    Valget af nøgletype og nøglestørrelse har direkte indflydelse på sikkerheden af dine e-mailsignaturer. Værktøjet analyserer de kryptografiske egenskaber i den indsatte post baseret på følgende regler:

    Nøgletype Størrelseskrav og anbefalinger Status og validering
    RSA Under 1024 bits Rapporteres som ugyldig (DKIM kræver mindst 1024 bits)
    RSA Mellem 1024 og 2047 bits Rapporteres som svagere end anbefalet (2048 bits eller mere anbefales)
    Ed25519 Præcis 32 bytes efter afkodning Godkendes som gyldig (fejler hvis den afkoder til et andet antal bytes)

    Derudover er valget af hash-algoritme kritisk. Tidligere var sha1 udbredt, men denne algoritme betragtes nu som forældet til DKIM-signaturer og må ikke bruges, da den ikke længere yder tilstrækkelig beskyttelse mod kollisionsangreb. Moderne konfigurationer skal understøtte sha256.

    DNS-begrænsninger og håndtering af TXT-bidder

    En af de mest almindelige tekniske udfordringer ved implementering af DKIM er begrænsningen på længden af strenge i DNS. En DNS TXT-post kan indeholde flere tegnstrenge, men hver enkelt streng (chunk) er begrænset til maksimalt 255 bytes.

    Når en offentlig nøgle – især en 2048-bit RSA-nøgle – skal publiceres, vil den samlede strenglængde ofte overskride denne grænse. Administratoren er derfor nødt til at opdele posten i flere citerede bidder i zonefilen. Værktøjet accepterer disse citerede TXT-bidder og zone-filparenteser, hvorefter det samler dem til analyse. Det kontrollerer i den forbindelse, om de enkelte rå bidder overholder grænsen på 255 bytes, og om formateringen af de citerede strenge er korrekt.

    Lokale kontroller versus aktive DNS-forespørgsler

    Det er vigtigt at forstå grænserne for denne analyse. Værktøjet udfører en lokal post-tekstkontrol direkte i din browser. Det betyder, at processen adskiller sig væsentligt fra en fuld leveringskontrol på følgende punkter:

    • Ingen DNS-forespørgsler: Værktøjet slår ikke dit domænenavn eller din DKIM-selector op i det globale DNS-system. Den analyserer udelukkende den tekst, du indsætter i feltet.
    • Ingen signaturverificering: Værktøjet modtager eller analyserer ikke faktiske e-mails og kan derfor ikke bekræfte, om din mailserver signerer meddelelser korrekt.
    • Lokal databehandling: Din DKIM-registrering forbliver i din browser. BroBroGo uploader eller gemmer det ikke, hvilket sikrer, at følsomme konfigurationsdata ikke forlader din maskine under analysen.

    Almindelige fejl og advarsler i DKIM-poster

    Når du indsætter en post på op til 20.000 tegn i feltet under "DKIM TXT værdi", analyserer værktøjet syntaksen og returnerer specifikke fejlmeddelelser og advarsler, hvis konfigurationen afviger fra standarderne:

    • Manglende eller fejlplacerede tags: Hvis v=DKIM1 er til stede, men ikke står først, udløses fejlen: "v=DKIM1-mærket skal være det første mærke, når det er til stede.". Hvis den offentlige nøgle mangler helt, vises: "Det påkrævede p public-key tag mangler.".
    • Syntaksfejl: Hvis et tag mangler en separator, vil du se fejlen: "Feltet “‹tag›” mangler et lighedstegn.". Hvis et tagnavn indeholder ugyldige tegn, rapporteres: "Tagnavnet “‹tag›” er forkert udformet.".
    • Dublerede tags: Hvert tag må kun optræde én gang. Hvis et tag gentages, vises advarslen: "‹tag›-tagget vises mere end én gang.".
    • Ugyldige værdier: Hvis du angiver en ukendt algoritme, vises: "Nøgletypen “‹detail›” er ikke understøttet. Brugrsaellered25519.". Hvis tjenestefeltet indeholder fejl, vises: "s-værdien “‹detail›” indeholder en ikke-understøttet tjeneste. Brug e-mail eller *.".

    Ofte stillede spørgsmål

    Hvorfor opdeles lange DKIM-poster i citerede strenge?

    En DNS TXT-post kan indeholde flere tegnstrenge, hvor hver streng er begrænset til 255 bytes. DNS forbinder strengene i rækkefølge, så alle chunks skal forblive inde i én TXT-record.

    Hvilke DKIM-nøgletyper genkender denne kontrol?

    Den genkender RSA og Ed25519 offentlige nøgler, kontrollerer deres Base64 form og rapporterer RSA nøgler under 1024 bits som ugyldige og nøgler under 2048 bits som svagere end anbefalet.

    Beviser et rent resultat, at DKIM virker?

    Nej. Denne side kontrollerer kun den posttekst, du indsætter. Den forespørger ikke DNS, verificerer ikke en meddelelsessignatur, bekræfter vælgernavnet eller beviser, at postmodtagere kan hente posten.

    Hvad sker der, hvis p-tagget er tomt i min post?

    Hvis p-værdien er tom, tolkes det som en bevidst handling, der udgiver en tilbagekaldt DKIM-nøgle. Dette bruges af administratorer til permanent at deaktivere en specifik nøgle, så modtagende servere ikke længere accepterer signaturer genereret med den tilhørende private nøgle.