Nej. Tjekket er gratis og kræver ikke login.

Domænet og resultatet indgår i en statistik over danske domæners mailsikkerhed. Din IP-adresse gemmes ikke i klar tekst. Bestiller du rapporten på mail, gemmer vi adressen og resultatet, og IP-adressen fra bestillingen slettes automatisk efter en fast periode. Læs mere i privatlivspolitikken.

Rapporten sendes først, når du har klikket på linket i bekræftelsesmailen. Så kan ingen bestille rapporter til andres adresser.

Ja. Når du bestiller rapporten på mail, kan du vælge overvågning. Så får du en mail, hvis din mailopsætning ændrer sig. Du kan altid afmelde dig med linket i mailen.

Nielco IT kan gennemgå hele din mailopsætning uafhængigt af din leverandør og rette den sammen med dig eller din IT-leverandør.

Hvis der ikke er en SPF record, kan dine e-mails have svært ved at nå frem til modtagerens indbakke. Uden SPF bliver dine e-mails mere tilbøjelige til at blive markeret som spam eller afvist af modtagerens server, så modtageren måske aldrig ser dit nyhedsbrev, din faktura eller anden vigtig mail. Derudover øges risikoen for mail spoofing, hvilket betyder, at kriminelle kan udnytte dit domæne til at sende falske e-mails.

Hvis der er flere SPF records for samme domæne, vil mailservere ignorere dem alle, hvilket resulterer i, at dine e-mails ikke bliver autentificeret korrekt. Dette kan føre til, at dine e-mails bliver markeret som spam eller afvist.

Hvis dine SPF records ikke inkluderer alle de platforme, du bruger til at sende e-mails, vil e-mails sendt fra de udeladte platforme blive afvist eller markeret som spam. Dette kan skade din leveringssikkerhed og reducere tilliden til dine e-mails.

SPF records tillader maksimalt 10 DNS opslag. Hvis din SPF record overskrider denne grænse, vil den blive betragtet som ugyldig. Dette kan resultere i, at dine e-mails ikke bliver autentificeret korrekt, hvilket fører til leveringsproblemer og øget risiko for spoofing.

Uden DKIM bliver dine e-mails ikke signeret, og modtagerens server kan ikke kontrollere, at de faktisk kommer fra dit domæne og ikke er ændret undervejs. DMARC skal så klare sig alene med SPF, hvilket ofte går galt, når e-mails bliver videresendt. Sender du mere end 5.000 e-mails om dagen til Gmail- eller Outlook-adresser, kræver begge udbydere både SPF og DKIM.

DKIM-nøgler ligger under et navn, en såkaldt selector, som hver mailplatform selv vælger. Det er ikke muligt at slå alle selectorer for et domæne op i DNS, så tjekket prøver de mest almindelige. Finder tjekket ingen, kan din platform godt bruge en anden selector. Se derfor i opsætningen hos din mailplatform, hvilken selector den bruger, før du konkluderer, at DKIM mangler.

Nej. DNS viser kun, at der er offentliggjort en nøgle. Om din mailplatform rent faktisk signerer dine e-mails, kan du se ved at sende en e-mail til en Gmail-adresse og vælge “Vis original”. Her fremgår det, om DKIM er godkendt, og med hvilket domæne.

En selector er det navn, DKIM-nøglen ligger under i DNS, fx selector1._domainkey.ditdomæne.dk. Selectoren gør det muligt at have flere nøgler på samme domæne, typisk én for hver platform, der sender e-mails for dig. Microsoft 365 bruger fx selector1 og selector2, mens Google Workspace som standard bruger google. Modtagerens server læser selectoren i e-mailens signatur og slår den tilsvarende nøgle op.

Flere DKIM records under forskellige selectors er helt normalt og ikke en fejl, i modsætning til SPF og DMARC. Ligger der derimod to forskellige records under samme selector, kan modtagerens server vælge en vilkårlig af dem. Resultatet bliver uforudsigeligt, og nogle af dine e-mails kan fejle godkendelsen.

En DKIM-nøgle på 2048 bit er længere end de 255 tegn, én tekststreng i en DNS-record må indeholde. Nøglen skal derfor deles op i flere strenge i samme record. Gøres det forkert, eller bliver nøglen afkortet, fejler godkendelsen, selvom recorden ser ud til at være på plads.

En tom nøgle betyder, at nøglen er tilbagekaldt. Alle e-mails, der er signeret med den selector, fejler godkendelsen. Det er korrekt, når en platform er taget ud af brug, men en fejl, hvis platformen stadig sender e-mails for dig.

Testtilstand fortæller modtagerne, at DKIM stadig er under opsætning. Ifølge DKIM-standarden må modtagerens server ikke behandle e-mailen anderledes end en usigneret e-mail, heller ikke hvis signaturen fejler. Når opsætningen virker, bør testflaget fjernes.

Mange platforme, bl.a. Microsoft 365, beder dig oprette DKIM som en CNAME, der peger på en nøgle hos platformen. Peger CNAME’en på noget, der ikke findes, kan modtageren ikke finde nøglen, og godkendelsen fejler. Er aftalen med platformen ophørt, bør CNAME’en slettes, så den ikke står og peger på en tjeneste, du ikke længere kontrollerer.

DKIM-standarden (RFC 8301) kræver nøgler på mindst 1024 bit og anbefaler mindst 2048 bit. Signaturer med kortere nøgler bliver ikke godkendt. Bruger du stadig en 1024-bit nøgle, virker den, men den bør udskiftes med en 2048-bit nøgle ved næste nøgleskift.

Jo længere den samme nøgle er i brug, jo større er risikoen for, at den private del er kommet i forkerte hænder, fx via gamle servere, backups eller tidligere medarbejdere. Skift derfor nøglen med jævne mellemrum: Opret en ny selector, skift signeringen over til den, og fjern først den gamle nøgle, når e-mails signeret med den er nået frem.

Den, der har nøglen, kan signere e-mails, som modtagerne godkender som ægte e-mails fra dit domæne. Opret straks en ny nøgle under en ny selector, flyt signeringen over på den, og tilbagekald den gamle ved at tømme nøglen (p=) i den gamle record.

Gamle records gør ingen gavn, men de øger antallet af nøgler, der kan misbruges, hvis en tidligere leverandør bliver kompromitteret. Slet dem, eller tilbagekald nøglen, når platformen er taget ud af brug.

DKIM understøtter også Ed25519-nøgler (RFC 8463), som er langt kortere end RSA-nøgler. Ikke alle modtagere kan endnu kontrollere dem, så de bør kun bruges sammen med en almindelig RSA-signatur på samme e-mail.

Hver platform, der sender e-mails i dit domænes navn, skal have sin egen DKIM-opsætning. Det gælder mailserver, nyhedsbrevssystem, webshop, CRM- og fakturasystem. E-mails fra platforme uden DKIM skal klare sig med SPF alene og kan ende i spam eller blive afvist, hvis SPF heller ikke er på plads.

Mange platforme signerer som standard med deres eget domæne. Signaturen er gyldig, men domænet i signaturen matcher ikke dit afsenderdomæne. DMARC kræver, at domænerne matcher, så signaturen tæller ikke med i din DMARC-godkendelse. Løsningen er at opsætte DKIM med dit eget domæne i platformen.

Den nye platform skal have DKIM opsat og verificeret, før den begynder at sende e-mails for dig. Ellers risikerer du, at e-mails fejler i overgangen. Når den gamle platform er lukket, bør dens DKIM-records fjernes.

Sender du fra fx nyhedsbrev.ditdomæne.dk, skal signaturen enten bruge subdomænet eller dit hoveddomæne. Med DMARC-standardindstillingen (adkim=r) godkendes begge. Er DMARC sat til streng kontrol (adkim=s), skal domænet i signaturen matche afsenderdomænet præcist.

Tilføjer en mailingliste en tekst i bunden, ændrer emnelinjen eller omskriver links, bryder det DKIM-signaturen, og e-mailen kan fejle hos modtageren. Google anbefaler, at videresendere og mailinglister bruger ARC (RFC 8617), som videregiver resultatet af den oprindelige godkendelse til den endelige modtager. ARC håndteres af mellemleddet, ikke af dig som afsender.

Ved DKIM replay sender en angriber en e-mail, der er gyldigt signeret af dit domæne, igen til et stort antal modtagere. Signaturen er stadig gyldig, så e-mailen bliver godkendt. Giv signaturerne en kort udløbstid (x=), hvis din platform giver mulighed for det, og hold øje med dine DMARC-rapporter for uventet store mængder e-mails.

Nej. DKIM bruges kun til at signere e-mails, der bliver sendt. Et domæne, der ikke sender e-mails, beskyttes bedst med en SPF record, der afviser alle afsendere (v=spf1 -all), og en DMARC record med p=reject.

Uden en DMARC record er dit domæne mere sårbart over for phishing og spoofing-angreb. En DMARC record hjælper med at sikre, at dine e-mails bliver autentificeret korrekt og giver dig mulighed for at specificere, hvordan modtagerens server skal håndtere ikke-godkendte e-mails.

Hvis der er flere DMARC records for samme domæne, vil mailservere ikke kunne validere dine e-mails korrekt, hvilket øger risikoen for mail spoofing og kan føre til dårlig leveringssikkerhed.

adkim styrer, hvor præcist domænet i DKIM-signaturen skal matche afsenderdomænet. Med r (relaxed), som er standard, er det nok, at hoveddomænet er det samme. Med s (strict) skal domænerne være helt identiske, så en signatur med ditdomæne.dk ikke godkendes for e-mails fra nyhedsbrev.ditdomæne.dk.

Selvom en korrekt SPF record hjælper med at forbedre leveringssikkerheden, vil manglen på en DMARC record betyde, at du stadig er udsat for mail spoofing. DMARC giver et yderligere lag af sikkerhed ved at specificere, hvordan ikke-godkendte e-mails skal håndteres.

En utilstrækkelig SPF record betyder, at nogle af dine e-mails ikke vil blive godkendt korrekt, hvilket kan resultere i, at de bliver markeret som spam eller afvist. Uden en DMARC record er dine e-mails og dit domæne fortsat udsat for spoofing og phishing-angreb.

En utilstrækkelig SPF record og en fejlbehæftet DMARC record vil tilsammen resultere i dårlig e-mail leveringssikkerhed og høj risiko for mail spoofing. Ikke-godkendte e-mails kan let ende i spam-mapper, og dit domæne kan blive udnyttet til phishing-angreb.

Selvom dine e-mails vil blive godkendt gennem SPF, vil en fejlbehæftet DMARC record betyde, at modtagerens servere ikke ved, hvordan de skal håndtere ikke-godkendte e-mails. Dette kan resultere i øget risiko for mail spoofing og reduceret leveringssikkerhed.

Uden en SPF record vil dine e-mails ikke blive godkendt korrekt, selvom der er en DMARC record. En politik på “none” betyder, at ingen handling tages på ikke-godkendte e-mails, hvilket betyder, at der stadig er høj risiko for spoofing og lav leveringssikkerhed.

Uden en SPF record vil dine e-mails ikke blive godkendt korrekt. En DMARC politik på “quarantine” vil føre til, at ikke-godkendte e-mails lander i spam-mappen. Dette kan reducere leveringssikkerheden betydeligt.

Uden en SPF record vil dine e-mails ikke blive godkendt korrekt. En DMARC politik på “reject” vil føre til, at ikke-godkendte e-mails bliver afvist. Dette vil kraftigt påvirke leveringssikkerheden, da ingen af dine e-mails vil nå modtageren.

En utilstrækkelig SPF record betyder, at nogle af dine e-mails ikke bliver godkendt korrekt. Med en DMARC politik på “none” tages der ingen handling på ikke-godkendte e-mails, hvilket efterlader dig sårbar over for spoofing.

En utilstrækkelig SPF record betyder, at nogle af dine e-mails ikke bliver godkendt korrekt. Med en DMARC politik på “quarantine” vil disse e-mails blive sendt til spam-mappen, hvilket reducerer leveringssikkerheden.

En utilstrækkelig SPF record betyder, at nogle af dine e-mails ikke bliver godkendt korrekt. Med en DMARC politik på “reject” vil disse e-mails blive afvist, hvilket kraftigt påvirker leveringssikkerheden.

En korrekt SPF record hjælper med at godkende dine e-mails, men med en DMARC politik på “none” tages der ingen handling på ikke-godkendte e-mails. Dette betyder, at der stadig er en vis risiko for spoofing.

En korrekt SPF record hjælper med at godkende dine e-mails, og med en DMARC politik på “quarantine” vil ikke-godkendte e-mails blive sendt til spam-mappen. Dette reducerer risikoen for spoofing og forbedrer leveringssikkerheden.

En korrekt SPF record hjælper med at godkende dine e-mails, og med en DMARC politik på “reject” vil ikke-godkendte e-mails blive afvist. Dette giver den bedste beskyttelse mod spoofing og sikrer høj leveringssikkerhed.

DMARC godkender en e-mail, hvis enten SPF eller DKIM er i orden og matcher dit domæne. En korrekt DKIM-signatur med dit eget domæne er derfor nok til, at DMARC godkender e-mailen, sådan som bl.a. Mailchimp arbejder. Gmail og Outlook kræver dog både SPF og DKIM af afsendere med mere end 5.000 e-mails om dagen, så en SPF record anbefales fortsat.

Dine e-mails er signeret, og det hjælper leveringen. Men uden DMARC har modtagerens server ingen instruks om, hvad den skal gøre med e-mails, der udgiver sig for at komme fra dit domæne uden en gyldig signatur. Dit domæne er derfor stadig udsat for spoofing.

E-mails, der sendes direkte til modtageren, bliver godkendt via SPF. Bliver en e-mail videresendt, fejler SPF typisk, og uden DKIM er der intet at falde tilbage på. Med p=reject kan videresendte e-mails derfor blive afvist.

DMARC godkender e-mailen, fordi det er nok, at én af de to metoder er i orden og matcher dit domæne. Fejlen i DKIM bør alligevel rettes, da e-mailen ellers står uden beskyttelse, hvis SPF også fejler, fx ved videresendelse.

E-mailen bliver ikke godkendt. Med en DMARC politik på “quarantine” lander den i spam-mappen, og med “reject” bliver den afvist. Rammer det dine egne e-mails, tyder det på en fejl i opsætningen hos en af dine platforme.

Ved videresendelse kommer e-mailen fra en anden server end din, så SPF fejler typisk. DKIM-signaturen følger med selve e-mailen og forbliver gyldig, så længe indholdet ikke ændres. Derfor er DKIM ofte det, der sikrer, at videresendte e-mails bliver godkendt.