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 需要付费套餐的人，都说错了。我们只对长期监控它是否保持正确收费，从不对这次改动收费。