自建邮件服务该不该用:先看它解决的问题是不是你的问题
家宽和多数云主机的 25 端口默认封禁,发信要走 587 中继
它擅长的是自有域名事务邮件;如果你只是多账号统一收件,用现成的东西更省事。
先说结论
自建邮箱技术上不难,难在 IP 信誉;发不出去的时候配置再对也没用
- 适合:自有域名事务邮件
- 不适合:邮件归档与检索
- 学习成本:SPF 记录只允许 10 次 DNS 查询,超过就直接 permerror
- 最大收益:DKIM 用 2048 位密钥时,DNS TXT 要分段,否则超 255 字符被截断
- 最大风险:只配了 A 记录就发信,Gmail 一律进垃圾箱
它到底解决什么
家宽和多数云主机的 25 端口默认封禁,发信要走 587 中继。
换句话说,它把「自有域名事务邮件」这件事从手工变成可重复的流程。这是它真正的价值,而不是功能列表的长度。
什么时候不该用
下面三种情况,用了反而更累:
只配了 A 记录就发信,Gmail 一律进垃圾箱
DMARC 直接设 p=reject,自己域名的转发邮件全被拒
用动态家宽 IP 发信,PTR 改不了,退信率超过三成
和替代方案比
DMARC 从 p=none 开始收报告,直接上 p=reject 会把自己的转发邮件拒掉。
| 方案 | 上手成本 | 适用规模 | 代价 |
|---|---|---|---|
| 自建邮件服务 | 中等 | 中大型 | 需要维护 |
| 用第三方邮件服务 | 低 | 小型 | 定制能力弱 |
| 只收不发的中继 | 低 | 一次性任务 | 不可维护 |

这台工具的关键细节
几个决定长期体验的点:
- SPF 记录只允许 10 次 DNS 查询,超过就直接 permerror
- DKIM 用 2048 位密钥时,DNS TXT 要分段,否则超 255 字符被截断
- 新 IP 没有信誉,日发 200 封就可能被标记,预热通常要 2-4 周
我的建议
自建邮箱技术上不难,难在 IP 信誉;发不出去的时候配置再对也没用。
先用两周,跑一个真实的小任务;两周后你还想用它,再谈长期。
还有几处容易忽略的
都是小地方,但出问题时往往就卡在这里。
- 家宽和多数云主机的 25 端口默认封禁,发信要走 587 中继
- 反向解析 PTR 必须与 HELO 域名一致,否则大厂直接判垃圾
工具是解法,不是身份。
评论 (3)
版本差异要强调,我照着做结果参数名全变了。
最小可用配置这个说法很好,先跑起来再优化。
排查顺序那段直接抄进值班手册了。
发表评论