有了自己的域名，给自己建一个邮箱并不难。难的是后面那些事：发给客户的邮件有没有进收件箱，手机能不能同步，服务器宕机后能不能找回旧邮件，以及某天收不到信时，你知不知道从哪里查起。
RackNerd VPS 配合 Mail-in-a-Box，适合愿意自己管理这些事情的人。你租一台独立的 Linux 虚拟服务器，用 Mail-in-a-Box 安装邮件系统，邮箱地址、账户和数据由自己管理。个人域名邮箱、几个人的工作室，以及想弄清楚邮件如何运转的开发者，都可以从这套组合开始。
先划清使用范围：自建邮箱仍然受机房规则、IP 信誉和收件方策略约束。服务器能连接 SMTP 端口，也可能遭到收件方限速或拒收。不要把它当成绕开发信限制的群发工具，更不要在新机器上导入一份来路不明的地址名单。
这篇指南按个人与小团队的正常收发需求展开。配置建议来自部署所需的资源和维护要求，文中没有声称做过 RackNerd 的长期送达率测试。
准备一台独立的邮件服务器
先看 2GB 或以上内存、独立 IPv4 和可用磁盘，再向客服确认所选机房的 SMTP 端口与反向解析条件。
选 RackNerd 前，先确认邮件服务需要的条件
RackNerd 的 KVM VPS 产品提供完整 root 权限，部分优惠套餐页面列出了独立 IPv4 和 rDNS 管理功能。这些条件对自建邮箱有用：你需要安装系统服务，也需要让外部邮件服务器查到你的主机名。购买时应核对具体套餐，别把共享主机的邮件功能、转售主机的中继服务，与独立 VPS 混为一谈。
网上常见“RackNerd 默认开放 25 端口”的介绍，但端口政策还涉及产品、机房和账户状态。购前把用途写清楚：准备运行个人或小团队域名邮箱，需要入站、出站 TCP 25，也需要把分配到的 IP 的 PTR 记录设置为自己的邮件主机名。要求客服针对所选方案答复，保留工单。本文不把第三方文章里的“无需申请”写成所有订单都适用的承诺。
25 端口负责邮件服务器之间的投递。你在电脑上填写的 SMTP 465 或 587，负责把邮件提交给自己的服务器。两段连接经过不同的网络路径。客户端显示“发送成功”，只能证明提交环节完成；你的 VPS 还要把邮件交给收件方。
机房位置可以按你管理服务器、同步邮件时的网络体验来选。延迟对下载大附件有影响，不能据此判断进收件箱的概率。新分配的 IP 是否有不良历史、DNS 身份是否一致、收件人是否愿意接收邮件，才需要在投递验收中检查。
RackNerd 当前服务条款禁止垃圾邮件，并将常规 VPS 列为非托管服务。系统维护、应用配置、数据备份和软件排障由用户负责。条款也没有承诺付款后无条件退款，购前确认端口比买完再要求解决更稳妥。
内存留出余量，磁盘按邮件保留时间来算
截至 2026 年 9 月核对时，Mail-in-a-Box 官方安装检查仍要求 Ubuntu 22.04。本文采用 Ubuntu 22.04 LTS x86_64 的干净服务器镜像。不要因为控制面板里有更新的 Ubuntu，就把版本换成 24.04；安装脚本会检查发行版。以后重装时，应重新核对项目支持范围。
官方指南的最低内存门槛为 512MB，并推荐 1GB。最低门槛只说明安装要求。邮件过滤、网页邮箱、系统更新和备份会争用内存，所以本文建议个人长期使用从 2GB 起步；多账户、较多附件或同时使用联系人和日历同步时，再考虑 4GB。不能根据内存大小推算“每天能发多少封”，也不应把加内存当成解决拒收的办法。
磁盘值得多算一遍。假设五个账户各保留 3GB 邮件，仅邮箱数据就要 15GB。这还没有算操作系统、索引、日志、临时文件和备份。选购 20GB 磁盘时，不能把整块盘都当作邮箱容量。你可以定期清理大附件，也可以选更大的磁盘，但应提前告诉使用者保留策略。
2026 年 9 月 20 日核对 RackNerd 的 Special Promos 页面时，2GB 内存、35GB SSD 的方案标价为 35.99 美元/年。它只是当时该页面的参考值，不代表所有促销入口、机房和续费订单都使用这个价格。原始材料里的 2.5GB、25.49 美元/年不作为本文的现售承诺。下单前看购物车里的规格、计费周期和续费说明。
再准备一个你能管理 DNS 的域名，以及一处服务器之外的备份存储。域名、VPS 和备份分别续费，任何一个到期都可能影响使用。注册 RackNerd、域名商和备份服务时，保留一个独立的外部邮箱接收通知，避免自建邮箱故障后连客服回信也看不到。
按邮箱容量选择 RackNerd 配置
个人邮箱可从 2GB 内存方案评估。团队使用时，把现有邮件总量和未来一年的附件增长也算进去。
先定主机名，再选择 DNS 管理方式
下面统一使用一组示例值。操作时请替换为你自己的域名和服务器地址；示例 IP 来自文档专用地址段，不能用于实际部署。
| 配置项 | 示例 |
|---|---|
| 邮箱域名 | example.com |
| 邮件服务器主机名 | box.example.com |
| 管理员邮箱 | admin@example.com |
| 服务器 IPv4 | 198.51.100.10 |
邮箱地址与服务器主机名不用相同。你可以用 box.example.com 连接服务器，日常发信仍然使用 hello@example.com。不要把正在托管网站的主域名直接拿来当邮件主机名，否则会把网站访问、证书和邮件配置搅在一起。
Mail-in-a-Box 支持自己管理权威 DNS，也提供 External DNS 所需的记录。对于已有网站的域名，本文采用保留现有 DNS 服务商的路线：不更换域名的 NS，按管理面板列出的要求添加邮件记录。这样可以保留已有网站解析，但以后新增邮件域名或调整配置时，你需要自己同步外部 DNS。
使用全新域名、愿意让 Mail-in-a-Box 接管 DNS 的读者，可以按项目指南在注册商处配置子域名服务器、Glue 和 NS。两种路线选定一种，不要一边把 NS 改到自建服务器，一边继续在原来的 DNS 面板里等待记录生效。修改记录前，用下面的查询确认当前权威 DNS：
dig +short NS example.com
域名已经在使用邮件服务时，先保存现有 MX、SPF、DKIM 和 DMARC。新服务器验收前不要替换 MX。否则部分来信会到新服务器，另一部分仍按缓存里的旧记录投递，账户没建齐就可能退信。
给 Mail-in-a-Box 一台干净的服务器
Mail-in-a-Box 会配置 Web 服务、邮件服务、DNS 组件和防火墙。专门分配一台 VPS，后续排查会省下很多时间。不要把它装进已经运行网站面板、另一套邮局或重要业务的机器，也不要把宿主 VPS 的 KVM 虚拟化与容器安装混为一谈。本文使用完整 VPS，不采用 Docker 容器部署 Mail-in-a-Box。
收到开通信息后，用 SSH 登录。Windows 可以用 Bitvise，也可以使用系统自带的 OpenSSH；macOS 和 Linux 可用终端。下面以交付信息提供 root 账户为例，如果服务商给的是带 sudo 权限的普通账户，就使用那个账户。
ssh -l root 198.51.100.10
首次连接时，SSH 会提示主机指纹。通过服务器控制台等独立渠道核对后再接受。服务器重装后出现指纹变化，应核实重装事实，别养成看到警告就删除记录的习惯。
进入服务器，核对系统版本、架构、内存和磁盘，再更新软件包：
cat /etc/os-release
uname -m
free -h
df -h /
sudo apt update
sudo apt upgrade -y
sudo apt install -y curl ca-certificates dnsutils netcat-openbsd
sudo hostnamectl set-hostname box.example.com
确认版本显示 Ubuntu 22.04，架构为 x86_64。系统更新如果要求重启，先重启并重新连接，再安装邮件系统。日常维护应配置 SSH 密钥；关闭密码登录前，用另一个终端验证密钥确实能登录，并保留控制台恢复入口。
这里的更新操作仅适用于刚准备好的邮件专用服务器。Mail-in-a-Box 安装后，应用升级应遵循项目维护说明，不要擅自更换发行版、PHP 版本或邮件组件。
端口测试要区分入站和出站
在安装前，先从 VPS 测试访问外部邮件服务器的 TCP 25。下面以 Gmail 的一个 MX 主机为例，先查记录，再检查 TCP 连接：
dig +short MX gmail.com
nc -vz -w 10 gmail-smtp-in.l.google.com 25
MX 查询结果与示例不同，就使用查询返回的实际主机。连接成功，只说明这台 VPS 当时能够访问那个目标的 25 端口，没有验证其他收件方，也没有提交邮件。如果超时，检查 VPS 内部防火墙、服务商网络限制和目标状态；不要根据一次失败就断言服务商封端口。
安装结束后，还要从另一台允许 SMTP 出站的外部主机测试连接你的 VPS。只在 VPS 上连接自己的 25 端口，无法验证公网入站。
nc -vz -w 10 198.51.100.10 25
家庭宽带或办公网络也可能限制 SMTP 出站。如果从自己电脑测试失败，换一处你有权限使用的网络再核实。排障时向客服提供测试方向、源地址、目标地址、时间和错误信息，比只说“邮件发不出去”更容易查清。
下表列出部署中常见的连接用途。它不是一份可以盲目套用的防火墙脚本；应以 Mail-in-a-Box 当前状态检查及你启用的功能为准。
| 端口 | 用途与检查重点 |
|---|---|
| TCP 22 或实际 SSH 端口 | 登录维护，调整防火墙时保留管理入口 |
| TCP 25 | 服务器之间收发邮件，同时验证公网入站与出站 |
| TCP 80、443 | Web、管理面板与证书验证，不要忽略证书签发需求 |
| TCP 465 | 客户端提交邮件，使用 SSL/TLS |
| TCP 587 | 客户端提交邮件的另一种方式，使用 STARTTLS |
| TCP 993 | IMAP 收信与同步，使用 SSL/TLS |
| TCP、UDP 53 | 权威 DNS 服务，自建权威 DNS 路线需要公网可达 |
| TCP 4190 | 邮件过滤规则管理，按客户端需求和项目配置检查 |
Mail-in-a-Box 会管理机器上的软件防火墙。RackNerd 控制面板如果另有网络防火墙，也要检查那一层。不要为了通端口直接停掉防火墙；先查服务是否监听，再查规则。
安装时，把邮箱地址与主机名填对
在域名当前使用的 DNS 面板中，为 box.example.com 添加 A 记录，指向 VPS 的 IPv4。使用带网站代理功能的 DNS 服务时，邮件主机名应使用“仅 DNS”模式。常规 HTTP 代理无法代替 SMTP 和 IMAP 连接。
Mail-in-a-Box 官方提供安装脚本。下面将下载与执行分开，便于确认来源并查看内容。
curl --fail --show-error --location \
https://mailinabox.email/setup.sh \
--output mailinabox-setup.sh
less mailinabox-setup.sh
确认下载成功，查看内容与来源后，再单独执行下一条命令。下载失败就停下来处理，不要继续运行一个残缺文件。入口脚本还会取得项目代码，检查这一个文件并不能替代对项目及下载来源的信任。
sudo bash mailinabox-setup.sh
按提示填写管理员邮箱 admin@example.com、邮件服务器主机名 box.example.com，以及时区等配置。不要把管理员邮箱填成主机名，也不要把主机名填成邮箱域名的泛称。提示项目可能随版本变化，以当前安装程序为准，不需要照着旧截图寻找固定的“国家代码”输入框。
给管理员邮箱设置独立的强密码，不要复用 VPS 的登录密码。安装需要下载依赖并配置服务，耗时取决于机器与网络。终端十几分钟没有结束，不足以判断失败；观察输出是在下载、配置还是报错，保留错误上下文，不要中途叠加另一套安装教程。
安装完成后，保存终端给出的管理入口和证书提示。已有安装需要重新运行配置时，项目提供 sudo mailinabox 命令。它不能替代备份，也不意味着可以在未诊断原因时反复执行。
DNS 配齐以后，再检查反向解析
按安装输出登录管理面板，查看 System Status Checks 和 DNS 的 External DNS 页面。不同版本的菜单名称可能有变化，以“状态检查”和“外部 DNS 记录”的功能为准。你需要把面板列出的记录复制到域名当前的权威 DNS 服务商处。
常见配置可以分成下面几类。这里解释用途，不提供一份让所有域名照抄的 TXT 模板。
| 记录 | 用途与常见错误 |
|---|---|
| A、按需配置的 AAAA | 将邮件主机名指向服务器，留意填错 IP 或不可用的 IPv6 |
| MX | 指定接收来信的服务器，目标不能填成 IP、带端口或带路径 |
| SPF TXT | 授权域名的发送系统，同一名称下不能并存多条 SPF |
| DKIM TXT | 供收件方核验签名，检查选择器和公钥是否完整 |
| DMARC TXT | 声明身份对齐要求及处理策略，还要核对可见发件人域名 |
| 其他面板要求的记录 | 支持自动发现、MTA-STS 等功能，不要忽略其余检查项 |
MX 的目标通常是 box.example.com 这样的主机名。不要填写管理面板地址，不要加 /admin，也不要加 :25。DKIM 的选择器与公钥从自己的面板复制；别人的教程即使写了完整公钥，也不能拿来用。
SPF 需要覆盖这个域名实际使用的发信渠道。如果你已经用第三方服务发送订单或通知，直接用新记录替换旧 SPF，可能让那些邮件认证失败。应在同一条 SPF 策略中整理授权来源，并检查查询次数等限制。DMARC 则需要核对可见 From 域名与通过认证的 SPF 或 DKIM 域名是否对齐，不能把几个 pass 当成彼此无关的勾选项。
PTR 反向解析不在普通域名 DNS 面板里设置。IP 地址由服务商分配，应在 RackNerd 提供的 rDNS 功能中设置，或者请客服处理。目标关系是：box.example.com 的 A 记录指向 VPS，而 VPS 的 PTR 指回 box.example.com。部署后用查询检查两边：
dig +short A box.example.com
dig +short -x 198.51.100.10
dig +short MX example.com
dig +short TXT example.com
dig +short TXT _dmarc.example.com
查 DKIM 时，使用面板给出的完整记录名再执行 TXT 查询。dig +short MX 查到一个主机名，只验证了 MX；它不能证明 DKIM、PTR 和证书都已经正确。
IPv6 也要单独验收。没有配置可达的 IPv6 与相应 PTR，就不要先添加 AAAA 记录凑齐表格。即使没有 AAAA，具备 IPv6 的服务器仍可能尝试从 IPv6 出站，因此还要核对实际投递日志和系统检查，按项目支持的配置方式处理，不能只删一条记录就认为问题结束。
DNS 缓存可能保留旧记录。修改后对照权威 DNS 与外部解析结果，确认修改发生在正确的服务商。反复在错误面板里新增记录，等再久也不会生效。
开通前，把端口与 PTR 一起问清楚
向客服说明“自建域名邮箱”，确认 TCP 25 双向连通、PTR 设置方式及所选套餐的系统镜像。不要只问能不能安装软件。
证书正常后，再让客户端保存密码
初次访问管理面板时，服务器可能仍使用自签名证书。不要习惯性忽略浏览器警告。按安装输出，通过已经核验的 SSH 连接比对证书指纹，确认你访问的是自己的机器，再进行首次配置。
DNS 指向正确后，在 TLS Certificates 页面申请或检查可信证书。平时使用带有效证书的邮件主机名访问管理面板，例如代码形式的 https://box.example.com/admin。用裸 IP 访问容易出现证书名称不匹配，不能据此判断证书坏了。
证书申请失败时，检查 A、AAAA、80 与 443 的可达性，以及已有 CAA 策略是否允许签发机构。已有 DNSSEC 的域名还要留意验证是否正常。一次没申请下来，不要靠反复删除配置和重装服务器碰运气。
证书通过后，先建一个测试邮箱，再配置 Thunderbird 或其他支持 IMAP 的客户端。以下是常用设置，最终以管理面板显示的客户端说明为准。
| 项目 | 建议填写 |
|---|---|
| 用户名 | 完整邮箱地址，例如 hello@example.com |
| IMAP 服务器 | box.example.com |
| IMAP 端口与加密 | 993，SSL/TLS |
| SMTP 服务器 | box.example.com |
| SMTP 首选端口与加密 | 465，SSL/TLS |
| SMTP 备用方式 | 587，STARTTLS |
| SMTP 身份验证 | 使用该邮箱的账户与密码 |
465 与 587 的加密方式不能互换。客户端从自动发现中填了错误设置，就改成面板提供的配置。SMTP 提交要认证，不要为了让测试通过而开放匿名外发。
管理面板支持双因素认证，可以在建立恢复方式后启用。日常收发账户与管理权限也应分开，不必让团队每个邮箱都具备管理员权限。管理面板的双因素登录不能代替客户端端口的账户安全。
把一封测试邮件的去向查完整
先从外部邮箱给新账户发信，确认网页邮箱与 IMAP 客户端都能收到，再从新账户回信。换另一个邮箱服务商重复测试，检查发件人名称、回复地址、正文编码和附件。发给同一台服务器上的另一个账户，只验证了本地投递。
使用 Mail-tester 时，先打开它的检测页面，获取当次显示的测试地址，再从新邮箱发送一封正常邮件。不要把 test@mail-tester.com 当作通用测试收件人。内容可以写明这是一封域名邮箱部署测试，使用正常主题和正文，避免只有一张图片或一串链接。
查看报告时，逐项检查发送 IP、PTR、SPF、DKIM、DMARC 和邮件格式。总分适合帮助定位配置问题。即使拿到满分，Gmail、Outlook 或企业网关仍可能把同一封邮件放进垃圾箱，因为它们还会使用各自的信誉与内容判断。
在真实收件箱中打开“显示原始邮件”或相应功能，查收件方写入的 Authentication-Results。对照发送域名和 IP，而不只搜索 pass。转发、邮件列表和网关可能让一封邮件经过多次处理，调试时应先做不经转发的直接收发测试。
服务器上的邮件队列与日志能进一步缩小范围：
sudo postqueue -p
sudo tail -n 100 /var/log/mail.log
找到对应邮件的队列 ID，再沿着同一个 ID 查看投递结果。status=sent 一般表示下一跳接受了这封邮件，不保证最终进入主收件箱；deferred 表示暂时未完成投递，需要结合返回原因判断；bounced 则要看退信中的永久失败信息。不要看到队列积压就批量删除，否则既损失待投邮件，也丢掉排查线索。
分享日志求助前，遮盖邮箱地址、认证信息和私人通信内容，只保留排障需要的字段。服务器日志不适合直接粘贴到公开论坛。
从正常通信开始，不给新 IP 安排虚假的预热任务
个人邮箱如果每天只有几封真实来信，就按这个节奏使用。没有必要为了凑“第一天 20 封、第二天 50 封”而给无关的人发邮件，更不要通过虚假打开、互相群发来制造活跃度。
需要向订阅用户发信时，从明确愿意接收、地址有效的收件人开始，观察退信、投诉和临时拒收，再决定发送频率。没有一张适用于所有 IP 的增长表。收件方开始返回限速信息时，应降低发送频率并调查原因，不能不断重试，或者靠换域名规避限制。
营销邮件还需要处理取消订阅、退信和投诉。面向个人 Gmail 账户的批量发送者有额外的认证和退订要求。Mail-in-a-Box 负责邮箱与邮件服务，不能替你管理订阅授权、名单质量或活动频次。有这些需求时，先把发送流程设计好，再评估是否应该使用单独的邮件发送系统。
不要把“免费”“限时”等词当成投递问题的全部原因。收件人没有订阅、账户遭到盗用、域名认证错误，都可能造成拒收或投诉。改几个词无法补上这些缺口。
正式迁入之前，先完成异地备份
Mail-in-a-Box 提供备份功能，但你仍然要决定备份存在哪里、多久检查一次，以及坏掉以后怎么恢复。备份如果只放在同一台 VPS，服务器或账户出问题时，邮件和备份可能一起失去访问。
在 Backup Status 中设置服务器之外的存储，并把页面要求保存的备份解密密钥另存到安全位置。只有备份文件、没有密钥，同样无法恢复。备份账户也不要与日常邮箱密码共用。
首次备份结束后，在隔离环境里做一次恢复检查：确认能解密、账户与邮件数量符合预期，抽查附件。恢复期间不要把域名 MX 指向测试机，也不要让恢复出来的队列误发旧邮件。保存恢复所需的版本信息与操作记录，换个人接手时才有依据。
迁移已有邮箱时，先建立新账户，迁移历史邮件并核对文件夹、邮件数量和附件，完成新服务器收发验收后再切换 MX。切换前合理降低相关记录的 TTL，并给旧缓存留出过期时间。切换后保留旧服务观察一段时间，检查两边是否仍有新邮件到达，再做最后一次同步。
不要把旧、新两组 MX 长期并列，期待它们自动同步数据。MX 优先级安排的是投递尝试顺序，两套独立邮箱不会因此共享邮件。也不要因为自己测试成功，就提前关闭其他成员仍在使用的旧账户。
维护时按故障发生的位置排查
只能收信，不能向外发送。 先看客户端是否成功提交，再查服务器队列。出站 25 不通、PTR 错误和收件方拒收，需要不同处理。把退信代码与日志时间记录下来，能避免来回修改无关的 DNS。
能发信，却收不到外部邮件。 检查 MX 是否指向正确主机，目标的 A、AAAA 是否可达，以及公网入站 25 是否开放。域名下只建了别名、没建对应账户，也可能影响投递，需对照面板里的实际账户配置。
网页邮箱正常，手机或 Thunderbird 连不上。 核对完整用户名、证书名称和端口加密方式，再看认证失败记录。不要将网页登录密码错误、IMAP 连接错误和外发队列失败当成同一种故障。
邮件进入垃圾箱。 先验证身份记录和 IP 历史，再查看收件方的认证结果与退信信息。只查到一个黑名单结果不能解释所有收件方的处理。换 IP 后也需要重新设置 PTR、核验 DNS 和重新测试，不能保证立刻恢复送达。
系统开始变慢，或者突然停止收信。 检查内存和磁盘，尤其是附件增长、日志与备份占用。磁盘用尽会影响写入和队列。删除文件前确认用途并保留备份，不要直接清空邮箱目录或数据库。
每周查看系统状态、备份是否成功、磁盘增长和异常登录。关注 Mail-in-a-Box 的更新与安全公告，升级前保留可用备份，升级后重新检查收发与证书。对小团队而言，指定一个负责维护的人，比给所有成员发一份安装教程更有用。
这套方案适合把邮箱作为长期服务来维护
选 RackNerd 搭配 Mail-in-a-Box，可以用一台独立 VPS 建立域名邮箱，按自己的需要管理账户和数据。配置阶段，Mail-in-a-Box 帮你组织了多种服务；日常使用中，端口、域名、证书、备份和异常投递仍需要有人照看。
个人站长可以先用一个次要域名或测试邮箱熟悉操作，积累一段真实收发记录，再迁入常用地址。工作室和团队则要提前商量故障联系人、数据保留时间和恢复安排。企业的唯一对外邮箱如果不能接受停机，应在上线前评估人员投入和可用性要求，不要只按年付价格做决定。
购买时把 Ubuntu 镜像、独立 IPv4、TCP 25、PTR 和磁盘容量逐项核对；交付后做收发和恢复测试。这些检查完成了，才适合把新地址放到网站、名片和客户联系资料里。
开始准备你的域名邮箱
选择配置前确认邮件用途与机房条件，安装后完成 DNS、双向收发和异地备份验收，再迁移日常邮箱。