ZoneMTA 邮件路由指南用 X-Sending-Zone 头与域名规则精准分流【免费下载链接】zone-mta Modern outbound MTA cross platform and extendable server application项目地址: https://gitcode.com/gh_mirrors/zo/zone-mtaZoneMTA 是一款开源、跨平台、可扩展的现代出站邮件传输代理Outbound MTA而邮件路由正是它最实用的能力之一。借助X-Sending-Zone请求头和域名规则你可以把不同类型的邮件精准分流到不同的发送区域Sending Zone每个区域拥有独立的 IP 池、并发连接数和限流策略让同一台服务器发出多种邮件变得井井有条。本文面向新手用最简的方式带你理解这套路由机制并快速上手。先理解 Sending Zone邮件路由的基本单元在 ZoneMTA 中每个Sending Zone发送区域都是一套独立的发信配置你可以把它想象成发信通道。每个 Zone 可以单独设置pool出站 IP 地址池可绑定多个 IP 并按比例分配负载processes/connections投递进程数与并行连接数throttling限流策略如每分钟最多 N 封senderDomains/recipientDomains域名规则routingHeaders自定义请求头规则originAddresses来源 IP 规则Zone 的定义位于配置文件 config/default.js 的zones节点下核心实现可以看 lib/sending-zone.js。有了多个 Zone邮件路由就能把邮件对号入座。用 X-Sending-Zone 头手动指定发送区域最直接的路由方式就是让投递方在邮件中携带X-Sending-Zone请求头直接指定要走哪个 ZoneX-Sending-Zone: marketing只要配置里存在名为marketing的 Zone这封邮件就会被送进该 Zone 对应的 IP 池和队列。该头由 plugins/core/default-headers.js 在入队阶段解析并且会在投递前被移除不会泄露给收件方非常安全。需要注意的是出于安全考虑默认只有apiHTTP 接口和bounce退信这两个来源允许使用路由头对应配置项是allowRoutingHeaders。如果你希望通过 SMTP 提交时也生效可以在插件配置里显式放开。基于域名规则自动分流不想手动加头ZoneMTA 还支持按域名自动分流适合发件域多、收件域杂的场景。按发件人域名分流senderDomains把某个 From 域名整体划入指定 Zonemarketing: { senderDomains: [newsletter.example.com], pool: marketing-pool }凡是从newsletter.example.com发出的邮件都会自动走marketing通道。配置会通过punycode做国际化域名转换匹配时自动忽略大小写。按收件人域名分流recipientDomains按收件方域名决定出口常用于重点客户走优质 IP、普通客户走共享 IPpriority: { recipientDomains: [bigcorp.com, kreata.ee], connections: 3 }这样发往bigcorp.com的邮件会使用priority区域享受独立的连接与 IP 资源。两种域名规则的定义与匹配逻辑可参考 lib/sending-zone.js。按自定义请求头值路由routingHeaders如果你的业务系统在邮件里放了业务标识如用户 ID、订单类型可以用routingHeaders做更精细的值匹配分流vip: { routingHeaders: { x-user-id: 123 } }只要邮件包含X-User-ID: 123这个请求头就会被路由到vipZone。值匹配不区分大小写适合在 API 发信场景中按业务维度分流。按来源 IP 路由originAddresses多台应用服务器共用一个 ZoneMTA 时还可以按提交邮件的来源 IP 分流在 Zone 配置里列出originAddresses来自这些 IP 的邮件会自动归入对应区域实现在线web与交易transaction流量的物理隔离。邮件路由优先级一封邮件如何找到归属当多种规则同时存在时ZoneMTA 按以下优先级依次匹配详见 lib/mail-queue.js优先级匹配规则配置项1X-Sending-Zone请求头邮件头2自定义请求头值routingHeaders3发件人域名senderDomains4收件人域名recipientDomains5来源 IPoriginAddresses6兜底defaultZone默认default一旦命中高优先级规则就不再继续匹配。全部未命中时邮件会落入queue.defaultZone指定的默认 Zoneconfig/default.js。官方文档对优先级的说明见 README.md。一个完整的邮件路由配置示例把上面几种方式组合起来就是一个典型的多渠道发信配置zones: { default: { pool: default, connections: 5 }, marketing: { senderDomains: [news.example.com], routingHeaders: { x-campaign: summer }, pool: marketing-pool, throttling: 500/hour }, priority: { recipientDomains: [gmail.com, bigcorp.com], connections: 2, pool: priority-pool }, bounces: { pool: default, connections: 1 } }配合邮件路由你还可以为每个 Zone 单独开启 DKIM 签名plugins/core/dkim.js和退信处理让每条通道的行为完全独立可预期。常见问题与排查建议Zone 没生效先确认 Zone 名称全小写且没有拼写错误路由匹配对大小写不敏感但配置中的域名建议统一小写。请求头被忽略检查接口是否在allowRoutingHeaders白名单内默认仅api、bounce。想确认走了哪个 Zone开启队列日志log.queue: true日志里会出现 Detected Zone xxx ... by sender/recipient/headers 之类的记录一眼就能看出命中规则。未匹配的邮件去哪了所有规则落空时走defaultZone请确保默认 Zone 存在且未被禁用。掌握 ZoneMTA 的邮件路由就等于掌握了出站流量的指挥权。从X-Sending-Zone头到域名规则从优先级到 IP 池这套机制能让你的邮件系统在增长中始终保持可控、可观测、可扩展。【免费下载链接】zone-mta Modern outbound MTA cross platform and extendable server application项目地址: https://gitcode.com/gh_mirrors/zo/zone-mta创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考