Omvänd DNS frågar efter ett namn kopplat till en IP-adress. För en e-postavsändare är den relevanta adressen den offentliga källan som används på SMTP anslutningen. En PTR post på den adressen är användbar infrastrukturbevis, men det är den inte SPF auktorisation, a DKIM signatur eller bevis på att ett meddelande är legitimt.
Identifiera den verkliga adressen och auktoriteten
Referenser: RFC 1035 §3.5, RFC 3596 §2.5.
Börja med IP-adressen som ses av det mottagande systemet eller en kontrollerad extern SMTP observation. En applikations privata adress, en lastbalanseringsadress och leverantörens utgående adress kan skilja sig åt. Lista alla utgående adressfamiljer och pooler som tjänsten kan använda.
IPv4 omvända frågor använder omvända oktetter under in-addr.arpa. IPv6 använder omvända hexadecimala nibbles under ip6.arpa. Befogenheten för dessa omvända zoner följer IP-tilldelningen och eventuell delegering. Det är vanligtvis värd- eller nätverksleverantören, inte registratorn eller DNS värden för avsändarens synliga domän. Att publicera ett PTR-liknande namn i en icke-relaterad framåtzon kommer inte att ändra det verkliga omvända svaret.
Koordinera båda riktningarna
Referenser: RFC 1912 §2.1, RFC 2181 §10.2.
Fråga operatören för omvänd zon om den ändringsprocessen som stöds och den exakta offentliga IP-adressen. Välj ett avsett värdnamn för infrastrukturen och se till att dess vidarebefordrade adressdata inkluderar den IP-adressen. RFC 1912 rekommenderar matchning av data bakåt och framåt; det är operativ vägledning, inte ett universellt acceptansavtal för mottagare.
RFC 2181 klargör att DNS inte begränsar en adress till exakt en PTR . Flera returnerade namn måste behållas som bevis snarare än att kasseras i tysthet. För förutsägbar administration är ett stabilt dokumenterat värdnamn ofta enklare, men mottagarspecifika krav kräver sin egen aktuella dokumentation. Påstå inte att ett PTR mönster garanterar leverans till varje leverantör.
Återskapa en omvänd sökning
Syntetisk IPv4 fixtur: källadress 192.0.2.25; omvänd ägare 25.2.0.192.in -addr.arpa.; PTR mål smtp.example.com.; framåt A vid det målet 192.0.2.25. Förväntat omvänt svar är värdnamnet och förväntad vidarebekräftelse inkluderar den ursprungliga IP-adressen.
Fråga i en isolerad omvänd zon dig @AUTH -x 192.0.2.25 +norecurse och fråga sedan smtp.example.com. A mot lab forward-myndigheten. Bevara den auktoritet som används för varje riktning eftersom de inte behöver vara samma organisation. Ta bort PTR för en andra fixtur: förväntade bevis är frånvaro eller ett fel klassificerat från det faktiska svaret, inte ett nyuppfunnit värdnamn.
För IPv6 , använd sökverktygets adress-till-omvänd-konvertering istället för att manuellt förkorta nibble-namnet. Fråga dig @AUTH -x 2001:db8::25 +norecurse, ersätter AUTH med den konfigurerade labbupplösaren. En produktionskontroll måste använda en verklig observerad källadress; dessa dokumentationsintervall beskriver inte en levande avsändare.
Skilj infrastruktur från autentisering
Referenser: RFC 7208 §5.5, RFC 9989 §5.3.5.
Ett PTR mål behöver inte vara den synliga From-domänen bara för att e-post använder den domänen. En leverantör kan driva delad sändningsinfrastruktur med sitt eget värdnamn. Vad som har betydelse för en viss mottagningspolicy måste kontrolleras separat från SPF och DKIM inriktning.
Lägg inte till den avskräckta SPF ptr mekanism bara för att göra omvänd DNS relevant för SPF . Behåll PTR som ett infrastrukturproblem och konfigurera SPF med den faktiska avsändarbehörighet som stöds. Efter ändringar, verifiera framåt- och bakåtsvar, SMTP introduktionen och relevant mottagarsvar. Håll alla leveransslut begränsade till den testade rutten och tiden.
Håll bevisens omfattning tydlig
En lokal adressbibliotekskonvertering bekräftar 192.0.2.25 mappar till 25.2.0.192.in -addr.arpa och genererar det fullständiga IPv6 nibble-namnet. Den beräkningen frågar inte varken omvänd zon eller fastställer att en PTR finns. Inget leverans- eller mottagarpolicytest utfördes.