★ FEATURED ARTICLE 公司内网自建的邮件服务器发不出外部邮件这个场景我见得太多了。新来的运维同事把服务器装好、账号建好、内部互发测试全绿结果一到给外部客户发邮件就石沉大海日志里躺着一行看不懂的退信代码或者干脆连退信都没有邮件像进了黑洞。这个问题表面上是发外部邮件一个动作背后其实牵扯到DNS解析、反向解析、发信认证、端口放行、信誉机制等一整条链路任何一环掉链子都会导致投递失败。我打算把这条链路从头到尾拆一遍讲清楚每一步在干什么、为什么必须这么配、配错了会看到什么现象让手上有内网邮件服务器的朋友能照着排查也让刚接触邮件系统的同行少走点弯路。内容偏实战涉及具体配置的地方我会给出可复现的示例但不会绑定某个特定产品Postfix、Exchange、国产邮件网关的思路是相通的。1. 先搞清楚内网发外部到底卡在哪一层很多人一上来就怀疑是对方拒收其实大部分问题出在自己这边。邮件从你的服务器到对方收件箱中间要经过好几个环节每个环节都有独立的失败表现。先把链路拆开才能对症下药。1.1 一封外发邮件的完整旅程一封邮件从内网服务器发出大致要经过这么几步服务器通过DNS查询收件人域名的MX记录找到对方邮件服务器的地址然后和对方服务器的25端口建立SMTP连接接着进行发信方身份验证现在主流是SPF、DKIM、DMARC三件套对方服务器根据你的IP信誉、域名信誉、认证结果决定接收还是拒绝接收后再做内容过滤最后投递到收件人邮箱。这条链路上任何一步失败都会表现为发不出去。但失败的位置不同你能看到的线索完全不同。比如MX查询失败你的服务器日志里会直接报找不到主机25端口连不上日志里是连接超时被对方拒收日志里会有对方返回的SMTP错误码像550、554这类。所以排查第一步永远是看自己服务器的邮件日志而不是猜。我见过有同事折腾了一下午防火墙最后发现是DNS里MX记录压根没配。也见过有人反复改SPF记录结果是出口IP被对方拉黑了。日志不会骗人关键是你要看得懂它在说什么。1.2 内网环境特有的三个隐形障碍内网邮件服务器和公网托管的最大区别在于网络边界。第一个障碍是出口NAT。你的服务器在内网用的是私有地址出去的时候被NAT成公网IP但很多邮件系统在握手时会做反向解析PTR如果这个公网IP的反向解析记录和你的发信域名对不上对方直接判为可疑。第二个障碍是25端口出站限制。不少网络环境默认封了出站25端口防止内网机器被感染后大量发垃圾邮件结果正常业务也受牵连。第三个障碍是DNS解析。内网服务器如果用的是内网DNS很可能查不到外部域名的MX记录或者解析结果被内网策略改写。这三个障碍的共同点是内部测试完全正常一碰外部就出问题。因为内部互发根本不经过这些环节。所以判断问题范围有个简单办法先确认服务器能不能正常解析外部域名再确认能不能连上对方25端口最后才看认证和信誉。顺序别乱从底层往上查效率最高。1.3 用日志定位失败环节的实操方法以常见的Postfix为例外发失败时日志里通常有这么几类关键行。第一类是DNS相关出现Host or domain name not found或者Name service error说明MX查询失败问题在DNS配置。第二类是连接相关出现connect to ... Connection timed out或者Network is unreachable说明网络层不通重点查防火墙和路由。第三类是对方拒收出现said: 550、said: 554这类冒号后面是对方服务器返回的原文这段文字信息量最大直接告诉你拒收原因。我的习惯是先把日志里最近一次外发尝试的完整记录抓出来从to收件人这一行开始往下看一直看到status结尾。中间每一行都对应一个动作连接、握手、认证、投递哪一步断了清清楚楚。如果日志级别不够临时把日志调详细一点再复现一次比瞎猜快得多。提示排查期间建议单独用一个测试账号发信收件人用自己可控的外部邮箱这样能完整看到发送端日志和接收端结果两头的信息定位效率翻倍。2. DNS这几条记录配不对后面全白搭邮件系统对DNS的依赖程度远超一般服务。A记录、MX记录、SPF记录、PTR记录、DKIM记录、DMARC记录每一条都有明确用途缺一条或者配错一条轻则进垃圾箱重则直接被拒。这一块是最容易出问题、也最容易被忽视的地方。2.1 MX记录和A记录先把门牌号写对MX记录告诉全世界发给这个域名的邮件该送到哪台服务器。它的值是一个主机名不是IP地址而且这个主机名必须能通过A记录解析到IP。很多人图省事MX直接填IP这是不合规的部分接收方会因此判为配置错误。正确做法是先给邮件服务器配一个A记录比如mail.example.com指向公网IP然后MX记录指向mail.example.com并设置一个优先级数字数值越小优先级越高单台服务器填10就行。这里有个内网场景的坑如果你的邮件服务器同时负责内网和外网收发MX记录必须指向公网可达的那个地址。内网用户访问时靠内部DNS或者hosts把它解析到内网地址外网投递则走公网地址。两套解析结果要一致地指向同一台逻辑服务器否则会出现外网能发进来、内网用户收不到的怪现象。2.2 SPF记录告诉对方这台机器有权替我发信SPF的本质是一条授权声明哪些IP有权以我的域名发信。它写在域名的TXT记录里格式类似vspf1 ip4:203.0.113.10 -all。这里的ip4:后面跟你的公网出口IP-all表示除了列出的地址其他一律视为伪造。如果出口IP不止一个就写多条或者用include:引入其他授权机制。配SPF最常见的错误是漏了出口IP。比如服务器本身是公网IP但发信经过一台网关做了NAT实际到达对方的是网关的IP而SPF里只写了服务器IP结果认证失败。还有一种情况是IP变了没同步更新SPF云环境里弹性IP换一个SPF不改外发立刻出问题。我的建议是SPF记录里把当前所有可能的出口IP都列全并且定期核对。-all和~all的区别也值得说一下。-all是硬失败未授权IP发信直接判失败~all是软失败标记为可疑但不一定拒收。刚上线不确定IP是否列全的时候可以先用~all观察一段时间确认没问题再收紧成-all。这个细节很多教程不提但实际运维中很有用。2.3 PTR反向解析内网NAT环境的重灾区PTR记录是IP到域名的反向查询由IP的持有方通常是网络服务商来配置你自己在域名DNS里改不了。它的作用是让对方确认这个IP确实属于它声称的域名。很多接收方会把PTR记录缺失或与发信域名不匹配作为垃圾邮件的重要判据。内网环境为什么容易在这栽跟头因为你的服务器是私有IP出去被NAT成公网IP而这个公网IP的PTR记录往往指向网络服务商的通用域名跟你的邮件域名毫无关系。对方一查PTR是static-203-0-113-10.isp.example.net而你的发信域名是example.com对不上信誉分直接扣。解决办法有两个方向。一是向网络服务商申请把出口IP的PTR改成你的邮件域名正规服务商一般支持这个操作提交工单说明用途即可。二是如果出口IP的PTR实在改不了考虑用中继服务让邮件从一台PTR配置正确的中继服务器出去。前者是根治后者是绕行看你的实际条件选。2.4 DKIM和DMARC加分项也是必选项DKIM是给邮件加数字签名接收方用你域名下公布的公钥验证签名确认邮件在传输过程中没被篡改、确实来自你的域名。配置分两步先生成一对密钥私钥配在邮件服务器上用于签名公钥以TXT记录形式发布到DNS的特定子域名下选择器._domainkey.你的域名。DMARC则是在SPF和DKIM基础上再加一层策略声明告诉对方如果SPF和DKIM都没通过你该怎么处理这封邮件同时提供一个报告接收地址方便你监控伪造情况。这两项现在越来越像必选项而不是加分项。主流邮箱服务商对新域名、低信誉域名的邮件如果没有DKIM签名进垃圾箱的概率明显上升。配置本身不复杂但要注意密钥长度建议2048位、选择器命名规范、DNS记录格式别写错。DMARC初期建议用pnone只观察不拦截收集一段时间报告确认自己的正常邮件都能通过SPF和DKIM再逐步收紧到pquarantine甚至preject。3. 网络出口这道关端口、NAT与连接策略DNS配好了不代表邮件就能出去。网络层的放行和地址转换是另一道硬门槛而且这一层的故障表现往往更隐蔽因为很多环境默认就封了相关端口你甚至不知道是被封了。3.1 出站25端口的封禁与应对25端口是SMTP的标准端口邮件服务器之间投递就走这个端口。但正因为它是发垃圾邮件的经典通道大量网络环境在出口处默认封禁了出站25端口。你的服务器尝试连接对方25端口时表现为连接超时日志里是Connection timed out看起来像对方服务器挂了实际是自己这边被拦了。怎么确认是不是被封最直接的办法是在邮件服务器上用telnet或者nc测试连接一个已知可用的外部邮件服务器的25端口。比如telnet mx.example.org 25如果能建立连接并看到对方返回的220欢迎信息说明出站25是通的如果一直卡住直到超时基本可以判定被封。注意测试要在邮件服务器本机做不要在办公电脑上做因为策略可能按网段区分。确认被封之后的应对一是找网络管理方申请放行邮件服务器的出站25通常需要说明用途并限定源IP只放行邮件服务器这一台风险可控。二是如果放行申请不下来改用邮件中继把外发邮件交给一台允许的服务器或者服务商的中继服务转发你的服务器只负责把邮件交给中继由中继去投递。三是部分环境支持提交端口587但587是邮件客户端提交用的服务器之间投递还是25不能混用。3.2 NAT映射与源地址一致性内网服务器通过NAT访问外网时源地址会被转换。这里有个容易被忽略的点如果你的出口有多个公网IP或者NAT策略是动态选路的那么不同时间发出的邮件可能来自不同IP。而你的SPF记录、PTR记录都是针对特定IP配的源地址一变认证就对不上。我遇到过一个典型案例出口有两条线路做负载均衡邮件有时走A线路有时走B线路SPF里只写了A线路的IP结果走B线路的邮件全部SPF失败。排查的时候看日志一切正常是对方退信里提到SPF不通过才发现的。解决办法是给邮件服务器做策略路由固定走一条线路或者把两条线路的出口IP都加进SPF。还有一种情况是NAT设备对SMTP协议做了特殊处理比如改写了某些头部字段或者限制了并发连接数。这类问题比较隐蔽表现是偶发失败或者大附件发送中断。排查时可以在服务器和对方之间抓包对比看数据是否被中间设备动过。3.3 连接超时与重试策略的调优邮件投递失败不一定是永久性的很多是临时故障比如对方服务器繁忙、网络抖动。邮件系统一般有重试机制隔一段时间再试超过一定次数或时间才判定为最终失败。这个重试策略的配置直接影响用户体验。以Postfix为例几个关键参数值得关注maximal_queue_lifetime控制邮件在队列里最多待多久默认5天超过就退信minimal_backoff_time和maximal_backoff_time控制重试间隔的起止值。如果对方是临时故障默认策略一般够用。但如果你的业务对时效敏感可以适当缩短队列生存时间让失败更早暴露出来而不是拖几天才退信。反过来如果对方明确返回了4xx临时错误码说明是暂时性问题应该继续重试返回5xx永久错误码说明是硬失败重试也没用应该立即退信并通知发件人。有些系统配置不当对5xx也反复重试白白占用队列资源。检查一下你的重试逻辑是否区分了4xx和5xx这个细节很多默认配置是处理好的但自定义配置时容易漏。4. 发信认证与信誉决定邮件进 inbox 还是 spam前面几关都过了邮件能送到对方服务器了但送到不等于送达。对方还要判断这封邮件是不是垃圾、是不是伪造判断依据就是认证结果和信誉记录。这一层决定了你的邮件最终躺在收件箱还是垃圾箱甚至直接被拒。4.1 SMTP认证别把能发和有权发搞混这里要区分两个概念。一个是服务器之间的投递认证靠SPF、DKIM、DMARC这套机制另一个是用户提交邮件时的身份认证靠用户名密码或者OAuth。内网邮件服务器往外发信如果允许内网用户无需认证就能通过服务器外发那就成了开放中继open relay会被迅速利用来发垃圾邮件然后你的IP就被拉黑了。所以第一件事是确认你的服务器没有开放中继。测试方法从一台不属于你授权网段的机器尝试通过你的服务器向一个外部地址发信如果成功说明配置有漏洞。正规配置应该只允许认证用户或者可信内网网段通过服务器外发其他一律拒绝。用户提交认证这块建议强制使用加密连接STARTTLS或者SSL避免密码明文传输。认证方式上简单的用户名密码够用但对安全性要求高的环境可以考虑更严格的机制。认证失败次数要有锁定策略防止暴力破解。4.2 IP和域名信誉看不见的评分卡接收方对每封来信都会做一个信誉判断依据包括发信IP的历史行为、域名年龄、是否在各类黑名单里、认证是否通过、邮件内容特征等。这个评分卡你看不到但它实实在在影响投递结果。新IP、新域名天然信誉低这是正常的需要时间积累。加速建立信誉的办法是保证认证配置完整SPF、DKIM、DMARC全通过、控制发信量和频率别一上来就群发、及时处理退信和投诉、保持发信内容规范。反过来拉低信誉的行为包括大量发送到无效地址退信率高、被用户标记为垃圾、内容里带可疑链接或附件、发信频率忽高忽低。检查自己是否在黑名单里可以用一些公开的黑名单查询服务输入你的发信IP或域名看是否被收录。如果被收录先搞清楚为什么被收录通常是有人利用你的服务器发垃圾或者你的IP段历史有问题处理完根源再申请移除。盲目申请移除而不解决根源很快又会被收进去。4.3 内容与头部规范细节决定成败邮件内容本身也影响投递。几个基本原则HTML邮件要有纯文本替代版本图片和文字比例要合理别搞成一张大图配几个字链接域名要和发信域名相关别用短链接跳转到完全无关的站点附件类型和大小要合理可执行文件基本必被拦。邮件头部也有讲究。From地址要和认证域名一致别出现From是a.com但SPF认证的是b.com这种错配。Reply-To、Message-ID、Date这些标准头部要完整规范。有些自建系统生成的Message-ID格式不规范或者Date时区写错都可能成为扣分项。还有一个常被忽略的点是退订机制。如果是营销类或者通知类邮件要提供清晰的退订方式并且退订请求要及时生效。用户点了退订你还继续发被投诉的概率极高投诉率是信誉评分里权重很大的因子。事务类邮件比如密码重置、订单确认一般不需要退订但也要确保只发给确实需要的人。5. 一套可复现的外发链路自检流程讲了这么多原理最后落到操作上。我整理了一套从内到外的自检流程按顺序走一遍基本能定位绝大多数外发问题。这套流程不依赖特定产品Postfix、Exchange或者国产邮件系统都能套用只是具体命令和界面不同。5.1 从服务器本机发起的分层测试第一步确认DNS解析正常。在邮件服务器上执行nslookup -typemx 收件人域名或者dig mx 收件人域名看能否返回MX记录。如果返回空或者报错问题在DNS先解决解析。第二步确认能连上对方25端口用telnet 对方MX主机 25测试能收到220欢迎语说明网络通。第三步手动走一遍SMTP会话用EHLO、MAIL FROM、RCPT TO、DATA这几条命令手工发一封测试邮件观察每一步对方的响应。这一步能暴露认证、拒收等应用层问题比看日志更直观。手工SMTP会话看着原始但信息最全。对方在哪个环节返回什么错误码、错误信息原文是什么一目了然。我排查疑难问题时经常用这招比反复翻日志快。注意手工测试时MAIL FROM要用你真实的发信地址别随便填否则认证结果不准。5.2 认证配置的逐项核对清单DNS和网络都通了之后逐项核对认证配置。SPF用公开的SPF检查工具输入你的域名和发信IP看是否返回pass。DKIM发一封测试邮件到支持DKIM验证的邮箱看邮件头部里的Authentication-Results是否显示dkimpass。DMARC同样看头部里的dmarcpass以及策略是否符合预期。PTR用反向查询工具查你的出口IP看返回的域名是否和发信域名匹配。这四项里任何一项fail都要回到对应章节去修。四项全pass认证层面基本没问题。建议把这套核对做成定期检查因为IP、DNS、证书这些东西会变配好不等于一直好。5.3 常见退信代码的对照处理对方拒收时返回的SMTP代码是最直接的线索。下面这张表覆盖了外发场景最常见的几类遇到对不上号的再具体查。返回代码常见含义处理方向550 5.7.1被策略拒绝常见于IP或域名信誉问题查黑名单、查SPF/PTR、申请移除550 5.1.1收件人地址不存在核对地址清理无效收件人554 5.7.1被判定为垃圾邮件或中继被拒检查是否开放中继、检查内容421 4.7.0临时限制连接过多或频率过高降低发信频率稍后重试450 4.7.1临时策略拒绝多为灰名单机制等待后重试通常会自动通过灰名单greylisting值得单独说一句。有些接收方对陌生发信方第一次投递先返回450临时拒绝过几分钟再重试就放行。这是对方反垃圾策略不是你的问题正常重试即可。如果你的重试间隔太短或者不重试就会误以为发送失败。确认对方是否启用灰名单看返回码是不是450开头、重试后是否成功即可判断。5.4 上线前的压力与合规预检正式大量外发之前建议做两件事。一是小批量试发先给几个不同服务商的邮箱各发几封观察投递结果和落箱位置收件箱还是垃圾箱确认各主流服务商都能正常接收。二是检查合规项发信内容是否符合规范、是否提供了必要的退订方式、收件人列表是否经过许可别买名单群发、退信处理流程是否就绪。还有一点是监控。外发链路要有人盯着队列积压、退信率突增、认证失败率上升这些都是早期信号。配一个简单的监控定时检查队列长度和最近退信情况比出了问题再救火强得多。我见过队列积压了几千封才发现的情况那时候已经影响业务了。6. 几个反复踩到的坑和我的处理习惯原理和流程讲完了最后分享几个实际运维中反复遇到的问题以及我形成的处理习惯。这些内容在标准文档里基本看不到都是踩出来的。6.1 内部正常外部失败的思维定式最常见的误判就是拿内部测试的结果当依据。内部互发不经过DNS外部解析、不经过NAT、不经过对方认证全绿太正常了。所以我的习惯是任何外发相关的改动验证一律用外部邮箱绝不用内部账号互发来确认。这个习惯能省掉大量以为好了其实没好的返工。另一个相关的心态问题是急于改配置。一出问题就同时改DNS、改防火墙、改认证改完不知道是哪一项起了作用下次再出问题还是不会。正确做法是一次只动一个变量改完立即验证确认有效再动下一个。慢就是快。6.2 变更管理DNS和IP变更的连锁反应邮件系统对变更特别敏感。换IP、换域名、换证书、调整NAT策略每一个动作都可能影响外发。我的做法是维护一份邮件相关配置清单把SPF里的IP、PTR对应的域名、DKIM选择器、DMARC策略、出口线路这些信息集中记录任何变更前先对照清单评估影响变更后逐项验证。举个具体的换出口IP的时候要同步更新SPF记录、申请新IP的PTR、检查新IP是否在黑名单里、确认新IP的25端口出站是否放行。这四件事漏一件外发就可能出问题。有清单在手按项打勾不容易漏。6.3 长期维护信誉是养出来的邮件投递这件事配置只是一次性的信誉是长期的。我的经验是把它当成一个需要持续照料的东西定期查黑名单、监控退信率和投诉率、保持认证配置有效、控制发信节奏、及时清理无效地址。这些动作不复杂但要坚持。新域名新IP要有耐心别指望配好当天就能大量投递。先用小量正常邮件养一段时间信誉观察各服务商的落箱情况稳定了再逐步放量。急于求成往往适得其反触发风控后恢复起来更麻烦。我个人在实际操作中的体会是邮件系统的问题八成出在以为配好了和实际没生效之间的差距上。DNS记录改了要等生效生效了要验证验证要用对方法。把验证这一步做扎实比任何高级技巧都管用。每次改动后花五分钟做一遍分层测试长期看省下的排查时间远超这五分钟的投入。
阅读完成 · 觉得有帮助？
