自建邮件系统实战：Eyou从安装到DNS配置与安全加固

公司用的云邮箱又到续费季了，销售发来账单的同时还不忘补一句“你们账号数超了，建议升级套餐”。算了一笔账，从几十个账号到上百个账号，一年下来两万多，而且所有往来邮件都存在别人的服务器上，数据合规这关怎么想都别扭。我干脆找了个周末，把Eyou（亿邮）邮件系统自己搭了一套出来，从解压安装包到收发测试通过，连带调DNS记录，前后不到两天。这篇文章把整个搭建过程写全，包括选型思路、环境准备、安装步骤、DNS和收发的关键配置、安全加固，以及我实际踩过的三个坑，给准备自建邮箱或者想把云邮箱换回来的兄弟一个能直接抄作业的参考。

1. 自建邮箱为什么还选Eyou：选型前先想清楚这几件事

1.1 从云邮箱切回自建的真实推动力

很多人劝我别折腾，说云邮箱省心、稳定、反垃圾能力强。这些优势我承认，但实际用下来有几个问题是绕不开的。

第一是账号计费模式。云邮箱按账号收费，账号一多就非常肉疼，而且很多销售话术里“无限容量”“不限附件大小”都是有限制条件的，真到用的时候才发现要单独花钱开大附件、单独买归档空间。

第二个是数据主权。公司内部讨论方案、客户合同、和上下游厂商的往来函件，这些都属于敏感业务数据。放在云上不是不能接受，但一旦涉及合规审查、安全审计，流程会特别被动。自建邮箱起码能做到“数据在自己手里，备份自己控制”。

第三个是管理自由度。云邮箱对发信频率、单封附件大小、收信规则都有比较死的限制。尤其做外贸或者做运营的，一天要发几百封同类通知邮件，云邮箱很容易触发限发，处理起来很麻烦。自建之后，所有阈值都可以自己调，合理合规地放开。

当然，自建也要有心理准备：你需要一台服务器，需要一个能改MX、SPF、DKIM的域名DNS后台，出了故障得自己查日志。不过对于有基础Linux维护经验的人来说，这些都不是门槛，反倒是长期受益的事。

1.2 Eyou邮件系统能干什么

Eyou的全称是亿邮电子邮件系统，国内高校、研究所、政企单位用得非常多，算得上邮件系统里面的老牌选手。它的定位就是一套完整的企业/机构邮件解决方案，一套装完，常见的功能都有了。

它能提供的核心能力包括：

• Webmail收发信，支持在浏览器里完成邮件读写、附件上传下载、通讯录、日程和网盘功能；
• 标准SMTP/POP3/IMAP服务，支持Outlook、Foxmail、手机自带邮件App通过标准协议接入；
• 内建反垃圾、反病毒引擎，可以按域、按用户配置不同的策略等级；
• 邮件群组、邮件列表、别名转发，适合按部门建组或者给业务邮箱做别名；
• 管理后台支持批量导入账号、设置配额、查看收发日志、做分发规则。

和国外开源邮件系统相比，Eyou最直观的优势是中文界面完整、管理逻辑符合国内企业习惯、部署不需要自己从零拼接Postfix/Dovecot这些组件。另外它对国产化硬件和操作系统的适配做得早，很多单位选它就是因为这块有保障。

1.3 快速搭建的两条路线

我在调研阶段发现，搭建Eyou邮件系统基本有两条路。

一条是直接用厂商提供的虚拟机镜像。Eyou官方渠道一般会提供OVA或者打包好的虚拟磁盘镜像，导入VMware或者主流虚拟化平台，改一下IP、换一下密码就能跑起来。这条路线最快，特别适合第一次接触Eyou、只想先体验功能的用户。

另一条路是从头部署安装包。安装包是tar.gz壳子，内部带安装脚本和依赖组件，在干净的Linux服务器上执行脚本后完成安装。这条路线适合业务服务器已经有存量环境、需要更精准控制安装路径和依赖的用户，也更方便后续升级和排障。

我个人用的是安装包部署方式，因为这台服务器以后还要跑其他运维监控组件，我不想为了一个邮件系统就把一整台机器完全圈死。如果你就是为了纯跑邮件的专用服务器，直接上镜像更省事。

2. 环境准备：硬件、系统和安装包，一次列全

2.1 硬件配置怎么定

邮件系统的特点是：真正占用资源的是磁盘IO和内存，CPU反而不是瓶颈。收信、投递、反病毒扫描这些操作都重度依赖磁盘读写，所以优先保证硬盘和内存到位。

以100人规模的企业邮箱为例，我的建议配置如下：

这里有个估算逻辑：每个用户的邮箱配额设在5GB到10GB之间，算上日志、临时文件、索引文件，实际磁盘消耗大概是“用户数×配额×1.3”。100人每人5GB配额，至少准备650GB以上空间。另外系统盘和数据盘最好分开挂载，将来数据盘满了，扩容的时候不用动系统。

内存低于8GB不太建议跑，因为反垃圾引擎和Webmail进程都是吃内存大户，内存不够的时候收发邮件能明显感觉到卡顿。

2.2 系统版本与安装包获取

Eyou官方对操作系统的支持名单里，最稳的是CentOS 7/RHEL 7的x86_64版本。我这次用的是CentOS 7.9，原因很简单：官方文档适配充分、遇到问题社区案例多、yum源配置成熟。

如果你的环境是Ubuntu或者Debian，也不是不能装，但请一定先跟官方确认当前版本的安装包是否明确支持，避免装到一半才暴露兼容性问题。我见过有人拿Ubuntu 22.04硬装老版本安装包，结果系统自带的OpenSSL版本过高导致编译依赖失败，非常折腾。

安装包本身属于商业软件范畴，需要向Eyou厂商或授权渠道申请试用。一般会拿到一个试用版安装包，账号数和有效期都有限制。正式生产环境要联系商务拿许可证，激活之后才能解除限制。

拿到安装包后，我习惯先算一下SHA256：

sha256sum eYouMailServer-xxx.tar.gz

和厂商提供的值比对，确认文件没被篡改或者传输损坏再解压。

2.3 系统初始化四件事

这一步很多人会跳过，但恰恰是后面排障时最容易返工的地方。我每次装邮件服务器之前，都会先在干净的Linux上做完以下几件事。

设置静态IP。邮件服务器必须有固定IP，服务器IP变了，所有DNS记录全部失效。改配置文件：

vim /etc/sysconfig/network-scripts/ifcfg-eth0

把BOOTPROTO改static，配上IP、掩码、网关和DNS。

设置主机名为完整的邮件域名。这个细节直接影响后续证书申请和客户端配置：

hostnamectl set-hostname mail.example.com

同时编辑/etc/hosts，把主机名和IP映射写进去，避免启动时反向解析慢导致服务起不来。

关闭SELinux。SELinux默认的强制模式会拦截邮件服务写日志、读队列、绑定端口，排查起来极其痛苦。开发环境直接关掉：

setenforce 0 sed -i 's/SELINUX=enforcing/SELINUX=disabled/g' /etc/selinux/config

如果是比较严格的等保环境不想关掉，可以设置成permissive，让SELinux先只告警不拦截，确认服务正常后再逐条放行。

防火墙放行端口。CentOS 7默认开着firewalld，先确认需要放行的端口再启动服务。如果你用的是云服务器，云控制台安全组里的入方向规则也要同步放开，两边都放行才算真正放行。

3. 安装过程详解：从脚本执行到Webmail首次登录

3.1 解压与执行安装脚本

操作系统和网络准备好之后，把安装包上传到服务器。我一般放在/opt目录下，避免放在/home下因为用户目录权限问题导致读取受限。

cd /opt tar zxvf eYouMailServer-xxx.tar.gz cd eYouMailServer ./install.sh

安装脚本启动之后是向导式的交互界面，核心要填的信息就几项：选择“全新安装”、“请输入邮件域名”、“设置管理员邮箱密码”。临时过渡环境可以随便用个测试域名，正式生产一定要用你自己真实拥有的域名，比如example.com，后面DNS配置全都要围绕这个域名展开。

脚本跑起来之后会自动解压依赖组件、创建服务账号、初始化数据库、配置反垃圾引擎和Web服务。安装过程受服务器性能和系统源速度影响，一般10到30分钟不等。如果卡住不动，先看终端输出是不是在等某个交互确认，不要急着Ctrl+C，真有耐心等不走了再查日志。

安装结束时，脚本会打印出访问地址。通常包括两个：

• Webmail用户入口：https://mail.example.com/
• 管理员后台入口：https://mail.example.com/ 下的特定路径，或者在安装输出里直接给了一个带端口的管理地址

这一步一定截图或者记到笔记里，后面天天要用。

3.2 首次登录Webmail与管理后台

第一次登录先用安装时设置的邮箱账号测通Webmail。我习惯把密码先设成一个临时强密码，等整条链路跑通后再改成正式密码并开启二次验证。

Webmail界面登录成功后，能看到收件箱、写信、通讯录、日程这些模块。先试试给自己发一封测试邮件，如果自己能给自己发信且能收到，说明本域内投递正常，再把重点放在外部收发。

管理员后台能看到的内容更细，包括组织机构管理、域名管理、邮箱账号管理、系统监控、系统日志、反垃圾设置、服务状态等。我建议刚装完先做三件事：改管理员后台密码、确认邮件域状态为“正常”、检查默认反垃圾策略等级。

3.3 域名与邮箱账号的创建顺序

这里有个容易搞混的顺序：先去“域名管理”里把邮件域添加/确认为example.com，再去“账号管理”里创建用户，最后再创建别名和群组。

很多人装完直接从“账号管理”界面添加user1，结果用户建出来是user1@系统默认域，而不是自己的业务域。虽然也能用，但后面发信时对方看到的发件人域名不对，容易直接进垃圾箱。正确的顺序一定是域先行、账号随后。

批量创建用户时，管理员后台一般支持CSV导入，字段包含姓名、邮箱前缀、初始密码、所属部门、配额大小。我帮客户迁移邮件系统时经常用这个功能，一次性导入几百个账号效率非常高。

4. DNS与收发链路：真正决定邮件能不能到的是解析不是安装

4.1 MX、A、PTR三条基础记录

邮件系统装完只是第一步，能不能和外部互通，决定权在DNS。

拿example.com来说，至少要有三条基础记录配合工作。

A记录：mail.example.com 解析到邮件服务器公网IP。这条记录没有的话，别人连mail.example.com都解析不到。

MX记录：example.com 的MX记录指向 mail.example.com，优先级一般写成10。对方服务器要给你发邮件时，先去查example.com的MX记录，拿到值之后再去解析这个值对应的IP，最后才发起SMTP连接。

PTR反向解析：公网IP的反向PTR记录，指向mail.example.com。PTR主要用来做信任验证，很多反垃圾系统会把“发信IP有没有PTR记录”当作一个重要评分项。没有PTR的邮件，轻则延迟进箱，重则直接拒收。

DNS后台配置完成后，本地用命令验证：

dig mx example.com dig A mail.example.com nslookup 公网IP

看起来都是解析记录，实际上很多搭建失败案例就是栽在这里：MX解析都还没生效，就急着去测试外部发信，当然收不到。

4.2 SPF、DKIM、DMARC三件套

基础记录配完之后，为了让外面的邮件服务器愿意信任你的发信身份，还要加三件套。

SPF记录声明“哪些IP和域名允许代表example.com发信”。以我们这台服务器为例：

v=spf1 mx ip4:服务器公网IP -all

这条记录的意思是：只有MX记录指向的服务器和这台指定IP有权发example.com的邮件，其他来源一律不认可。

DKIM是域名密钥识别邮件，本质就是给发出的邮件做签名。Eyou管理后台通常可以在“域名设置”里生成DKIM密钥对，然后把公钥内容作为一条TXT记录发布到域名里。对方收到邮件后会查TXT记录，用公钥验签，验不过就判定伪造。

DMARC则是告诉对方，如果SPF和DKIM都没过，邮件怎么处理。常见配置：

v=DMARC1; p=quarantine; rua=mailto:postmaster@example.com

p=quarantine表示疑似伪造邮件进垃圾箱；rwua是把报告发到指定邮箱方便查看。

三条记录的发布地方都是在域名DNS管理后台，以TXT或MX类型添加，不需要在服务器上做任何配置，但决定邮件能不能进对方主收件箱的，恰恰就是它们。

4.3 收发测试前的必要检查

配置完DNS记录后，不要急着群发测试信。先按顺序做三个十秒检查。

第一个检查是解析是否生效。用dig命令确认MX和SPF记录值，很多DNS服务商的修改生效是分钟到小时级别的，刚改完立刻查还是旧值很正常。

第二个检查是25端口是否可达。外部测试机执行：

telnet mail.example.com 25

出现SMTP服务横幅说明端口畅通。如果连接超时，大概率是云安全组或机房防火墙没有放行25端口。

第三个检查是用一个外部免费邮箱发一封测试信，观察到达位置。建议先发到QQ邮箱或Gmail收信测试，如果进了垃圾箱，优先回查SPF、DKIM配置是否完整。

我用mail-tester这类网站做过评分测试，调试前后得分差异非常明显：没配DKIM的时候评分勉强及格，SPF、DKIM、DMARC都配齐之后，发信身份评分接近满分。

5. 账号、别名与反垃圾：管理员后台的高频操作

5.1 创建邮箱账号与批量导入

管理员后台最常用的功能就是账号管理。单个创建账号很简单：填邮箱前缀、显示名、初始密码、邮箱配额，选所属部门，保存即可。Eyou的配额单位可以按MB设置，1000MB就是1GB。

批量导入时，我建议先下载官方CSV模板看一眼字段格式，避免自己造的CSV列名对不上。批量导入完成后，一定要抽查几个账号是否能正常登录Webmail，防止模板里编码问题导致密码中文乱码。

账号初始密码我一般设成复杂随机密码，然后在全员通知里让员工第一次登录时自行改密。很多安全事件就是初始密码统一且长期不改造成的，宁可多一步流程，不要省这个安全裕度。

5.2 别名与邮件群组的实际用法

别名适合给业务入口用。比如contact@example.com就是销售组的对外公开邮箱，但后端对应的是sales01、sales02、sales03三个真实账号的转发关系。这样销售同事流动时，对外邮箱地址不用变。

群组适合按部门或项目组建。投递到group@example.com的邮件，所有加入群组的成员都能收到。Eyou支持群组成员自由订阅和取消，管理后台设置群组管理员后，群组日常工作可以下放给业务同事，不需要每次加人都找IT。

5.3 反垃圾策略怎么调

Eyou默认反垃圾策略对绝大多数场景够用。如果内部对垃圾邮件容忍度低，可以在反垃圾全局配置里把评分阈值调低，识别更激进。但要注意阈值调太低会有误杀风险，业务方抱怨“重要客户邮件被吞了”比“垃圾邮件多进来几封”更难处理。

我会先保持默认阈值跑一周，看后台垃圾邮件统计，分析被拦截样本中有没有正常邮件。确认策略偏保守还是偏激进，再微调阈值。重点业务域名、重点客户域名可以单独加白名单，保证投递不中断。

6. 安全加固与端口规划：上线前必须做的高危项排查

6.1 端口开放清单

Eyou邮件系统涉及的服务端口不少，但不是所有端口都要对公网开放。按照最小暴露原则，我的开放思路如下：

管理后台默认如果带了独立端口，我强烈建议在云安全组里把那个端口限制成只允许公司办公网IP访问。管理后台被公网扫描爆破是迟早的事，直接把入口封掉最省心。

6.2 25端口被运营商限制的问题

自建邮件服务器最容易踩的隐形坑就是云厂商对25端口的限制。很多云厂商默认禁止25端口出方向，目的避免被恶意用户滥发垃圾邮件。你要发外部邮件，就必须先在云控制台提交解封申请，一般要填业务用途和承诺书。

我建议在部署前就先去云控制台把25端口申请流程走起来，因为这个审核不一定实时通过。等装完再发现发不出去邮件才去申请，中间等待时间纯属浪费。

6.3 防止服务器被当成中继

邮件服务器最怕被利用成垃圾邮件中继。一旦你的服务器可以匿名帮外部用户发信，很快会被反垃圾组织列入黑名单，后果是全站外发邮件被拒收。

自检方法很简单，从外部环境连接你的邮件服务器：

telnet 服务器公网IP 25 HELO test.com MAIL FROM:<attacker@test.com> RCPT TO:<someone@example.com>

正常配置下，服务器应该拒绝外域用户使用本地域发信，或者要求先认证。如果在没有认证的情况下就能转发，说明中继漏洞开得很彻底。Eyou默认安装包里中继控制是关闭的，但升级、迁移配置时经常被改回来，所以我每次上线前都会自检一遍。

另外，管理员密码、数据库密码、SSH密钥这些初始凭据，装完第一时间全部更换。我在实际工作中见过好几次安装完成页面被人截图后默认密码泄露的案例，初始密码等于是公开的，不换就是裸奔。

7. 排障实录：退信、收不到、延迟高，三类典型问题的排查链路

7.1 外部发不进来：三天后终于发现是PTR没做

第一次完整搭好Eyou，我给自己回复一封来自外部邮箱的信，结果等了半小时都没收到。下意识觉得是服务器问题，翻了一堆服务状态，全都正常。

后来冷静下来按链路查了一遍，发现最先该查的是DNS解析。尽管MX和A记录都已经生效，但外部邮箱发信时报“554 4.7.1 helo rejected”之类的错，对方服务器在验证发件人身份时，会反向验证我们这台发信IP的PTR记录。因为没有PTR记录，对方认为这是一台来历不明的服务器，直接拒绝连接。

解决办法是找机房或云厂商提交PTR解析申请，绑定mail.example.com。PTR生效后再发测试信，秒达。

这次踩坑给我的体会是：排障顺序真的要从DNS开始，不要一上来就怀疑服务挂了。按“MX解析->25端口通不通->PTR反查->SPF/DKIM”的顺序走，能少走太多弯路。

7.2 内部发得好好的，外部发不出去：SPF记录语法错误

另一个朋友遇到的问题更典型：内部互发完全正常，对外发信却经常被对方退信。退信代码提示“550 SPF validation failed”。

查他域名DNS后台发现，SPF记录被运维写成两条重复记录，导致SPF校验结果变成了permerror。SPF记录在整个域里只能存在一条，如果配置了多条，读取方不知道以哪条为准，直接判定校验失败。

修复方法很简单：把多条SPF删掉，只保留一条，并且用include语法汇聚需要授权的所有来源：

v=spf1 mx ip4:IP1 include:spf.供应商.com -all

这里也提醒一点，很多同事为了方便，喜欢在SPF里把范围写得很宽，比如直接用+all，等于告诉大家“所有人都能代表这个域发信”，反垃圾评分会直接扣到负分。SPF的原则一定是最小授权，能写几个授权对象就写几个，别图省事。

7.3 邮件延迟高：新买服务器IP被反垃圾系统盯上了

还有一次替客户排查外部发信延迟，对方在MSN/Hotmail系邮箱收信时，经常要等15分钟甚至一个小时才收到。

查了队列、查了DNS解析、查了网络，最终问题锁定在新买的云服务器IP信用度太低。云服务商的IP段里，很多IP之前被滥用发过垃圾邮件，信誉已经烂了。即便当前用户是正常使用，也会被反垃圾系统列为“待观察”状态，邮件先进隔离区观察，等确认信誉好转才放行。

这块没什么一键修复的办法，只能做到三件事：SPF、DKIM、DMARC齐全，控制发信频率不要突增，每天关注退信和延迟报告。正常使用两到四周后，IP信誉会慢慢恢复。另外如果业务允许，也可以考虑向云厂商申请独立IP，避开共享IP段的信誉拖累。

最后再分享一个自己习惯上的调整：装完邮件系统不要急着把原有云邮箱的所有数据一次性迁移过来，先用新系统跑一两周，确认收发链路彻底稳定，再分批切流。我见过太多人图快一天内把几百个账号全部切过来，结果反垃圾误杀、客户端配置、别名转发一堆问题同时爆发，运维根本接不住。

自建邮件系统不是装上就算完，真正考验人的是后面这些DNS、安全、信誉层面的功课。按这个节奏走，多数问题都能提前规避，剩下的，也能靠排查链路快速定位。