Reverse DNS og PTR for e-postservere

Reverse DNS svarer på spørsmålet «hvilket vertsnavn er knyttet til denne IP-adressen?». For en server som leverer e-post direkte til mottakere, er svaret en del av den tekniske identiteten mottakersystemet vurderer.

Men de fleste bedrifter sender gjennom infrastrukturen til en e-postleverandør. Da er det leverandøren – ikke kunden som bruker domenet – som må ha kontroll på PTR for sende-IP-ene.

Når trenger du å undersøke PTR?

Slik sender du	Hvem har normalt ansvaret?	Hva du bør gjøre
E-postapp via administrert e-postleverandør	E-postleverandøren	Ikke opprett PTR selv; meld fra ved dokumentert leveringsfeil
Nyhetsbrev eller transaksjonell e-post via plattform	Utsendelsesplattformen	Kontroller leverandørens oppsett og autentiser ditt avsenderdomene
Egen server leverer direkte til mottakerens MX	Virksomheten og IP-leverandøren	Sett PTR, fremoveroppslag, EHLO og øvrig avsenderoppsett før sending
Egen app sender via et SMTP-relé	Reléleverandøren for ekstern sende-IP	Konfigurer appens relé og domeneautentisering; ikke appserverens private IP
Kontorlinje eller dynamisk bredbånds-IP	Internettleverandøren kontrollerer reverse DNS	Bruk normalt et godkjent SMTP-relé fremfor direkte levering

Det er den offentlige IP-en som faktisk kobler seg til mottakerserveren som er relevant. IP-en til PC-en, webserveren eller den lokale ruteren er ikke nødvendigvis sende-IP-en.

Hva er en PTR-post?

PTR er DNS-posttypen som peker fra et navn i reverse DNS til et vertsnavn. IPv4 bruker sonen in-addr.arpa, mens IPv6 bruker ip6.arpa.

For IPv4-adressen 203.0.113.42 blir navnet:

42.113.0.203.in-addr.arpa.

En post kan prinsipielt se slik ut:

42.113.0.203.in-addr.arpa. PTR mail.example.no.

IP-adressen står i omvendt rekkefølge fordi DNS-hierarkiet da kan delegeres etter IP-blokker. For IPv6 snus hvert heksadesimale siffer i den fullt utvidede adressen og legges under ip6.arpa. Du trenger sjelden å skrive dette navnet manuelt; dig -x bygger oppslaget for deg.

Hvem kan endre reverse DNS?

PTR ligger ikke i den vanlige DNS-sonen for domenet ditt. Den ligger i reverse-sonen for IP-adresseblokken. Den som kontrollerer eller har fått delegert denne sonen kan endre posten.

I praksis betyr det ofte:

skyleverandøren for en virtuell server
datasenteret for en dedikert server
internettleverandøren for en offentlig bedrifts-IP
e-postleverandøren for en administrert sendeplattform

Noen leverandører har et felt for «reverse DNS» i kontrollpanelet. Andre krever en supportsak eller at et fremoveroppslag finnes først. Å opprette en vanlig PTR-post i domeneleverandørens DNS-panel virker bare hvis panelet faktisk administrerer reverse-sonen for den aktuelle IP-en.

Fremoverbekreftet reverse DNS

Mange mottakere kontrollerer både reverse og forward DNS:

203.0.113.42  → PTR  → mail.example.no
mail.example.no → A  → 203.0.113.42

Når vertsnavnet fra PTR peker tilbake til den opprinnelige IP-en gjennom A eller AAAA, kalles det ofte forward-confirmed reverse DNS, forkortet FCrDNS.

Testen kan uttrykkes slik:

Finn PTR for sende-IP-en.
Finn A- og eventuelt AAAA-adressene for vertsnavnet.
Kontroller at den opprinnelige sende-IP-en finnes i resultatet.

Det er ikke nødvendig at PTR-vertsnavnet er det samme som domenet i brukerens synlige Fra-felt. En leverandør kan bruke ett stabilt servernavn for en delt sende-IP med mange kundedomener. Avsenderdomenet autentiseres separat med SPF, DKIM og DMARC.

PTR, EHLO og avsenderdomene er tre ting

Disse identitetene blandes ofte:

Identitet	Eksempel	Hva den beskriver
Sende-IP	`203.0.113.42`	Serveren som oppretter SMTP-forbindelsen
PTR-vertsnavn	`mail.example.no`	Navnet reverse DNS knytter til IP-en
EHLO-navn	`mail.example.no`	Navnet serveren presenterer i SMTP-samtalen
Envelope-from-domene	`bounce.example.no`	Domenet SPF og returer ofte bruker
Synlig Fra-domene	`example.no`	Domenet mottakeren ser i meldingen
DKIM-domene	`example.no`	Domenet i signaturens `d=`

Et ryddig direkte oppsett bruker normalt et gyldig EHLO-vertsnavn som kan slås opp og som passer med serveridentiteten. Men likhet mellom PTR og synlig Fra er ikke det som avgjør DMARC. DMARC vurderer alignment mellom synlig Fra og SPF- eller DKIM-domenet.

Hva PTR kan og ikke kan bevise

Et sammenhengende PTR- og fremoveroppslag viser at infrastrukturen har en stabil DNS-identitet. Det kan gjøre feilsøking og mottakerens risikovurdering enklere.

PTR beviser ikke at:

e-posten er ønsket
Fra-adressen er ekte
kontoen ikke er kompromittert
avsenderen har godt omdømme
SPF, DKIM eller DMARC består
meldingen vil bli levert til innboksen

PTR er derfor ett signal blant flere. Mottakere kan avvise eller begrense trafikk med manglende reverse DNS, men korrekt PTR overstyrer ikke klagerate, blokkeringer, innhold, volumendringer eller manglende autentisering.

Google krever at sende-IP-er til personlige Gmail-kontoer har gyldig fremover- og reverse DNS, og at PTR-vertsnavnet går tilbake til sende-IP-en. Kravene står i Googles løpende oppdaterte retningslinjer for e-postavsendere . Andre mottakere kan ha andre terskler og feilkoder.

Slik tester du IPv4

Start med den offentlige sende-IP-en fra leveringslogg, mottatt meldingshode eller leverandørens dokumentasjon:

dig -x 203.0.113.42 +short

Hvis svaret er mail.example.no., kontroller fremoveroppslaget:

dig A mail.example.no +short
dig AAAA mail.example.no +short

IPv4-adressen må finnes i A-svaret for at akkurat denne kjeden skal gå tilbake. Et AAAA-svar er en separat IPv6-rute og må vurderes for seg.

Bruk gjerne også:

dig -x 203.0.113.42 +trace

+trace kan hjelpe med delegeringsfeil, men krever at nettverket tillater direkte DNS-oppslag. Sammenlign resultatet med autoritative svar og flere resolvere hvis endringen er ny.

Slik tester du IPv6

Test den faktiske IPv6-adressen serveren sender fra:

dig -x 2001:db8::42 +short

Kontroller deretter at vertsnavnets AAAA-post inkluderer den samme adressen:

dig AAAA mail.example.no +short

Ikke aktiver utgående IPv6 «for sikkerhets skyld» uten komplett oppsett. En server kan ha god autentisering og omdømme på IPv4, men begynne å levere fra en ny IPv6-adresse uten PTR, riktig EHLO, oppvarmet omdømme eller tilsvarende policy. Det gir et problem som bare rammer deler av trafikken.

Vanlige feilbilder

Symptom	Sannsynlig årsak	Tiltak
`dig -x` gir ikke svar	PTR mangler eller reverse-delegeringen feiler	Kontakt den som leverer IP-en
PTR finnes, men A/AAAA peker et annet sted	Fremoveroppslaget ble endret eller PTR er gammelt	Bestem riktig serveridentitet og rett én av sidene
Noen meldinger virker, andre avvises	Flere utgående IP-er har ulikt oppsett	Kartlegg alle IP-er, IPv4 og IPv6
Bare direktesending fra webserver feiler	Webserveren bruker egen IP uten e-postoppsett	Bruk autentisert SMTP-relé eller konfigurer hele sendestakken
EHLO viser generisk eller ugyldig navn	Serverprogrammet er ikke satt opp med riktig vertsnavn	Konfigurer EHLO og kontroller fremoveroppslag
PTR-endring synes bare enkelte steder	Cache, TTL eller delegasjon	Vent i henhold til TTL og spør autoritative servere
Delt leverandør-IP får avvisning	Omdømme eller policy på leverandørens infrastruktur	Send full returkode og tidspunkt til leverandøren

Ikke konkluder ut fra en nettbasert «score» alene. Den faktiske returmeldingen, sende-IP-en og mottakerens dokumenterte krav er bedre feilsøkingsdata.

Før du sender direkte fra egen server

Direkte e-postdrift krever mer enn én DNS-post:

stabil offentlig IP for hver aktiv protokoll
fungerende PTR og fremoveroppslag
gyldig EHLO-identitet
SPF, DKIM og DMARC for avsenderstrømmene
TLS og oppdatert serverprogramvare
kø, returhåndtering og overvåking
misbruksvern, ratebegrensning og rask nøkkel-/kontosperring
håndtering av blokkeringer, klager og mottakerspesifikke krav

For de fleste små virksomheter er et administrert SMTP-relé eller en e-postleverandør enklere og mer robust enn direkte levering fra en tilfeldig webserver eller kontor-IP.

Hvis e-post fortsatt avvises

Les hele returmeldingen. En kode om reverse DNS skal undersøkes som PTR/FCrDNS; en kode om DMARC, omdømme eller mottakerpolicy krever et annet tiltak. Bruk feilsøkingsguiden for e-post som ikke sendes for å finne riktig ledd.

Har du e-post gjennom Vymo, administreres den offentlige sendeinfrastrukturen av e-posttjenesten. Vymos publiserte planer lover ikke at kunden får en dedikert sende-IP eller kan velge PTR-navnet. Ved en konkret avvisning kan du sende Vymo full statuskode, tidspunkt og mottakerdomene . Ikke send passord eller sensitivt meldingsinnhold.