简介：这份文档面向需要自行搭建邮件服务的技术人员与运维初学者，围绕 hMailServer 的部署与配置展开，帮助读者理解从协议原理到客户端接入的完整流程。包内共 1 个 doc 文件，压缩包约 263KB，篇幅精简但内容集中，涵盖下载与版本选择、SMTP 收发原理说明、添加域与用户的方法、协议选择、SMTP 参数调整、Routes 路由配置、认证方式设置以及 Log 日志配置等环节，并补充服务器自动注册为服务后的管理要点与客户端配置注意事项，例如账号须按 xxx@server.com 格式书写、关闭服务器认证等易错细节。资源还给出相关下载地址与 SMTP 原理参考链接，便于延伸查阅。目前已有 2642 人学习浏览，适合作为邮件服务器入门配置的速查笔记与排错参考，也可供搭建测试环境时对照核对关键参数。
1. 一份 2008 年的配置记录：hMailServer 4.4.1 今天还能不能照着抄
翻出一份老手记，标题就叫 hmailserver 的完整配置，记的版本是 hMailServer-4.4.1-B273.exe。第一反应是这东西还能不能跑——现在的邮件生态对发信方比当年严得多，反向解析、SPF、TLS 一样不能少。可照着它的顺序走一遍，会发现骨架其实很干净：域、账号、协议、SMTP、Routes、认证、日志，七步一条线，没有一句多余的废话。它适合两类人：要在隔离内网里搭自建邮件服务、给应用发通知或者做收发测试的；以及想搞明白一封邮件到底卡在 SMTP 链路哪一跳的。对外营业级的公网收发不在射程内，这点先说清楚。
2. 装之前的三笔前置账：版本线、端口占用与域名解析
很多人拿到这种配置记录，第一步就是双击 exe，然后卡在"装完了但连不上"。邮件服务器这个品类，安装只占工作量的三成，剩下七成在装之前就该算清楚：跑哪个版本、占哪些端口、域名往哪儿解析。这三笔账里任何一笔算错，后面所有配置都会表现出"看起来对、就是不工作"的玄学症状，而邮件系统恰好是个几乎不给错误提示的黑匣子——信发出去了，日志也写了，对方就是没收到。
2.1 4.4.x 这条版本线与它的管理客户端
hMailServer 的分发形态是单文件 exe，4.4.1-B273 属于 4.x 末期的小版本，安装过程中会问数据库怎么选：内置的精简数据库，还是外接一台 MSSQL。除非你手上已经有现成的数据库实例要复用，否则直接选内置的那套省掉一堆连接串和权限问题，装完就能用，账号、域、日志都落在安装目录里，备份就是拷文件夹。
安装完成后有两个东西要分清。一个是 Windows 服务，名字就叫 hMailServer，向导默认会把它注册成自启动服务，这意味着管理程序关掉、远程桌面断开、机器重启，收信发信都不受影响——这是那份记录里"可以放心退出管理程序"这句话的真实含义，不是让你不管它。另一个是管理客户端 hMailServer Administrator，它只是个前端，通过本地连接去操作服务，本身不承载任何邮件逻辑。所以出现"管理界面打不开但邮件还在正常收发"的时候不用慌，先看服务是不是活着。
首次打开管理程序会让你设一个管理员密码，这个密码和邮箱账号密码完全是两套东西，别混。我一般会把它记在和服务器资产台账一起的地方，因为 hMailServer 没有"忘记密码"的找回流程，丢了只能进数据库改或者重装。
至于系统兼容性，4.x 是那个年代的产物，如果只是想把这份配置流程复现一遍、验证投递链路，扔进虚拟机跑一个同时期的系统最省事，也避免和现网环境里的其他服务抢端口。这不是必须，但能省掉很多"装到一半报错、报错信息还看不懂"的时间。
2.2 端口清单：哪几个必须通，哪几个只是本机自嗨
邮件服务最容易被忽略的一点：它对端口的要求是双向的。你自己监听 25 不代表别人能连上你的 25，中间还有防火墙、安全组、运营商策略三道关。先把默认端口列清楚，后面配协议时对着这张表勾。
| 用途 | 默认端口 | 加密端口 | 关键说明 |
|---|---|---|---|
| 服务器之间投递信件 | 25 | 465 | 必须允许外部主动连入，否则收不到任何外域来信 |
| 客户端提交待发信件 | 25 / 587 | 465 | 587 更规范，很多网络封了出站 25 |
| POP3 收信 | 110 | 995 | 单机下载式收信，多端不同步 |
| IMAP 收信 | 143 | 993 | 多端同步，客户端体验更好但占资源 |
表里最要命的是 25。国内多数住宅宽带和部分云主机默认封禁出站 25，表现是"本地投递正常、发给外域全部超时重试"。遇到这种情况不用怀疑配置，先确认链路：换一个能通 25 的环境测，或者在 SMTP 里配中继（后面 4.1 会讲），把出站交给上游。
DNS 那边要准备的记录不多，但一条都不能少：
- A 记录，把 mail.yourdomain.com 指到服务器的公网地址，这台机器必须有固定的、能反向解析的地址；
- MX 记录，把 yourdomain.com 的收信指向 mail.yourdomain.com，优先级填 10 就行，单机没有备选；
- TXT 记录，写一条 SPF，最小可用形态是
v=spf1 mx -all，意思是只有 MX 指向的那台机器有权用这个域发信； - 反向解析 PTR，这条不归你管，得找地址的归属方加，但是没有它，很多接收方会直接把你的信判成可疑。
提示：域名、IP、SPF 三样东西是绑在一起生效的。改任何一样，都要留出解析生效时间，别改完立刻测然后判定"配置失败"。
2.3 安装向导里那两个默认勾选，别一路下一步
向导里有两个地方值得停一下。第一个是数据库选择，前面说了，单机自用选内置。第二个是端口绑定方式，默认是监听所有网络接口，对应写法就是只写端口号（比如 25），等价于 0.0.0.0:25。如果这台机器有多张网卡、或者你只想让它在内网那张卡上提供服务，就写成192.0.2.10:25这种"地址:端口"的形式，把监听范围收窄。
收窄监听范围不只是洁癖。一台同时连着内网和公网的机器，如果 SMTP 在两张卡上都监听，而内网那张卡的网段又在 IP 范围里被划成了受信任，等于给外部留了一条绕过认证的路。后面讲 IP Ranges 的时候会再提一次，这里先把绑定的口子扎紧。
装完立刻做一次端口自检，别等配完域和账号才发现端口没通：
# 在服务器本机看监听状态，确认 25/110/143 都在 LISTENING netstat -ano | findstr ":25 :110 :143" # 从另一台机器测连通性，能拿到 220 开头的欢迎语就算通 telnet mail.yourdomain.com 25第一条命令的-ano表示显示所有连接、用数字形式显示地址和端口、附带进程号，看到 0.0.0.0:25 说明监听范围是全接口。第二条命令连上以后，hMailServer 会回一行类似220 mail.yourdomain.com ESMTP的欢迎语，这行里的主机名就是后面要在 SMTP 设置里对齐的 Host name，两边不一致会给自己埋坑。如果 telnet 直接卡住然后超时，先查 Windows 防火墙的入站规则，再看云主机的安全组，最后才怀疑服务本身。
3. 域、账号与协议：把一台邮件服务器立起来的最小闭环
到这一步，机器有了、端口通了、DNS 也在生效路上，接下来要建立的是三个层次的东西：域（这台机器替谁收发）、账号（这个域下有哪些人）、协议（用哪些方式对外提供服务）。顺序不能乱，先有域才能建账号，账号建完才有东西可谈协议。那份记录里写得很简略——"添加域和用户，针对域，只需配置 IP 地址就可以了"，这句话省略了大量前提，照着字面理解很容易翻车。
3.1 添加域：那个 IP 地址字段到底填不填
Domains 节点右键添加，会看到两个输入框：域名和 IP 地址。域名没什么好说的，写你要托管的那个，比如 yourdomain.com，不要带 www、不要带 @、不要写成 mail.yourdomain.com，这是 MX 记录指向的主机名，不是域本身。
IP 地址这一栏是新手最容易填错的地方。它的含义是"这个域只在这个本地地址上应答"，用途是多 IP 场景下做区分——一台机器绑了三个公网地址，三个域分别从不同地址出去。绝大多数单机部署根本没有这个需求，留空即可，留空表示不限制。
那份记录写"只需配置 IP 地址就可以了"，在它的语境里大概是指多域共存时用地址区分，但这句话被单独摘出来看，会让人误以为这栏是必填。真填了一个和本机网卡对不上的地址，症状是收信全部超时、日志里连一条 SMTPD 记录都没有——因为服务根本没在那个地址上应答。这种"配置项填了但没有任何报错"的坑，排查起来最费时间。
同一个域下面还有几个属性值得顺手设掉：最大邮箱大小、单封信最大尺寸、默认账号配额。前两个是域的兜底值，账号级别可以单独覆盖但不能超过域的限制。别嫌麻烦，不设的话默认值可能大得离谱，一台小机器被塞满只是时间问题。
3.2 账号为什么必须写成完整的邮箱地址
Accounts 节点下添加账号，最关键的字段是 Address。hMailServer 这里有个和其他 MTA 不太一样的地方：它要求你填完整地址，也就是zhangsan@yourdomain.com，而不是只填zhangsan。填短了不会立刻报错，但客户端用完整地址去认证时会匹配不上，表现为反复弹密码框、日志里出现认证失败。
这不是设计缺陷，是它的账号模型决定的——hMailServer 的账号是全局唯一的完整地址，同一个域下的账号和别的域下的账号放在同一张表里，用短名没法定位。理解了这点，后面客户端配置里"账号写法需要 xxx@server.com"那句就不是玄学了，是硬性要求。
建账号时顺手要设的还有三样：密码、邮箱大小上限（单位 MB，超过就拒收，不是自动清理）、以及是否需要自动回复。密码别用弱口令，尤其当这台机器后面要暴露在公网上的时候，一个被猜中的账号就是一台发垃圾信的中转机。
建完先在管理程序里发一封内部测试信，收件人写自己，这一步只验证账号存在和本地投递通路，不涉及任何外部依赖：
Domains → yourdomain.com → Accounts → 新建 Address: test@yourdomain.com Password: 设置一个强口令 Max size: 200（MB）四行填完点保存，账号立刻可用，不需要重启服务。如果保存时报"地址已存在"，多半是你之前建过一个同名但大小写不同的，hMailServer 对地址是大小写不敏感的。
3.3 三个协议的开关、端口与并发限制
Settings → Protocols 下面并列着 SMTP、POP3、IMAP 三块，每块的结构类似：一个启用勾选、一个 TCP/IP ports 列表、一组连接数和尺寸限制。
SMTP 是必须开的，没有它什么都干不了。端口列表默认是 25，想同时跑提交端口就再添一行 587。这里的写法是每行一个，格式为"地址:端口"或只写端口，和前面安装时说的是同一套规则。
POP3 和 IMAP 按需要开。只做应用通知、只发不收的场景，两个都可以不开；要给用户提供正常邮箱体验，至少开 IMAP，因为 POP3 把信下载到本地后服务器上的副本处理策略很别扭，多设备场景下容易丢信或者重复收。开了之后端口分别是 110 和 143，加密端口 995 和 993 需要在服务端配好证书才会生效。
连接数限制这一项容易被忽略。默认值放在内网几十个人的规模够用，但如果是应用批量发信，瞬时并发很容易顶到上限，症状是客户端报"连接被拒绝"而日志里写着连接数超限。调这个值之前先看机器内存，一个 IMAP 连接的开销不算小，盲目拉到几百只会让整台机器变慢。
3.4 客户端填写模板，以及"关闭服务器认证"的适用边界
客户端配置是那份记录的最后一步，也是被简化得最厉害的一步。它给了两个要点：账号写成完整邮箱、关闭服务器认证。第一条是硬规则，第二条有明确前提，脱离前提照抄会出事。
先把标准模板摆出来，按这个填基本不会错：
| 客户端字段 | 填写内容 | 备注 |
|---|---|---|
| 收件服务器 | mail.yourdomain.com | 与 A 记录、MX 一致 |
| 收件协议/端口 | IMAP 143 或 POP3 110 | 有证书再用 993/995 |
| 发件服务器 | mail.yourdomain.com | 同上 |
| 发件端口 | 25 或 587 | 25 被封时用 587 |
| 用户名 | test@yourdomain.com | 必须完整，不能只写 test |
| 密码 | 账号密码 | 不是管理员密码 |
| 发件服务器需要认证 | 内网受信任段可关，公网必须开 | 见下方说明 |
"关闭服务器认证"这条，成立的前提是服务器侧已经把客户的来源地址划进了受信任的 IP 范围（通常是本机或内网段），服务端对这个范围不要求认证。在这个前提下客户端勾不勾认证都能发信。但如果这台服务器要对外提供服务，客户端的来源地址落在 Internet 范围里，服务端就会要求认证，此时客户端还关着认证，结果就是能收不能发，或者发出去被拒。
更麻烦的是另一种情况：服务端把 Internet 范围也设成了"不需要认证"，客户端也关着认证，两边一拍即合——这台机器就成了一台谁都能借道发信的中转。这种配置在隔离内网里跑测试没问题，接公网就是给自己找麻烦。所以我一般会强制要求：只要这台机器的 25 端口对外可达，客户端就必须勾上"我的发件服务器需要身份验证"，没有例外。
4. SMTP 与 Routes 的组合：让邮件既能发出去也能收进来
域和账号建完，机器只能自己跟自己玩。要让信真正走出去、外面的信真正走进来，靠的是 SMTP 面板和 Routes 这两块配合。前者决定"我怎么把信交出去"，后者决定"某些特定的收件域我不按常规走"。这两块配错的概率最高，因为它们的选项名字都很温和，看不出哪个会引发事故。
4.1 SMTP 面板里必改的四个参数
Settings → Protocols → SMTP 下面子项很多，先盯这四个。
第一是 Host name，也叫 HELO 名。它是服务器在 SMTP 对话里自报家门的名字，必须是一个能被 DNS 正向解析、且和你出口 IP 对得上的完整域名，通常就是 mail.yourdomain.com。填成机器名、localhost、或者干脆留空，对端在反查时对不上，轻则进垃圾箱，重则直接 550 拒收。这一项是公网发信被拒的头号原因，比 SPF 还常见。
第二是中继（SMTP Relayer）。当你的出站 25 被封、或者出口 IP 没有干净信誉时，把所有出站信交给一个上游服商转发是标准解法。填对方的地址、端口、以及认证用的用户名密码。开了中继以后，服务器不再直接连对端的 25，所有投递都走这一条路，日志里能看到连接目标变了。注意中继和 Routes 是两回事，前者管全部出站，后者管特定域，别混用。
第三是重试策略。默认的投递重试次数和间隔在内网够用，公网环境下建议把重试拉长一些，因为对端临时故障（4xx 响应）很常见，急着判死会让用户以为信丢了。重试到期还没成功，服务器会生成一封退信回到发件人，那封退信里的诊断码才是真正有用的信息。
第四是尺寸与收件人限制。单封信最大尺寸、单封信最大收件人数，这两个值不设，一个用户往通讯录里全选发一封带附件的信就能把队列堵住。按实际业务定，通知类业务通常几 MB、几十个收件人就够。
4.2 Routes：什么情况下必须配，怎么配才不绕回自己
Routes 在 Settings → Protocols → SMTP → Routes 下面（不同小版本的入口文字略有差异，找带 Route 字样的那项）。它的作用是：当收件域满足某个匹配条件时，不要按 MX 去解析，直接把信交给指定的主机和端口。
什么时候需要它？三种典型场景。内网 DNS 解析不到对端的 MX，直接投递必然失败；某些域名的信必须统一走上游中继，不能自己直连；服务器迁移期间临时把某个域的收信改道到新机器。
配置项的填法：
| 配置项 | 含义 | 典型填法 |
|---|---|---|
| Domain | 匹配哪个收件域 | partner.internal 或 yourdomain.com |
| Target SMTP Host | 交给谁 | 192.0.2.20 或 relay.upstream.com |
| TCP/IP Port | 对方监听端口 | 25，几乎不改 |
| 匹配范围 | 全部地址还是域内地址 | 单域转发选"该域所有地址" |
| 失败处理 | 目标不可达时怎么办 | 选按正常 MX 重试，别选直接退信 |
最后一行的"失败处理"是个隐藏雷区。如果目标主机挂了而你选的是直接退信，所有走这条路由的信会瞬间全部退回，用户端看到的就是"突然之间所有信都发不出去"。选正常重试，至少给了你修复的时间窗口。
更隐蔽的一个坑是把 Target Host 填成了本机地址加 25 端口。看起来是"我先收下来再处理"，实际效果是形成一个环路：服务器收到信，按路由交给自己的 25，自己又收到一遍，再交给自己。日志里同一封信的 ID 反复出现、队列只增不减，几分钟就能把磁盘写满。这种邮件风暴一旦起来，停服务是唯一止血手段，改完配置再启。
4.3 认证与那条"allow plain text authentication"的红线
认证这块在 Settings → Advanced → IP Ranges 里，默认预置了两个范围：My computer（本机）和 Internet（其余全部）。每个范围是一组策略的集合，控制四件事：允许从哪些方向投递、是否需要认证、是否允许明文认证、是否允许中继到外部。
四个投递方向要分开看，它们的风险等级完全不同：
| 方向 | 含义 | 建议 |
|---|---|---|
| Local to local | 本域账号发给本域账号 | 可不要求认证，方便内部应用发通知 |
| Local to external | 本域账号发往外域 | 必须要求认证，否则等于开放中转 |
| External to local | 外域发给本域账号 | 不要求认证，否则收不到任何外部来信 |
| External to external | 外域经你转发到另一个外域 | 一律禁止，这是垃圾邮件最爱的口子 |
这张表里最容易设反的是第三行。有人为了"安全"把 External to local 也设成需要认证，结果所有外域来信全部被拒，症状是内部互发完全正常、外部一封信都进不来，而且日志里能看到明确的拒绝记录，反而好查。
现在说那份记录里点名的那条：配置 trac 的时候，"allow plain text authentication"不能勾选，否则报错。这条结论是对的，但它没写原因，照抄的人一旦遇到别的现象就会懵。我的理解是这样的：这个勾选控制服务器是否接受以明文方式提交用户名密码，勾上之后，服务器在握手时会向客户端通告支持明文认证机制。trac 的通知是通过脚本调用 SMTP 发信的，它用的库在协商认证机制时比较挑，如果服务器通告的机制集合和它的预期不一致，就会在认证阶段失败，表现出来就是通知发不出去、应用日志里一串认证异常，而邮件服务器这边只留下一条语焉不详的会话记录。
所以这条红线的正确表述不是"永远别勾"，而是"当你的发信方是脚本类应用、且它不需要明文认证时，把这一项关掉"。反过来，如果某个老客户端只支持明文认证、你又必须让它发信，那就得勾上，但要同时保证这条通路是加密的或者仅限内网，别让密码在公网上裸奔。
注意：改 IP Ranges 是即时生效的，不需要重启服务。改完立刻用外部地址发一封信验证，别等到第二天用户投诉才发现方向设反了。
4.4 日志：出问题时先看哪几个文件
Settings → Logging 里一排勾选框：Application、SMTP、POP3、IMAP、TCP/IP、Debug、AWStats。全勾上会让日志量爆炸，一天几个 G 很常见，而且真正要找的那几行会被淹没。
我的习惯是常开 Application + SMTP，排查期临时加 TCP/IP，Debug 只在确认是协议层问题时短时间打开，问题定位完立刻关掉。POP3 和 IMAP 的日志只在怀疑客户端同步异常时才开。
日志文件落在安装目录的 Logs 下，按日期命名，格式大致是 hmailserver_YYYY-MM-DD.log。找一封具体的信，最快的方式是拿收件人地址去搜，顺着会话 ID 往下看，能看到这封信从接收、排队、投递到对端的完整过程，以及对方返回的三位数字状态码。三位码的第一位是分类：2 开头成功，4 开头临时失败会重试，5 开头永久失败会退信。看第一位就能判断这封信还有没有救。
5. 五条踩坑记录：现象、原因和最后怎么解决的
配置这种事情，顺利的时候二十分钟搞定，不顺利的时候两天都卡在一个勾选框上。下面这五条是我在实际环境里反复遇到的，按"看到什么现象、根子在哪、怎么改"的顺序写，遇到类似情况可以直接对号入座。
5.1 日志显示投递成功，对方就是说没收到
现象：SMTP 日志里这封信的状态是已完成，对端也返回了 250，但收件人翻遍收件箱、垃圾箱都找不到。
原因基本不在你这边。250 只代表对端服务器接受了这封信，接下来的过滤、归档、垃圾判定都是它内部的事。最常见的三种情况：你的 HELO 名和出口 IP 对不上被反查判可疑；域没有 SPF 或者 SPF 写错，被硬拒或软拒；内容命中了对方的规则。
解决顺序是先把自身三项对齐：Host name 必须是能正向解析的域名，PTR 必须指回同一个域名，SPF 必须覆盖实际发信 IP。三项对齐后仍然不收，就让对方管理员去日志里按时间点查，他们那边一定能看到拒收理由，比你在自己这边猜快得多。
5.2 内部互发正常，发给外域全部卡在队列里
现象：队列里堆着一堆信，状态是正在重试，日志里连接对端 25 端口超时。
原因：出站 25 被封，这是最常见的。或者本机防火墙只放行了入站没放行出站。判断方法很直接，在服务器上换个端口连一下对端，连不上就是链路问题，跟配置无关。
解决：把 SMTP Relayer 配上，所有出站交给上游转发，端口用对方给的（通常 587 或 465），认证信息填对。配完队列里的信会自动按新路径重投，不用手动重发。这条也是内网部署最实用的一个技巧——与其跟运营商扯皮，不如老老实实走中继。
5.3 客户端能收不能发，反复弹密码框
现象：收信一切正常，发信时客户端提示认证失败，密码明明是对的。
原因有三层，按概率排：账号写成了短名而不是完整邮箱，这是最常见的；客户端没勾"发件服务器需要身份验证"，服务端要求认证而客户端没提交；或者服务端 IP 范围把该来源划进了不需要认证的范围，客户端提交的认证信息被忽略后又被别的策略拒了。
解决：先把账号改成完整地址，重试；不行就检查客户端的发件认证勾选；再不行去 IP Ranges 看这个来源地址落在哪个范围、那个范围的四个投递方向是怎么设的。三步之内基本能定位。
5.4 脚本发通知全部失败，邮件服务器日志几乎没记录
现象：应用侧报 SMTP 认证异常，但邮件服务器日志里只有零星几条会话，看不出所以然。
原因：多半就是 4.3 里说的那条明文认证。脚本类客户端在协商认证机制时，如果服务器通告的机制集合不匹配，会在认证阶段直接失败，而失败发生在协议早期，应用层的日志往往只有一句笼统的异常。
解决：临时把 TCP/IP 和 Debug 日志打开，重放一次发信，看会话里服务器通告了哪些机制、客户端选了哪个、在哪一步断的。定位到是明文认证的问题后，把该 IP 范围的"允许明文认证"关掉，或者反过来给脚本换一个支持现代认证方式的发信库。改完记得把 Debug 关掉。
5.5 磁盘一夜之间被写满，队列里全是同一封信
现象：早上发现服务器磁盘告警，队列里有几万封内容相同的信，日志里同一个会话 ID 反复出现。
原因：Routes 把目标指向了本机地址加 25 端口，形成投递环路；或者两个域互相把对方设为路由目标，A 转给 B、B 转回 A。
解决：第一步先停服务止血，这一步不能犹豫，环路每秒都在放大。然后去 Routes 里逐条检查 Target Host，凡是等于本机地址或者指向另一个会转回来的域的，全部删掉或者改正。改完启服务，清空队列里那些重复的信，再补一条监控：队列长度超过阈值就告警。这个坑我吃过一次，从那以后凡是配 Routes，我都会先把 Target Host 抄在纸上确认一遍，再往框里填。
6. 三段式验收：把配置从看起来对变成确实通
配置全部填完、服务也重启了，这时候最容易犯的错是"发一封试试，收到就算完"。自建邮件系统的坑大多藏在边界上——本域互发永远正常，一旦跨域就原形毕露。所以验收要走三段，从协议层到应用层逐级确认。
第一段是协议层，手工跟服务器对话，确认它该说的都说了：
# 连上 25 端口，看欢迎语里的主机名是否与 Host name 一致 telnet mail.yourdomain.com 25 # 依次输入，每行一条，看返回码 EHLO test.local # 看服务端通告的能力列表里有没有 AUTH MAIL FROM:<test@yourdomain.com> # 应为 250 RCPT TO:<someone@example.net> # 应为 250 或 551，不能是 550 拒绝 QUITEHLO的返回里如果出现了 AUTH 关键字，说明认证通路是通的；如果RCPT TO直接返回 550，说明这个域的策略不允许往外投，回去看 IP Ranges 的 Local to external 那一行。这一段的价值在于把"配置问题"和"网络问题"彻底分开，很多人卡一天就是因为没做这一步。
第二段看日志，走一遍完整的收发，然后在 Logs 目录里找到对应的会话，确认三件事：信被接收时有记录、投递到对端时对端返回了 2xx、没有异常重试。日志里每个会话都带唯一标识，顺着它能把一封信的一生看完。
第三段才是真实收发。用两个不同域名的邮箱互发一封带中文主题和附件的信，确认主题不乱码、附件能打开、时间戳正常。中文乱码这一项单靠本地测试永远测不出来，因为它跟客户端编码、服务器转码策略都有关。
最后留一个习惯：每次改完配置，把改动项、改动时间、验证结果记一行到同一个文档里。邮件系统的故障往往不是当场爆发的，而是三天后有人反映"某类信收不到了"，这时候那份记录就是唯一的后悔药。希望帮到你。
本文还有配套的精品资源，点击获取
