# Kontrollera reverse DNS: fråga efter och skapa en PTR-post

> Så kontrollerar du reverse DNS-posten för en IP-adress med dig, host och nslookup, låter leverantören sätta den och uppfyller e-postservrarnas regler.

Quelle: https://whovisit.app/sv/blog/reverse-dns-kontrollera-ptr-post
Veröffentlicht: 2026-11-07
Herausgeber: Whovisit (ARAVILO, Innsbruck)

Den som driver en e-postserver stöter förr eller senare på felmeddelandet "no reverse DNS" eller "PTR missing". Det som avses är reverse DNS-posten för din serveradress. Den här artikeln visar hur du frågar efter den, vad den måste klara för e-postservrar och hur du låter skapa den. Hur du drar slutsatsen från ett värdnamn till ett företag står däremot i [PTR-post: hur ett värdnamn blir ett företag](https://whovisit.app/blog/ptr-rueckwaertssuche-firma).

## Vad reverse DNS är

Normal DNS översätter ett namn till en adress. Reverse DNS gör motsatsen: Till en IP-adress levererar den ett namn. För det finns PTR-posten. Frågan går via en specialdomän. Vid IPv4 är det `in-addr.arpa`, vid IPv6 `ip6.arpa`. Adressen vänds då. Av `192.0.2.10` blir `10.2.0.192.in-addr.arpa`. Vid IPv6 vänds de enskilda hexadecimala siffrorna, som [RFC 3596](https://www.rfc-editor.org/rfc/rfc3596) beskriver.

## Fråga efter PTR-posten

Alla kommandon frågar i exemplet efter `193.0.6.139`, RIPE NCC:s adress. Ersätt den med din egen.

| Verktyg | Kommando | Bra att veta |
|---|---|---|
| dig (macOS, Linux) | `dig -x 193.0.6.139 +short` | Vänder själv på adressen. Utan `+short` ser du också statusen. |
| host (macOS, Linux) | `host 193.0.6.139` | Kortaste utdata: "domain name pointer …" |
| nslookup (alla system) | `nslookup 193.0.6.139` | Finns också under Windows. |

Kommer inget svar finns ingen post (status `NXDOMAIN`) eller så svarar den ansvariga namnservern inte (`SERVFAIL`, tidsöverskridning). För IPv6 fungerar samma skrivsätt, till exempel `dig -x 2001:db8::25 +short` med en adress ur dokumentationsområdet. Den som inte har en konsol använder en onlinefråga på en webbplats med DNS-verktyg. Nyligen ändrade poster kommer på grund av mellanlagringen (TTL) ofta först efter en tid fram överallt.

## Varför e-postservrar behöver den

Mottagande e-postservrar kontrollerar gärna om avsändaren är korrekt uppsatt. En del av den kontrollen är reverse DNS. Grundtanken heter på fackspråk *forward-confirmed reverse DNS*:

1. För avsändaradressen frågas PTR-posten. Resultat: ett värdnamn.
2. För det värdnamnet frågas A-posten (vid IPv6 AAAA).
3. Stämmer adressen överens med den ursprungliga är kedjan sluten.

Google kräver uttryckligen giltiga fram- och återposter för avsändare. I [riktlinjerna för avsändare](https://support.google.com/a/answer/81126) står att avsändaradressen måste stämma överens med adressen för det värdnamn som anges i PTR-posten. Även [RFC 1912](https://www.rfc-editor.org/rfc/rfc1912) rekommenderar i avsnitt 2.1 att PTR- och A-poster passar ihop och att PTR-posten inte pekar på en CNAME. Om en annan mottagare kontrollerar strikt står i dennes egen dokumentation. Räkna med att en saknad eller omatchande post leder till avvisade e-postmeddelanden eller sådana som hamnar i skräpposten.

## Låta skapa den

PTR-posten sätter du inte i din egen domänhantering. Den ligger i den zon som hör till adressblocket. Den förvaltas av den som blocket är tilldelat. Oftast är det din leverantör eller hostingfirma.

1. Välj det värdnamn som din e-postserver ska uppträda under, till exempel `mail.beispiel-firma.example`.
2. Skapa i din egen DNS-zon A-posten: `mail.beispiel-firma.example` pekar på `192.0.2.10`.
3. Ange i leverantörens kundportal reverse DNS-posten för `192.0.2.10`. Hos många hostingfirmor är det ett fält vid IP-adressen. Annars räcker en förfrågan till supporten med adress och önskat namn.
4. Kontrollera med `dig -x` och därefter med `dig mail.beispiel-firma.example +short` att båda riktningarna passar ihop.
5. Se till att namnet också passar till hälsningen (HELO/EHLO) från din e-postserver.

Har du ett eget adressblock vidarebefordrar registret zonen till dina namnservrar. För block som är mindre än ett /24 beskriver [RFC 2317](https://www.rfc-editor.org/rfc/rfc2317) förfarandet. Fråga i så fall först din leverantör.

Två snubbelstenar är vanliga. Har servern flera adresser behöver var och en sin egen post. Och med dynamiska adresser, som privata anslutningar har, får du i regel inget fritt valt namn. Den som skickar e-post därifrån använder bättre en relätjänst.

## När kontrollen misslyckas

| Iakttagelse | Möjlig orsak |
|---|---|
| Ingen post | Leverantören har inte satt något, posten saknas för den här adressen |
| Posten pekar på leverantörens samlingsnamn | Eget namn har aldrig begärts |
| Namnet löses inte till samma adress | A-posten saknas eller pekar på en gammal adress |
| Bara IPv4 fungerar | För IPv6 saknas posten, Google påpekar det i sin dokumentation |
| Ändringen syns inte | Mellanlager, vänta eller fråga leverantörens namnserver direkt |

Reverse DNS ersätter ingen e-postautentisering. SPF, DKIM och DMARC är egna ämnen. Men utan passande PTR-post hamnar en e-postserver snabbt under mottagarnas radar.

## Vad reverse DNS inte bevisar

Posten är frivillig och sköts av nätoperatören. Den säger inte vem som använder en adress. Därför duger den som ledtråd, inte som bevis, när du vill veta [vem en IP-adress tillhör](https://whovisit.app/blog/ip-adresse-inhaber-herausfinden). För det är nätregistret den pålitligare källan. Samspelet mellan båda vägarna förklarar [Reverse IP lookup enkelt förklarat](https://whovisit.app/blog/reverse-ip-lookup-erklaert).

## Vanliga frågor

**Måste varje IP-adress ha en PTR-post?** Nej, den är frivillig. För servrar som skickar e-post är den i praktiken ändå obligatorisk, eftersom mottagare kontrollerar den.

**Kan jag ändra PTR-posten själv?** Bara om du förvaltar adressens reverse-zon. För adresser från din leverantör eller hostingfirma sätter den posten, oftast via kundportalen eller på begäran.

**Vad är skillnaden mellan reverse DNS och Whois?** Reverse DNS levererar ett värdnamn och sätts av nätoperatören. Whois eller RDAP anger innehavaren av adressområdet. Båda är olika databaser med olika syfte.