Defaults.Exposed › Rettelser › Reverse DNS (PTR)

Sådan retter du Reverse DNS (PTR)

Reverse DNS er ID-kortet for den server, der sender din virksomheds e-mail. Når en modtagende udbyder som Gmail eller Microsoft 365 slår op hvem der er bag afsenderadressen og får et navn, der holder stik, ser din post legitim ud. Mangler kortet — eller stemmer navn og nummer ikke overens — behandles dine ellers ægte fakturaer og tilbud som mistænkelige og junkes stille og roligt eller afvises.

Det korte svar for din virksomhed: Dine fakturaer, tilbud og kundersvar ender lydløst i spam eller ankommer slet ikke — så aftaler staller, betalinger ankommer sent, og kunder tror, du ignorerede dem, uden at noget af det viser sig som en fejl, du ville bemærke.

Hvad dette kan koste dig

Du sender et tilbud til en varm prospect, det ryger i spam, og de går med den konkurrent, der 'faktisk svarede' — og du vidste aldrig, at e-mailen ikke landede.
Fakturaer til kunder forsvinder i junk, betalinger ankommer uger for sent, og dit cashflow tager skraldet, fordi ingen nogensinde så e-mailen.
En kunde klager over, at du aldrig svarede dem — men det gjorde du; deres mailudbyder smed stille og roligt dit svar ud, fordi din afsendende server ikke kunne bevise hvem den var.
Dit domæne klarer sig igennem en ny klients sikkerhedscheck på alt andet, men flagges fordi din mailserver ingen ordentlig identitet har — en lille ting, der får dig til at fremstå sjusket.
Du skiftede til en billig VPS eller en ny app til at sende nyhedsbreve og fakturaer, og natten over dykker din leveringsrate — fordi den nye afsendende server ingen reverse-DNS-badge har, og de store udbydere ikke længere stoler på den.

Hvorfor det betyder noget. Enhver stor e-mailudbyder tjekker identiteten på den server der sender din post, og de tjekker det på enhver besked. Kan den server ikke bevise hvem den er — eller hvis dens navn og nummer modsiger hinanden — behandles din ægte virksomhedspost som om den måske er spam. Du mister svar, betalinger og tillid, og fordi intet bouncer, finder du som regel aldrig ud af hvorfor.

Den korte version

Når din virksomhed sender en e-mail, afsender den fra en mailserver, og enhver server på internettet har en numerisk adresse — dens IP. Reverse DNS (en “PTR-record”) er den servers navne-badge: den lader alle der ser nummeret, slå det ordentlige navn bag det op, som mail.dinvirksomhed.com.

De store modtagende udbydere — Gmail, Microsoft 365, Yahoo — tjekker den badge på enhver besked du sender. En server der kan navngive sig selv, og hvor navn og nummer stemmer overens med hinanden, ser ud som en legitim mailserver. En server uden badge, eller med en badge der ikke matcher, ser præcis ud som de anonyme, engangs-maskiner, spammere bruger. Så dine ægte fakturaer og tilbud starter enhver samtale under mistanke — og mange af dem taber.

Den frustrerende del er, at intet siger dig, at det sker. Ingen bounce, ingen fejl. Din e-mail underperformer bare stille og roligt.

Hvad dette kan koste dig

Her er de hverdagslige måder, en manglende eller mismatching reverse-DNS-record omsættes til penge og tillid der forsvinder.

Tilbuddet der aldrig landede. Du e-mailer et detaljeret tilbud til en prospect, der bad om det den morgen. Deres udbyder kan ikke verificere din afsendende server, så den dropper beskeden i spam. De graver ikke igennem junk. Om eftermiddagen har de taget konkurrentens tilbud — det der “faktisk dukkede op.” Du tilskriver det en langsom lead; i virkeligheden blev din e-mail aldrig set.
Fakturaen i tomrummet. Du fakturerer en god kunde. Den lander i spam. Tredive dage senere jagter du en betaling, der er forfalden uden deres skyld — og nu er der en akavet samtale, et anstrengt forhold og et cashflow-hul, der var fuldstændig undgåeligt.
“Du svarede aldrig.” En kunde er irriteret over, at du ignorerede deres spørgsmål. Det gjorde du ikke — du svarede samme dag. Deres mailudbyder smed stille dit svar ud, fordi din afsendende server så upålidelig ud. Du fremstår uprofessionel for noget du faktisk gjorde rigtigt.
Den gør-det-selv afsendende server der forgiftede alt lydløst. For at spare penge begyndte din post (eller blot dine nyhedsbreve og automatiske fakturaer) at gå ud via en billig VPS eller en ny sendende app. Den server fik aldrig et reverse-DNS-badge. Natten over sank din leveringsrate bredt — og fordi der ingen fejlmeddelelse er, tog det måneder blot at mistænke årsagen.
Sikkerhedscheck-flaget. En større klients IT-team kører en rutinetjek af dit domæne under onboarding. Alt andet er fint, men din mailserver har ingen ordentlig identitet. Det er et mindre teknisk punkt, men det læses som sjuskethed — og nu fikser du det under deadlinepres, eller forklarer dig, når en konkurrents domæne bare sejlede igennem.

Tråden igennem alt dette: omkostningen lander på dig, den er usynlig mens den sker, og fikset er gratis.

Hvad det faktisk er

Normal DNS forvandler et navn til et nummer: du skriver dinvirksomhed.com, og DNS giver IP-adressen at forbinde til. Reverse DNS gør det omvendte — det forvandler et nummer til et navn. Givet IP’en 203.0.113.10 svarer et reverse-opslag (en “PTR-record”) mail.dinvirksomhed.com.

Hvorfor modtagere bekymrer sig: når din mailserver forbinder til Gmail for at levere en besked, ser Gmail den forbindende IP. Det første en seriøs mailfilter gør, er at spørge “hvem er denne maskine?” — ved at lave et reverse-opslag på den IP. En rigtig virksomheds mailserver har et svar (mail.dinvirksomhed.com). En engangs spammaskine har som regel ikke, eller har et generisk udbyder-tildelt navn som host-203-0-113-10.someudbyder.net. Så tilstedeværelsen og kvaliteten af badgen er et af de allerførste tillidssignaler, der anvendes på din post — inden SPF, DKIM eller beskedindhold overhovedet får et kig.

Det tjekker mailserveren, ikke din hjemmeside. Dette forvirrer folk. Din hjemmesides adresse er ofte bag et CDN eller proxy (som Cloudflare) og vil aldrig have en matchende badge — og det er fint, fordi reverse DNS for e-mail handler om den MX-mailservers IP, en fuldstændig separat maskine.

Den halvdel, de fleste opsætninger tager fejl af: det skal matche begge veje. At have et navn er ikke nok. Gmail og de andre store filtre gør noget strengere, kaldet forward-confirmed reverse DNS (FCrDNS):

Slå IP’en op → få et navn (f.eks. mail.dinvirksomhed.com).
Slå nu det navn op igen → det skal pege tilbage til den samme IP du startede fra.

Stemmer de to retninger overens, er serveren bekræftet og fuldt betroet. Er der et navn, men det peger et andet sted hen (eller ingen steder), er serveren kun halvt betroet.

Sådan scores det:

Forward-confirmed (FCrDNS): IP’en navngiver en host, og den host peger tilbage på den samme IP. Fulde point — dette er korrekt konfiguration, og det er det modtagere stoler på.
Badge eksisterer men bekræfter ikke: der er en PTR-record, men navnet peger ikke tilbage på mailserverens IP. Delvist point kun.
Ingen badge overhovedet: ingen PTR-record på mailserverens IP. Ingen point, og leveringsomkostningen er reel.

Sådan fikser du det (gratis, ~10 minutter af nogens tid)

Overrækk dette afsnit til den der ejer IP-adressen for din mailserver — som regel din e-mail- eller hostingudbyder, eller dit datacenter for en self-hosted boks — og bemærk, at fikset er gratis. Dette er den ene e-mail-indstilling, du næsten helt sikkert ikke selv kan ændre i dit normale DNS-panel, fordi reverse DNS kontrolleres af den der ejer IP’en, ikke af den der ejer domænet.

Trin 1 — Find afsendende mailservers IP. Identificer domænets primære MX-host og opløs den til dens IP-adresse:

dig MX dinvirksomhed.com        # find den primære (laveste-prioritet) MX-host
dig A mail.dinvirksomhed.com    # opløs den host til dens IP

Den IP er den der har brug for badgen.

Trin 2 — Bed IP-ejeren om at sætte PTR-recorden.

Google Workspace / Gmail: administreres automatisk for Googles egne mailservere.
Microsoft 365: ligeledes administreres automatisk.
En self-hosted eller VPS mailserver: åbn en support-ticket med din hosting-udbyder eller dit datacenter og bed dem om at sætte PTR (reverse DNS) for din IP til dit mail-hostnavn. De fleste udbydere eksponerer dette i deres kontrolpanel under “Reverse DNS,” “rDNS” eller “PTR.”
En tredjeparts sendende app (nyhedsbrev/faktura/CRM): hvis den sender fra sin egne delte servere, håndterer udbyderen reverse DNS — der er intet for dig at sætte. Sender den fra en dedikeret IP du har købt fra dem, bed dem om at sætte PTR’en på den.

Trin 3 — Gør det forward-confirmed (dette er det trin, de fleste glemmer). Hostnavnet i PTR’en skal også pege tilbage til den samme IP via en normal A-record du kontrollerer i dit eget DNS:

PTR’en siger 203.0.113.10 → mail.dinvirksomhed.com (din udbyder sætter dette).
A-recorden siger mail.dinvirksomhed.com → 203.0.113.10 (du sætter dette i dit DNS, f.eks. Cloudflare → DNS → tilføj en A-record, Navn mail, indhold 203.0.113.10).

Begge retninger skal pege på hinanden. Kun da er det forward-confirmed og fuldt betroet.

Trin 4 — Tjek dit domæne igen. Bekræft, at mailserveren nu viser forward-confirmed reverse DNS, og at tjekket består.

Almindelige fejl

At sætte badgen på hjemmesidens IP i stedet for mailserverens. Reverse DNS for e-mail handler om MX-serveren. At sætte en PTR på din web/CDN-adresse gør intet for leveringsevnen.
At stoppe ved “PTR eksisterer.” Et navn alene giver kun delvis tillid. Gør det ikke-matchende navn ikke det reverse op, stoler de strenge filtre (Gmail, M365, Yahoo) ikke fuldt på det. Fuldfør altid forward-bekræftelsen (Trin 3).
At glemme A-recorden efter at udbyderen sætter PTR’en. Udbyderen sætter den reverse halvdel; du skal sætte den forward halvdel i dit eget DNS. Folk gør den ene og antager, at de er færdige.
At bede den forkerte part. At sende anmodningen til dit domæneregistrar eller DNS-host i stedet for IP-ejeren giver dig “vi kan ikke gøre det” — fordi de virkelig ikke kan. Det skal gå til den der ejer IP’en.
Generiske udbyder-hostnavne. En PTR som host-203-0-113-10.someudbyder.net eksisterer teknisk set, men gør intet for dit brand eller din tillid. Brug et rigtigt hostnavn på dit eget domæne, der forward-confirmer.

Hvor dette passer ind

Reverse DNS er serverens identitet; SPF, DKIM og DMARC er domænets autoriserings- og anti-efterligningslag. De besvarer forskellige spørgsmål, og de store udbydere tjekker dem alle. SPF lister hvilke tjenester der må sende som dig; DKIM signerer kryptografisk dine beskeder; DMARC binder de to sammen og fortæller modtagere hvad de skal gøre med post der fejler. Reverse DNS sidder under alt det og borger for, at den maskine der sender, er en rigtig, navngiven mailserver. Enhver af disse rettelser er gratis.

FAQ

Jeg er ikke teknisk — kan jeg selv klare det?

Som regel ikke, og det er fint. I modsætning til de fleste e-mail-indstillinger ændres denne ikke i dit eget domænes DNS — den sættes af den der ejer internetadressen (IP'en) for din mailserver, altså din e-mail- eller hostingudbyder. Dit job er simpelthen at sende dem afsnittet 'Sådan fikser du det'. Det er en hurtig ændring fra deres side, og det er gratis.

Hvis jeg bruger Google Workspace eller Microsoft 365, er jeg allerede dækket?

Næsten helt sikkert ja — begge administrerer reverse DNS automatisk for deres egne mailservere, så et domæne der kun sender via dem, klarer dette uden du gør noget. Flagger vores tjek det stadig, betyder det næsten altid, at noget af din post sendes via en anden server (din egen boks, en billig VPS eller en tredjepartsapp), og det er den server der mangler sin badge. Fix-afsnittet forklarer, hvem du skal kontakte.

Kan det at fikse dette bryde min e-mail?

Nej. Dette tilføjer eller korrigerer kun afsendende servers identitetsrecord — det ændrer ikke, hvor din post sendes, hvem der har tilladelse til at sende den, eller nogen af dine indbakke-indstillinger. Det gør blot den e-mail du allerede sender mere sandsynlig for at blive betroet og leveret.

Hvad er forskellen på dette og SPF, DKIM og DMARC?

De tre besvarer 'har dette domæne tilladelse til at sende denne besked?' Reverse DNS besvarer et andet, tidligere spørgsmål: 'er den maskine der sender, en rigtig, identificerbar mailserver, eller en anonym boks?' Store udbydere tjekker begge. Du ønsker dem alle rigtigt — men reverse DNS er den der fanger en ny eller self-hosted afsendende server, inden SPF og DKIM overhovedet kommer i spil.

Vi har en reverse-DNS-record, men tjekket klarer sig stadig ikke fuldt ud — hvorfor?

Fordi at have et navn ikke er nok; navnet skal gå op i begge retninger. Badgen siger, at serveren hedder mail.dinvirksomhed.com — men Gmail slår derefter det navn op og forventer, at det peger direkte tilbage på den præcise samme IP. Gør det ikke (eller peger et andet sted hen), behandler udbyderne det som ubekræftet. Denne tovejs-match kaldes forward-confirmed reverse DNS, og det er den del de fleste opsætninger mangler.

Er fikset virkelig gratis, eller er dette et betalt mersalg?

Fikset er altid gratis — det er en lille konfigurationsændring foretaget af din udbyder, ikke et produkt du køber. Vi opkræver kun betaling for at overvåge, at det forbliver korrekt over tid, aldrig for at foretage ændringen.