Defaults.Exposed › 修復 › 反向 DNS（PTR）
如何修復 反向 DNS（PTR）
反向 DNS 是為你公司發郵件那台伺服器佩戴的身份牌。當 Gmail、Microsoft 365 這樣的收件服務商查清發件地址背後是誰、並得到一個經得起核對的名字時，你的郵件就顯得合法。一旦沒有身份牌——或名字與地址對不上——你那些完全真實的發票和報價就會被當成可疑，被悄悄丟進垃圾箱或拒收。
對您業務的關鍵影響： 你的發票、報價和給客戶的回覆悄悄落進垃圾箱、或根本沒抵達——於是生意停滯、款項遲到、客戶以為你在無視他們，而這一切都不會以你能注意到的報錯形式出現。
這會讓您付出什麼代價
- 你給一個熱門客戶發了一份報價，它掉進了對方的垃圾箱，於是他選了那個「真的回覆了」的競爭對手——而你甚至不知道郵件沒送到。
- 發給客戶的發票消失在垃圾箱裡，款項遲了好幾週才到，你的現金流因此受損，全因為沒人看到那封郵件。
- 一個客戶抱怨你從沒回他——但你回了；他的郵件服務商悄悄把你的回覆丟掉了，因為你的發件伺服器無法證明自己是誰。
- 你的網域在新客戶的安全審查裡其他項目一路過關，卻因為你的郵件伺服器沒有正經身份而被標記——一件小事，卻讓你顯得馬虎。
- 你換到一台便宜的 VPS、或一個新應用來發你的郵件簡報和發票，一夜之間送達率驟降——因為那台新的發件伺服器沒有反向 DNS 身份牌，大服務商不再信任它。
為什麼它重要。 每一家主流郵件服務商都會核查替你發信那台伺服器的身份，而且每封郵件都查。如果那台伺服器無法證明自己是誰——或者它的名字和地址自相矛盾——你正經的商務郵件就會被當成可能是垃圾郵件來處理。你失去回覆、款項和信任，而因為什麼都不退回，你通常永遠查不出原因。
一句話說清楚
當你公司發郵件時，它從一台郵件伺服器出發，而網際網路上每台伺服器都有一個數字地址——它的 IP。反向 DNS（一條「PTR」記錄）就是那台伺服器的名牌：它讓任何看到這個數字的人都能查出背後正經的名字，比如 mail.yourcompany.com。
大型收件服務商——Gmail、Microsoft 365、Yahoo——會在你發的每一封郵件上核查這塊身份牌。一台能說出自己名字、且名字和地址相互對得上的伺服器，看起來像一台合法的郵件伺服器。一台沒有身份牌、或身份牌對不上的伺服器，看起來就和垃圾郵件發送者用的那些匿名、一次性機器一模一樣。於是你正經的發票和報價，每一場對話都在嫌疑中開場——其中不少會輸。
最令人沮喪的是，沒有任何東西告訴你這正在發生。沒有退信，沒有報錯。你的郵件只是悄悄地表現不佳。
這會讓你付出什麼代價
下面是缺失或不匹配的反向 DNS 記錄一點點蠶食你金錢與信任的日常方式。我們從不點名任何真實企業——這些都是我們在資料裡看到的套路。
- 從未送達的報價。 你給一個當天早上索要報價的潛在客戶發去一份詳細報價。對方的服務商無法驗證你的發件伺服器，於是把郵件丟進垃圾箱。他們不會去翻垃圾郵件。到下午，他們已經接受了競爭對手那份「真的出現了」的報價。你把它歸咎於線索冷淡；實際上你的郵件從未被看到。
- 石沉大海的發票。 你給一個好客戶開了發票。它落進了垃圾箱。三十天後你在追一筆本不是對方過錯的逾期款——現在多了一場尷尬的對話、一段緊張的關係，以及一個本可完全避免的現金流缺口。
- 「你從沒回我。」 一個客戶因你無視他的問題而惱火。你沒有——你當天就回了。他的郵件服務商悄悄把你的回覆丟掉了，因為你的發件伺服器看起來不可信。你為一件本來做對的事顯得不專業。
- 悄悄毒化一切的自建發件伺服器。 為省錢，你的郵件（或只是簡報和自動發票）開始透過一台便宜 VPS 或一個新發件應用發出。那台伺服器從沒拿到反向 DNS 身份牌。一夜之間，你的送達率全線下滑——而因為沒有報錯訊息，花了好幾個月才疑心到原因。
- 安全審查裡的標記。 一個大客戶的 IT 團隊在引入流程中對你的網域做例行檢查。其他一切都好，但你的郵件伺服器沒有正經身份。這是個小小的技術點，卻讀起來像馬虎——現在你要麼在死線壓力下修補、要麼費力解釋，而競爭對手的網域剛剛一路過關。
貫穿所有這些的一條線：代價落在你身上，發生時它是隱形的，而修復是免費的。
它到底是什麼
普通 DNS 把名字變成數字：你輸入 yourcompany.com，DNS 交還要連線的 IP 地址。反向 DNS 反其道而行——它把數字變回名字。給定 IP 203.0.113.10，一次反向查詢（一條「PTR 記錄」）回答 mail.yourcompany.com。
收件方為什麼在乎：當你的郵件伺服器連上 Gmail 投遞一封郵件時，Gmail 看到連線進來的 IP。一個認真的郵件過濾器做的第一件事就是問 「這是誰的機器？」——辦法是對那個 IP 做反向查詢。一台真實的企業郵件伺服器有答案（mail.yourcompany.com）。一台一次性垃圾郵件機器通常沒有，或者只有一個服務商分配的通用名字，比如 host-203-0-113-10.someisp.net。所以身份牌的有無與好壞，是施加於你郵件的最早信任信號之一——比 SPF、DKIM，甚至郵件內容還要靠前。
它查的是郵件伺服器，不是你的網站。 這一點常把人絆倒。你網站的地址往往藏在 CDN 或代理（比如 Cloudflare）後面，永遠不會有匹配的身份牌——這沒關係，因為郵件的反向 DNS 關乎的是 MX 郵件伺服器的 IP，那是一台完全獨立的機器。本項檢查會正確地查出你網域的主郵件伺服器（優先順序最低的那條 MX 記錄），把它解析成 IP，再核查那個 IP 上的身份牌。
大多數設定做錯的那一半：它必須雙向都對得上。 光有名字本身還不夠。Gmail 和其他大型過濾器會做一件更嚴格的事，叫做正向確認反向 DNS（FCrDNS）：
- 查 IP → 得到一個名字（例如
mail.yourcompany.com）。 - 現在把這個名字反查回去→ 它必須解析到你起初用的同一個 IP。
如果兩個方向一致，伺服器就被確認、被完全信任。如果有名字卻指向別處（或無處），伺服器就只被半信半疑——一塊經不起第二眼審視的身份牌，被當作比你期望的更弱。一條指向攻擊者控制的主機名稱、且無法解析回來的 PTR，在某些方面比根本沒有 PTR 還糟。
本項檢查正是這樣評分的：
- 正向確認（FCrDNS）： IP 命名了一台主機，且那台主機指回同一個 IP。滿分——這是正確的設定，也是收件方信任的。
- 身份牌存在但無法確認： 有 PTR 記錄，但名字不解析回郵件伺服器的 IP。只得部分分——它看起來設好了，但大型過濾器不會完全信任它。
- 完全沒有身份牌： 郵件伺服器的 IP 上沒有 PTR 記錄。零分，且送達率的代價是真實的。
關於權重的說明： 在方法論裡，這是一項計分的郵件安全檢查（值 25 分，屬 P2 優先級項目）。它不是權重最重的郵件檢查——那是阻止徹底冒充的 SPF 和 DMARC——但它是你郵件信譽中真實、計分的一部分，也是少數取決於你服務商把事情做對、而非你自己的檢查之一。如果你只透過 Google Workspace 或 Microsoft 365 發信，你幾乎肯定已經通過了它；失敗的是那些透過自建或第三方伺服器發信的企業。
「好」長什麼樣： 你主郵件伺服器的 IP 有一條 PTR 記錄，指向一個你擁有的真實主機名稱，而那個主機名稱又直接解析回同一個 IP——兩個方向一致（FCrDNS 已確認）。
如何修復（免費，約花某人 10 分鐘）
把這一節交給擁有你郵件伺服器 IP 地址的人——通常是你的郵件或主機服務商，自建機器則是你的資料中心——並請注意修復是免費的。 這是你幾乎肯定無法在自己常用的 DNS 面板裡改的那個郵件設定，因為反向 DNS 由擁有 IP 的人控制，而不是擁有網域的人。我們只對長期監控它是否保持正確收費，從不對這次改動收費。
第 1 步——找到發件郵件伺服器的 IP。 確定網域的主 MX 主機（優先順序數字最小的那台郵件伺服器），並把它解析成 IP 地址：
dig MX yourcompany.com # 找出主（優先順序最低的）MX 主機
dig A mail.yourcompany.com # 把那台主機解析成它的 IP
需要身份牌的就是那個 IP。不要用網站的 IP——那是另一台機器，且往往在永遠不會匹配的 CDN 後面。
第 2 步——請 IP 所有者設定 PTR 記錄。 反向 DNS 歸誰控制 IP 段誰管，所以請求要發給：
- Google Workspace / Gmail： 為 Google 自己的郵件伺服器自動管理——如果一個只透過 Google 發信的網域不知何故顯示失敗，向 Google 支援提出。（實踐中這些都通過。）
- Microsoft 365： 同樣為 Microsoft 的伺服器自動管理。
- 自建或 VPS 郵件伺服器： 向你的主機服務商或資料中心開工單，請他們把你 IP 的 PTR（反向 DNS）設為你的郵件主機名稱。多數服務商在其控制台的「Reverse DNS」「rDNS」或「PTR」下提供此項。在大型雲端上這是一個單欄位設定（例如 AWS 需要一個簡短的申請表才能在彈性 IP 上啟用 rDNS；多數 VPS 主機商讓你即時設定）。
- 第三方發件應用（簡報 / 開票 / CRM 工具）： 如果它從自己的共用伺服器發信，服務商負責反向 DNS——你沒什麼要設的，對那部分流量可忽略。如果它從你向他們購買的專用 IP 發信，請他們在上面設定 PTR。
告訴他們你想要的記錄，例如：203.0.113.10 → mail.yourcompany.com。
第 3 步——讓它正向確認（這是大多數人漏掉的一步）。 PTR 裡的主機名稱還必須透過一條你在自己 DNS 裡控制的普通 A 記錄解析回同一個 IP。所以：
- PTR 說
203.0.113.10→mail.yourcompany.com（你的服務商設這個）。 - A 記錄說
mail.yourcompany.com→203.0.113.10（你在自己的 DNS 裡設這個，例如 Cloudflare → DNS → 加一條A記錄，Name 填mail，content 填203.0.113.10）。
兩個方向必須互相指向對方。只有這樣它才是正向確認、被完全信任的。
第 4 步——重新檢測你的網域。 確認郵件伺服器現在顯示為正向確認反向 DNS，且檢查通過。DNS 改動會在幾分鐘到幾小時內生效。
常見錯誤
- 把身份牌設在網站 IP 上，而非郵件伺服器上。 郵件的反向 DNS 關乎的是 MX 伺服器。給你的網站/CDN 地址加 PTR 對送達率毫無幫助——身份牌戴錯了機器。
- 止步於「PTR 存在了」。 光有名字只贏得部分信任。如果它不解析回同一個 IP，嚴格的過濾器（Gmail、M365、Yahoo）不會完全信任它。永遠完成正向確認（第 3 步）。
- 服務商設好 PTR 後忘了 A 記錄。 服務商設反向那一半；你必須在自己的 DNS 裡設正向那一半。人們做了一半就以為完事了。
- 找錯對象。 把請求發給你的網域註冊商或 DNS 主機、而非 IP 所有者，得到的回答是「我們做不了」——因為他們確實做不了。它必須發給擁有 IP 的人。
- 通用的服務商主機名稱。 像
host-203-0-113-10.someisp.net這樣的 PTR 技術上存在，卻對你的品牌或信任毫無作用。用一個在你自己網域上、能正向確認的真實主機名稱。
它在哪裡發揮作用
反向 DNS 是伺服器的身份；SPF、DKIM 和 DMARC 是網域的授權與防冒充層。它們回答不同的問題，而大服務商全都查。SPF 列出哪些服務可以以你的名義發信；DKIM 給你的郵件加密簽名，使其無法被篡改；DMARC 把兩者串起來，告訴收件方對未通過檢查的郵件怎麼辦——並保護你客戶實際看到的那個可見「發件人」名稱。反向 DNS 墊在所有這些之下，擔保正在發信的那台機器首先是一台真實、有名有姓的郵件伺服器。把 SPF、DKIM 和 DMARC 做對，獲得最強的防冒充防禦；把反向 DNS 做對，讓一台全新或自建的發件伺服器不至於在其餘檢查還沒機會上場前就被悄悄不信任。這每一項修復都是免費的。
常見問題
我不懂技術——這個我自己能搞定嗎？
通常不能，這沒關係。與大多數郵件設定不同，這一項不是在你自己網域的 DNS 裡改——它由擁有你郵件伺服器那個網際網路地址（IP）的人來設，也就是你的郵件或主機服務商。你要做的只是把「如何修復」一節轉給他們。這在他們那邊是個快速的改動，而且免費。
如果我用 Google Workspace 或 Microsoft 365，是不是已經涵蓋了？
幾乎肯定是——兩者都為各自的郵件伺服器自動管理反向 DNS，所以一個只透過它們發信的網域無需你做任何事就能通過。如果我們的檢查仍標記它，那幾乎總意味著你有一部分郵件是透過另一台伺服器（你自己的機器、一台便宜 VPS，或某個第三方發件應用）發出的，缺身份牌的正是那台伺服器。修復部分會說明該聯繫誰。
修這個會搞壞我的郵件嗎？
不會。這只是添加或修正發件伺服器的身份記錄——它不改變你的郵件發往哪裡、誰有權發它，或你的任何收件匣設定。它只是讓你已經在發的郵件更可能被信任、被送達。
這個和 SPF、DKIM、DMARC 有什麼區別？
那三個回答的是「這個網域獲准發這封郵件嗎？」反向 DNS 回答一個不同的、更靠前的問題：「正在發信的這台機器，是一台真實、可識別的郵件伺服器，還是一台匿名機器？」大服務商兩者都查。你希望它們全都對——但反向 DNS 是那個在 SPF 和 DKIM 還沒登場前，就先抓出一台全新或自建發件伺服器的檢查。
我們有反向 DNS 記錄，但檢查仍不完全通過——為什麼？
因為光有名字還不夠；名字必須雙向都經得起核對。身份牌說這台伺服器叫做，比方說，mail.yourcompany.com——但 Gmail 接著會反查這個名字，期望它正好指回完全相同的那個 IP。如果指不回去（或指向別處），服務商就把它當作未確認，只半信半疑。這種雙向匹配叫做正向確認反向 DNS，正是大多數設定漏掉的部分。
修復真的免費，還是付費推銷？
修復永遠免費——這是你服務商做的一個小設定改動，不是要你買的產品。任何告訴你設定反向 DNS 需要付費套餐的人，都說錯了。我們只對長期監控它是否保持正確收費，從不對這次改動收費。