# PTR-post: hur ett värdnamn blir ett företag

> PTR-posten kopplar ett värdnamn till en IP-adress. Så läser du den, känner igen samlingsnamn och kommer från domänen till företaget.

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

Den som vill veta vem en IP-adress tillhör tittar oftast i nätkatalogen, för europeiska adresser alltså i RIPE:s databas. Det finns en andra väg som ofta förbises: den omvända uppslagningen i DNS. Då frågar du inte "Vem tillhör nätet?" utan "Vad heter datorn bakom den här adressen?". Står ett företags domän i namnet har du en användbar ledtråd.

Den här artikeln förklarar vad en PTR-post (PTR-record) är, vem som sätter den, hur du skiljer användbara poster från värdelösa och var metoden når sina gränser. Vägen via nätkatalogen beskriver [Reverse IP lookup enkelt förklarat](https://whovisit.app/blog/reverse-ip-lookup-erklaert).

## Vad en PTR-post är

DNS känner två riktningar. Normalt frågar du efter ett namn och får en adress (A- eller AAAA-post). PTR-posten (engelska *pointer record*) är motriktningen: Till en adress levererar den ett namn.

Tekniskt vänds adressen för detta och förses med en specialändelse. Av `203.0.113.25` blir frågan `25.113.0.203.in-addr.arpa`. Vid IPv6 heter ändelsen `ip6.arpa`. Adressen vänds då tecken för tecken. Svaret är ett värdnamn, till exempel `mail.beispiel-firma.example`.

Viktigt: En PTR-post är frivillig. Det finns adresser utan post. Posten behöver inte stämma överens med den framåtriktade posten. Den är en ledtråd, inget bevis.

## Vem som sätter den

PTR-posten sköts av den som förvaltar adressblocket:

- **Leverantörer** sätter för sina kundanslutningar oftast automatiskt skapade samlingsnamn.
- **Företag med eget adressblock** sköter posterna själva och anger ofta sin egen domän.
- **Affärsanslutningar** får hos vissa leverantörer på begäran en post med kundens domän. Det sker framför allt för e-postservrar, eftersom många mottagare avvisar e-post från adresser utan passande värdnamn.

Av detta följer: En post med egen domän är ett tecken på att någon medvetet har tagit hand om adressen. Ett automatiskt skapat namn säger bara något om leverantören.

## Känna igen mönster: samlingsnamn eller egen domän

Värdnamnet består av två delar: framdelen (`mail`, `pool-1-2-3-4`) och den registrerbara domänen i slutet (`beispiel-firma.example`). Domänen avslöjar operatören, framdelen avslöjar om namnet gavs för hand eller automatiskt.

Typiska tecken på ett **samlingsnamn** som inte avslöjar något företag:

- delar av adressen står i namnet: `203-0-113-25.provider.example` eller `25.113.0.203.provider.example`
- ord som `dyn`, `dynamic`, `dial`, `pool`, `dsl`, `adsl`, `cable`, `cust`, `customer`, `mobile`, `lte`, `static`, `nat`, `cgn`, `client`
- en domän som uppenbart tillhör en leverantör, en hostingfirma eller ett datacenter

Typiska tecken på ett **användbart namn**:

- en talande framdel som `mail`, `gw`, `fw`, `vpn`, `proxy` eller `smtp`
- inga adressdelar i namnet
- en domän som uppenbart hör till ett företag och inte till leverantören

| Värdnamn (påhittat exempel) | Bedömning |
|---|---|
| `dyn-203-0-113-25.dsl.provider.example` | Leverantörens samlingsnamn, inget uttalande om anslutningens innehavare |
| `pool-25.cust.provider.example` | Samlingsnamn, kundanslutning |
| `mail.beispiel-firma.example` | Egen domän, kandidat för en företagskoppling |
| `vpn.beispiel-firma.example` | Egen domän, kandidat för en företagskoppling |
| `ec2-203-0-113-25.compute.cloud.example` | Datacenter, en kund hos hostingfirman, inte hostingfirman själv |

Tabellen visar också en fälla: Kommer domänen från leverantören eller hostingfirman hjälper namnet dig inte, även om det ser snyggt ut. En användbar utvärdering behöver därför en lista över kända domäner hos leverantörer och hostingfirmor som utesluts.

## Från domänen till företaget

En domän är ännu inget företag. Den vanliga vägen till företaget går via webbplatsen bakom domänen:

1. Bestäm den registrerbara domänen. Av `mail.beispiel-firma.example` blir `beispiel-firma.example`. Vid ändelser som `co.uk` räknas tre delar.
2. Öppna impressumet. I Tyskland, Österrike och Schweiz måste affärsmässiga webbplatser ange operatören, oftast med bolagsform (GmbH, AG, KG och så vidare).
3. Läs ut det juridiska namnet och kontrollera att det hör till en juridisk person och inte till en privatperson.

Textsökningen har gränser. Impressum är inte enhetligt uppbyggda, vissa sidor laddar innehåll först via skript. Ibland står en byrå eller en moderkoncern i impressumet. En automatisk koppling förblir därför ett förslag som en människa vid tvivel kontrollerar. Alternativt ger företagsdatabaser till en domän företagsnamnet, men inte heller det är någonsin fullständigt.

## Pröva själv

Du behöver ingen specialprogramvara. Under macOS och Linux finns `dig`, under Windows `nslookup`. Exemplen använder `203.0.113.25`, en adress ur området för dokumentation (RFC 5737). Den tillhör ingen och har därför ingen verklig post. Sätt för egna försök in adressen till din egen anslutning eller server.

```bash
# Omvänd uppslagning, bara svaret
dig -x 203.0.113.25 +short

# Utförligt, med den vända frågan
dig -x 203.0.113.25

# Windows, macOS och Linux
nslookup 203.0.113.25
```

Så läser du utdata:

- Vid `+short` står i svaret bara värdnamnet, till exempel `mail.beispiel-firma.example.` (punkten i slutet är avsiktlig). Kommer inget tillbaka finns ingen post.
- Utan `+short` visar dig i avsnittet `QUESTION` den vända frågan med `in-addr.arpa`. I avsnittet `ANSWER` står raden med `PTR` och namnet.
- Statusen `NXDOMAIN` betyder: För den här adressen finns ingen post. `SERVFAIL` eller en tidsöverskridning betyder: Den ansvariga namnservern svarar inte.
- `nslookup` visar `name =` följt av värdnamnet, eller meddelandet att namnet inte hittades.

Som motprov frågar du efter namnet framåt (`dig beispiel-firma.example +short`). Pekar namnet åter på samma adress är posten mer trovärdig. Stämmer inte fram- och återriktning överens är försiktighet på sin plats.

## Metodens gränser

- **Föråldrade poster.** Adresser byter ägare, poster blir stående. Ett namn som var rätt för år sedan kan idag leda till ett annat företag eller till inget alls.
- **Tjänsteleverantörers e-postservrar.** Många företag skickar e-post via en hostingfirma eller ett marknadsföringsverktyg. Värdnamnet pekar då på tjänsteleverantören, inte på företaget.
- **Gemensamt använda adresser.** Bakom en adress med företagsnamn kan flera hyresgäster i en kontorsbyggnad eller ett coworking-space sitta. Namnet tillhör då hyresvärden.
- **Tidsgränser.** DNS-frågor kan hänga sig. Den som utvärderar dem i bakgrunden måste ge upp efter kort tid och får inte tvinga fram svaret.
- **Hemarbete och mobilnät.** Här finns nästan alltid bara samlingsnamn. Varför det är så står i [Hemarbete, VPN och mobilnät: vilka du inte ser](https://whovisit.app/blog/homeoffice-vpn-mobilfunk-besuchererkennung).

Hur PTR, nätkatalog och utvärdering tillsammans ger en besöksigenkänning visar översikten [Hur fungerar företagsigenkänning? Tekniken i 6 steg](https://whovisit.app/blog/firmenerkennung-website-technik). Där står också varför träffarna varierar kraftigt beroende på målgrupp.

Ett exempel från praktiken: Whovisit använder den omvända uppslagningen bara för adresser ur leverantörsnät, kastar samlingsnamn och kända leverantörsdomäner, väntar högst två sekunder på svaret och minns bara kopplingen från domän till företag, aldrig IP-adressen. Vilka besökarklasser som finns och vad de betyder står i hjälpen under [Besökarklasser: företag, internetleverantör, datacenter](https://whovisit.app/hilfe/besucherklassen-verstehen).

## Kort sammanfattat

En PTR-post är en frivillig ledtråd till värdnamnet bakom en adress. Värdefull blir den när namnet innehåller en egen företagsdomän och inte visar leverantörsmönster. Från domänen till företaget leder i regel impressumet. Varje koppling förblir en gissning med felkvot. Ingen post är bättre än en felaktig.