反向DNS與PTR紀錄：郵件伺服器為何需要

從位址到名稱

A與AAAA等正向DNS紀錄位於網域的區域中：控制example.com的人，決定www.example.com指向哪個位址。反向DNS需要另一個樹狀結構，因為位址並不是依網域名稱組織的。IPv4的這個樹狀結構是in-addr.arpa，IPv6則是ip6.arpa。

建立反向名稱時，位址要倒過來寫。8.8.8.8會變成8.8.8.8.in-addr.arpa，203.0.113.10會變成10.113.0.203.in-addr.arpa，讓位址中最概括的部分像網域名稱一樣放在最後。IPv6則是把完整32位數位址的每個十六進位數字倒序排列並以點分隔，因此IPv6的反向名稱很長。

誰控制PTR紀錄

位址區塊的反向區域，由區域網際網路註冊管理機構授權給持有該區塊的組織，再由該組織授權給它指定的對象。家用或行動網路的對象就是你的網路服務供應商；雲端伺服器則是雲端服務商，通常可讓你在控制台中設定名稱，或依申請代為設定。

因此，在網域註冊商或DNS代管服務加入PTR紀錄不會有任何作用：它們並不控制你伺服器位址的反向區域。請洽詢提供該位址的供應商，並告知你想要的確切主機名稱。

正向確認的反向DNS

任何控制反向區域的人，都能在其中發布任何名稱，甚至是他人網域下的名稱。因此PTR名稱要從反方向驗證：查詢該名稱的A或AAAA紀錄，確認其中包含原始位址。兩個方向一致時，就稱為正向確認的反向DNS（FCrDNS）。

IPNixa的反向DNS查詢會執行這兩個步驟：先向Cloudflare與Google查詢PTR紀錄，再查詢傳回的名稱，並回報四種狀態之一。

實際查詢結果

我們在2026年11月2日，透過Cloudflare與Google的DNS-over-HTTPS解析器查詢了以下公開位址。每個名稱都能解析回原始位址。

範例說明了什麼

第四個位址是當時Gmail收信主機gmail-smtp-in.l.google.com所傳回的位址。它的PTR名稱不在gmail.com之下，而是在Google用於伺服器名稱的網域1e100.net之下。PTR名稱不必與服務對外使用的網域相同，但必須能解析回該位址。

兩個解析器傳回相同的名稱，剩餘的快取時間卻差異很大。以8.8.8.8為例，Cloudflare回報84,907秒，Google則是18,566秒，因為兩者在不同時間快取了這筆紀錄。因此，供應商修改PTR紀錄後，舊名稱最長可能在整個TTL期間內持續出現。

家用連線通常會有一個依位址產生的通用名稱。同一天檢查的一條曼谷寬頻線路，傳回了ppp-a-b-c-d.revip8.asianet.co.th形式的名稱，其中a到d是位址的各段數字。這類名稱能辨識供應商，通常也能看出連線類型，但無法辨識用戶本人。

郵件伺服器為何需要反向DNS

收信的郵件伺服器會以反向DNS作為低成本的第一道檢查，阻擋來自遭入侵家用電腦的垃圾郵件。Google的寄件者規範要求寄信伺服器具備有效的PTR紀錄，且能解析回寄信位址；其他大型信箱服務商也有類似檢查。像上述寬頻範例那樣的通用名稱，通常會被視為家用連線而遭到過濾。

1. 在你控制的網域下為伺服器選一個主機名稱，例如mail.example.com。
2. 建立A紀錄（若伺服器透過IPv6寄信，也要建立AAAA紀錄），將該主機名稱指向伺服器的位址。
3. 請擁有該位址的供應商，把該位址的PTR紀錄設為相同的主機名稱。伺服器用來寄信的每個位址（IPv4與IPv6）都要設定。
4. 讓郵件伺服器在SMTP問候訊息（HELO或EHLO）中宣告相同的主機名稱。
5. 用IPNixa反向DNS查詢檢查結果，直到兩個解析器都顯示相符；請預留舊紀錄TTL到期的時間。

反向DNS無法告訴你的事

PTR名稱是位址擁有者選定的標籤，可能已過時、只是通用名稱，或根本不存在，也無法說明目前是誰在使用某個浮動位址。請用它來辨識網路或伺服器的用途，而不是辨識個人。192.168.1.10這類私有位址沒有公開的反向紀錄，因此查詢會略過它們。