VPS的25端口被封怎么办：发信方案对比

一、25 端口被封是什么，为什么大部分 VPS 都不开放它

先说清楚一个常见误解：25 端口被封不是因为你的机器有问题，而是因为它被用来发垃圾邮件。25 端口是全球 SMTP 邮件传输的默认端口，早期几乎所有垃圾邮件都从 25 端口直接投递。为了不让自己家的 IP 变成垃圾邮件源，主流云服务商和绝大多数 VPS 商家都默认封禁入站 25 端口。

判断你的端口是什么状态：

# 测试本机 25 端口是否在监听
ss -lntp | grep :25
# 或者
netstat -lntp | grep :25

有输出说明本地 SMTP 服务在跑，但这不代表对外可达。本地监听和外部能连上是两回事——防火墙和商家的网络策略是在外层拦的。

从外部测试连通性（最准的方法）：

telnet mail.yourdomain.com 25

或者：

nc -vz mail.yourdomain.com 25

三种典型结果：

结果	含义	说明
Connection refused	端口可达但服务没开	你的配置问题，改配置就行
Connection timed out	被防火墙丢弃	商家封了 25 端口，或你的防火墙 DROP 了
Connection reset by peer	中间有设备主动切断	典型的服务商策略拦截

查看 iwebfusion 当前月价与库存

商家封 25 端口的三个常见原因（都符合公开的行业惯例）：

第一，防止新开的机器立刻被用于发垃圾邮件。很多 VPS 商家在用户新开实例时就被滥用过，开通即封是最低成本的防护。

第二，IP 段的黑名单机制。很多 IP 段因为历史用户的滥用被整体标记，商家对新分配的 IP 一并封禁。

第三，遵守上游网络提供商的反垃圾邮件规定。这一条对租用美国机房 VPS 的用户特别相关——很多机房的默认政策就是禁止向外发送未经授权的营销邮件，25 端口封禁是这条政策的落地方式。

关键的一点：这个限制通常是可以通过申请解封的，但要看商家的具体政策。申请之前先看三样东西：商家是否提供解封入口、需要什么材料（一般要说明发信用途和域名）、有没有月发信量的上限。把用途写清楚、说清楚是 transactional 邮件而不是营销群发，通过率会高得多。

二、先搞清楚你要发的是哪一类邮件

方案选错的第一大原因，是没分清邮件类型。这两类邮件的技术要求和合规要求完全不同：

类型	特征	举例	技术难点
事务性邮件	触发式、发给明确收件人	注册验证、密码重置、订单通知	送达率、不能进垃圾箱
营销/批量邮件	计划式、群发	促销 Newsletter	声誉管理、退信处理、投诉率

查 racknerd 在售套餐与库存

这两类邮件的发送方式、价格和合规红线都不同。几乎所有发信服务商都会对这两类做区分报价，营销邮件通常需要单独审核，部分服务商直接禁止营销邮件走交易通道。

更细致一点的分类还有第三类：通知类邮件。比如订单状态变更、系统告警。这类邮件的打开率要求高但投诉率低，通常和事务性邮件归为一类。

在做任何技术选型之前，先把这三个问题回答清楚：

- 你的邮件是发给你的注册用户，还是发给陌生名单？

- 每天多少封？峰值多少封？

- 收件人的邮箱服务商是谁？国内用户多还是 Gmail、Outlook 这类海外服务商多？

第三个问题的影响常被低估。Gmail 对发件方的 IP 和域名有明确的信誉要求，而且近年的反垃圾邮件策略越来越严格；QQ 邮箱、163 邮箱对国内 IP 的判定标准又是另一套。同一个发信方案，对 Gmail 的送达率和对 QQ 邮箱的送达率可能差出一倍。

还有一个必须提前确认的合规问题：你有没有域名？有没有配置 DKIM 和 SPF？没有这两项记录，你的邮件在大多数邮箱里都进不了收件箱，直接进垃圾箱或者被拒收。这个准备工作和选哪个服务商无关，必须自己做。

三、方案一：SMTP 中继（最常用，也最适合大多数场景）

SMTP 中继是你把邮件交给第三方服务商，由他们负责实际投递。你只需要在应用里配置发信服务器地址、端口、账号密码，剩下的 DKIM、SPF、DMARC、IP 信誉、投诉率管理全部由服务商负责。

这是绝大多数 VPS 用户的正确选择，理由有三：第一，你不需要等 IP 信誉积累（新 IP 的信誉从零开始，可能要几周甚至几个月才能稳定送达）；第二，你不用处理反垃圾邮件的运维负担；第三，25 端口封禁完全不影响你——中继服务用的是 587 或者 465 端口。

配置示例（以常见的事务性邮件服务接口形式说明）：

# 应用侧的环境变量配置
SMTP_HOST=smtp.yourprovider.com
SMTP_PORT=587
SMTP_USER=apikey
SMTP_PASS=你的密钥
SMTP_TLS=true

用 Postfix 的具体配置：

# /etc/postfix/main.cf 关键项
myhostname = mail.yourdomain.com
mydomain = yourdomain.com
myorigin = $mydomain
smtpd_tls_security_level = encrypt
smtpd_sasl_auth_enable = yes
smtpd_sasl_type = dovecot
smtpd_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtpd_relayhost = [smtp.yourprovider.com]:587

再写一份密码映射文件并设置权限：

echo "smtp.yourprovider.com youruser:yourpassword" > /etc/postfix/sasl_passwd
postmap /etc/postfix/sasl_passwd
chmod 600 /etc/postfix/sasl_passwd

改完重载并测试：

postfix reload
echo "测试邮件内容" | mail -s "测试主题" [email protected]

测试时一定要去垃圾箱里翻一遍，并且查看服务商的投递日志确认状态是 delivered 而不是 deferred。

SMTP 中继的成本结构要看三个维度：

- 按量计费：通常按每千封收费，量大有阶梯折扣

- 月费套餐：固定额度，超出另算，适合稳定发信量

- 免费额度：多数服务商提供每月几百到几千封的免费额度，足够小型项目用

中继方案的关键注意点：

第一，注意 587 和 465 的区别。587 端口是 STARTTLS 模式，先明文连接再升级到加密；465 端口是隐式 TLS，一上来就是加密。大多数服务商的文档会写明用哪个端口，照着填就行，填错的典型表现是连接超时或者认证失败。

第二，认证失败是最常见的报错。看到 535 Authentication failed 或者 535 5.7.8 Error: authentication failed，先检查密码里有没有特殊字符没转义、账号是不是完整的邮箱地址、是不是用了 app 专用密码而不是登录密码。

查 cloudcone 在售套餐与库存

第三，一定要在你的程序里做好失败重试。中继服务的可用性高于自建，但网络抖动仍然存在。发信失败应该进队列重试，而不是直接丢弃——用户点「重发验证码」却收不到，是最伤转化率的事故。

四、方案二：HTTP API 发信服务（开发体验最好）

API 方案是直接调用服务商的 HTTP 接口提交邮件，完全不碰 SMTP 协议。它是现代应用的主流做法，因为省掉了配置和排错的麻烦。

调用示例（结构示意）：

curl -X POST https://api.yourprovider.com/v1/messages \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "from": "[email protected]",
    "to": "[email protected]",
    "subject": "您的验证码",
    "html": "<p>您的验证码是 123456，10 分钟内有效。</p>"
  }'

API 方案相比 SMTP 中继的优势很实在：

第一，不需要在服务器上跑任何邮件服务。不用装 Postfix、不用配 SASL、不用管证书。在容器化环境里这一点尤其有价值——镜像直接就小了，也不用处理邮件队列的持久化。

第二，错误信息更清晰。API 会直接返回结构化的错误码和错误描述，不用去翻 SMTP 的多行响应。排查时间能从几十分钟降到几分钟。

第三，可以精确追踪每一封的状态。API 方案天然给你一个消息 ID，webhook 回调可以告诉你这封是投递成功、被拒收还是进了垃圾箱。这个能力对做送达率统计和优化 DKIM 配置非常关键。

第四，发送不受 25 端口限制。走的是 443 端口，出站基本不会有问题。

API 方案的代价：

- 价格通常比纯 SMTP 中继略贵，因为接口调用本身有成本

- 多了一层依赖，服务商接口挂了你也发不出去

- 功能受限，有些高级功能（比如自定义退信处理逻辑）只能用 SMTP

SMTP 和 API 怎么选？一个简单的判断：如果你的程序已经用了某个语言的发信库且配置简单，用 SMTP；如果你的应用是容器化部署、或者需要精确追踪每封邮件的状态、或者团队里没人熟悉 Postfix，用 API。

API 方案也有必须做对的地方：

第一，API 密钥必须放在环境变量或者密钥管理服务里，绝不能硬编码进代码或提交到 Git。这是最常见的安全事故来源。

第二，做好限流。服务商都有每分钟的调用上限，超了会返回 429 错误。你的代码要能识别 429 并退避重试，而不是直接失败。

digitalocean 官网机型与实时报价

第三，处理不同的错误类型。API 会区分「参数错误」（4xx，重试没用，要改代码）、「限流」（429，退避后重试）、「服务端错误」（5xx，可以重试）。把这三类分开处理，是用好 API 的基本功。

五、方案三：自建邮件服务器（能自控，成本最高）

自建邮件服务器就是在自己的 VPS 上装 Postfix 或 Exim 自己发信。它能给你完全的控制权——发信策略、发信时间、发信量都不受限。但它是四条路线里门槛最高、坑最多的。

先把成本算清楚，这是最容易被低估的部分：

直接成本：服务器本身。一台跑邮件服务器并有独立 IP 的 VPS，通常需要至少 1 GB 内存和 1 个核心——因为反垃圾邮件扫描和 TLS 握手都要吃 CPU。

间接成本一：IP 信誉从零开始积累。这是最耗时间的部分。新 IP 发送的第一批邮件几乎必然进垃圾箱，你需要靠正常投递、逐渐建立信誉、等主要邮箱服务商把你的 IP 加入白名单。这个周期通常是几周到几个月，期间你的验证邮件用户根本收不到。而 IP 信誉一旦被污染（被某个服务商列入黑名单），恢复的周期是另一回事。

间接成本二：DNS 记录必须齐全。至少要有 SPF、DKIM、DMARC 三条，加上反向解析（PTR）记录。任何一项缺失或配置错误，邮件都会被直接拒收而不是进垃圾箱。

间接成本三：反垃圾邮件规则要自己维护。SPF 的 include 机制有 DNS 查询次数限制，超过 10 次会导致 permerror 整条记录失效。这些规则需要持续跟进各家的规范变化。

间接成本四：合规义务不因为你自建而消失。反向滥用投诉、垃圾邮件投诉率、投诉处理流程，这些责任都在你自己身上。

自建方案适合什么情况？只有一个答案：你的发信量足够大且稳定，大到中继服务的月费超过了自建的运维成本，而且你有专门的人来维护它。发信量小的时候，自建一定是亏的——你花几十个小时搭服务器、攒信誉，最后省下的钱还不够付一个月的服务器费。

自建的几个硬性前提，缺一不可：

- IP 必须是独立的，不能和机房其他用户共用——共用 IP 的信誉是共享的，别人发垃圾邮件会连累你

- 必须有反向解析（PTR）记录，而且要指向你的主机名

- 必须配置 SPF、DKIM、DMARC 三条 DNS 记录

- 必须配置退信处理，收到退信要立刻把地址从发送列表里移除，否则退信率飙升会进一步毁掉信誉

自建方案常见的坑：

第一，往返路径不一致导致拒收。发信服务器的 HELO 名、反向解析指向的主机名、DKIM 的 d= 域名三者必须一致。不一致的话，邮件会在接收方那边被直接拒收，日志里显示的是 DNS 错误。

第二，连接到了接收方的 25 端口但对方不回 HELO 响应。有些服务端会先发一段 banner，这段 banner 必须是合法的 SMTP 响应行。配置错误会导致连接挂起直到超时。

查 hostwinds 在售套餐与库存

第三，TLS 证书过期。用 Let's Encrypt 自动续期可以避免，但 renew 钩子必须配置正确，否则续期失败你不会收到任何通知。证书过期后邮件会在接收端直接被拒收，日志里写的是证书错误。

六、方案四：换一台开放 25 端口的 VPS

这条路的技术难度最低——换一台不封 25 端口的机器就行。但它有一个前提必须说清楚：换机器不解决信誉问题。

核心逻辑是这样的：邮件能不能进收件箱，取决于两个独立的因素——能不能连上对方（端口连通性）和对方认不认你（发信方信誉）。25 端口封禁只影响第一个因素。换一台开放 25 端口的新机器，第二个因素依然是零起点，所以你会发现：邮件能发出去了，但照样全进垃圾箱。

这条路的价值在于那些「只需要能发出邮件、送达率要求不高」的场景。典型的例子是：内部系统通知、测试环境的邮件触发、与某个自建系统对接的机器对机器通知。这些邮件的收件人是特定的几个人，他们可以手动把发件人加进白名单。

这条路的成本结构：

- 需要单独买一台开放 25 端口的机器，这是一笔独立支出

- 这台机器的 IP 信誉同样需要积累，成本没有省掉

- 多了一台机器要维护，监控、补丁、安全更新都要跟上

所以这条路的判断标准非常明确：如果你的邮件是营销性质的、需要高送达率，那它一点用都没有；如果是内部通知性质、收件人固定且可以手动加白名单，那它是最省事的选择。

还有一个必须注意的点：即便端口开放了，你的 VPS 所在的机房政策可能仍然禁止发营销邮件。这是机房层面的规定，和端口开不开无关。在动手之前先确认机房的发信政策，否则可能因为违反政策被暂停服务，那比端口被封更麻烦。

查看 interserver 当前月价与库存

折中做法：主业务用中继或 API，同时保留一台开放端口的机器作为备用。平时不发，触发需要直连的时候再用。这样既避免了日常维护成本，又保留了应急能力。

七、算账：四条路线各花多少钱

把四条路线的成本结构摆在一起，结论其实很清楚：

路线	固定月成本	变动成本	首次投入	送达率起点
SMTP 中继	0	按千封计费	1 小时配置	服务商已有信誉，高
HTTP API	0	按封计费，略贵	2 小时集成	服务商已有信誉，高
自建邮件服务器	至少 1 台机器	0	数天搭建加数周攒信誉	零起步，需长期积累
换开放 25 端口的机器	1 台机器	0	迁移加数周攒信誉	零起步，需长期积累

查看 itldc 当前月价与库存

真实在售机型的成本可以对照看。按月付费的机型：

机型	月费	内存	系统盘	月流量	内存单价	磁盘单价	流量单价
RosCloud-01	19.99 美元	1 GB	20 GB	1024 GB	19.99 美元/GB	0.999 美元/GB	19.99 美元/TB
RosCloud-02	29.99 美元	2 GB	40 GB	2048 GB	14.99 美元/GB	0.75 美元/GB	14.995 美元/TB
RosCloud-03	39.99 美元	4 GB	80 GB	3072 GB	10.00 美元/GB	0.5 美元/GB	13.33 美元/TB
RosCloud-04	49.99 美元	8 GB	160 GB	4096 GB	6.25 美元/GB	0.312 美元/GB	12.498 美元/TB

如果你因为自建发信要额外买一台机器，最低档的 19.99 美元/月的 RosCloud-01 就是你的额外支出。这个数字可以拿来做决策基准：自建方案省下的中继费用必须超过 19.99 美元/月，这笔账才算划算。

年付线的对应数据：

机型	年费	折合月费	内存	系统盘	月流量	内存单价	磁盘单价	流量单价
LAX-STARTER	200 美元	16.67 美元	2 GB	40 GB	5000 GB	8.33 美元/GB	0.417 美元/GB	3.413 美元/TB
LAX-MICRO	400 美元	33.33 美元	4 GB	80 GB	10000 GB	8.33 美元/GB	0.417 美元/GB	3.413 美元/TB
LAX-MEDIUM	800 美元	66.67 美元	8 GB	160 GB	20000 GB	8.33 美元/GB	0.417 美元/GB	3.413 美元/TB

做发信服务器的一个额外考量：流量成本几乎可以忽略。一封邮件的正文加上协议开销通常只有几 KB，即使一天发十万封，一个月也才用掉几十 GB 流量，在 5000 GB 到 20000 GB 的月流量额度里占比很小。所以选型时不要把流量当成约束条件，内存和 CPU 才是。

算账的结论：除非你的月发信量已经大到中继月费超过 20 美元并且持续稳定，否则中继或 API 方案都是更划算的选择。这条线以下，省下来的运维时间远比省下的钱值钱。

八、怎么提高送达率：四个必须做对的地方

不管你选哪条路线，这四件事都绕不过去。它们是送达率的真正决定因素，比你选哪家服务商重要得多。

第一，配置 SPF、DKIM、DMARC 三条 DNS 记录。

SPF 声明哪些服务器可以用你的域名发信：

v=spf1 include:yourprovider.com -all

末尾的 -all 表示「除了上面列的，其他一律不认」，这是最严格也最推荐的做法。如果你的域名还有别的邮件来源，用 ~all 软失败过渡，等确认没有遗漏再改成 -all。

DKIM 记录由你的发信服务提供，一般是一长串公钥。关键是确保签名用的域名和发件人地址的域名完全一致。

DMARC 记录告诉接收方遇到验证失败的邮件怎么处理：

v=DMARC1; p=none; rua=mailto:[email protected]

先用 p=none 观察一两周，确认没有遗漏的发信来源再改成 p=quarantine 或 p=reject。

第二，发信域名的选择。不要用免费邮箱服务商的域名发信，也不要用和新域名同 IP 的其他域名。用你自己控制的独立域名，这是信誉的基础。子域名也可以，比如 mail.yourdomain.com 或者 notify.yourdomain.com，用子域名的好处是万一某个子域名的信誉坏了，不会影响主域名。

第三，控制发信节奏。新域名或新 IP 刚开始发信时，从小量开始，逐步递增。常见的错误是一上线就给几万个用户群发，结果第一波就被判定为垃圾邮件，后面所有邮件都受影响。稳妥的做法是：先给活跃用户发，逐步扩大到沉睡用户，再扩大到全部用户。

第四，管理退信和投诉。收到硬退信（地址不存在）要立刻把地址从发送列表移除；收到软退信（临时失败）要重试，但要有次数上限；收到投诉要立刻停止发信。退信率是各家服务商和邮箱服务商共同盯的核心指标，超过一定阈值你的发信权限会被限制甚至暂停。

查 spinservers 在售套餐与库存

还有一个常被忽略的动作：监控送达率。用 API 方案的 webhook 或者 SMTP 中继的投递日志，把投递成功、被拒收、进垃圾箱三种状态分开统计。只看「发送成功」是不够的，那只说明邮件交出去了，不代表用户看到了。

九、完整操作流程：从申请到送达

第一步，确认要发什么邮件、发给谁。把第二节的三个问题写下来。

第二步，准备域名记录。在域名 DNS 里加 SPF、DKIM、DMARC 三条。DKIM 记录要先从发信服务商拿到。

第三步，选服务商并申请额度。如果打算自建或者用独立机器发信，先问商家能不能解封 25 端口：

- 问法要具体：「申请解封 25 端口，用于发送事务性邮件，日均 X 封，发件域名是 yourdomain.com」

- 附上用途说明和域名，能显著提高通过率

- 问清楚解封需要多久、有没有发信量上限、违反会怎样

第四步，做一个端到端测试。发一封测试邮件到 Gmail、QQ 邮箱、Outlook 各一个，确认三处都收到，并且不在垃圾箱里。

第五步，检查 DNS 配置是否生效。

dig +short TXT yourdomain.com
dig +short TXT _dmarc.yourdomain.com

用 +short 可以直接看到记录值，比看完整输出清楚。还要确认 DKIM 的选择器记录也在。

第六步，配好应用的失败重试。这是最容易被忽略但影响最大的一步。发信失败必须进队列重试，并且要有最大重试次数和退避间隔。

第七步，打开监控。至少监控三个指标：发送成功率、退信率、投诉率。这三个数字异常，说明 DNS 配置或者发信行为出了问题。

zenlayer 官网机型与实时报价

第八步（可选但推荐）：发一封测试邮件到你的 Gmail，然后看原始邮件头。在 Gmail 里点「显示原始邮件」，找到 Received: 那一串，能看到邮件经过了哪些服务器、每一跳的延迟和 SPF/DKIM 的判定结果。这是判断问题出在哪一环最直接的方法。

按你的情况，下一步该看哪家

上面讲的是判断标准，但多数人最后还是想问一句「那我该买谁」。按你的实际情况对照下面几条，直接去看对应的机型页比继续比价更快：

• 主要访客在国内、在意打开速度：先确认回程线路，再谈配置。看 iwebfusion 当前机型与价格
• 只是开发测试、临时用：按小时或月付，用完就删，别买年付。看 racknerd 当前机型与价格

价格与库存以商家页面当日显示为准，下单前建议先确认退款窗口与是否支持按月付费。

十、常见问题

Q：VPS 的 25 端口怎么申请解封？流程一般是：登录商家控制台找到端口或邮件相关的设置项，或者直接开工单。工单里要写清楚发件域名、预估日均发信量、邮件类型（注册验证、营销通知等）、以及这些是发给谁收件人的。强调是发给已有用户的通知类邮件、通过订阅获得收件人地址、不购买名单，能明显提高通过率。部分商家要求先购买满一定时长才受理，也有部分商家完全不开放。

Q：为什么我的邮件发出去了但对方说没收到？按这个顺序排查：第一，看服务商后台的投递日志，状态是 delivered 说明对方服务器收下了，问题在进垃圾箱或者被服务商二次拦截；状态是 deferred 说明还在重试，常见于对方临时拒收；状态是 bounced 说明被拒收，日志里会写原因。第二，如果状态是 delivered 但用户没看到，检查垃圾箱和订阅者文件夹。第三，确认域名配置完整，用 dig +short TXT 逐条核对。

Q：用 Gmail 发信行不行？技术上可以，但只适合个人和小规模内部使用。Gmail 的发信配额有限（每天几百封），超过会被限制甚至封号。更重要的是 Gmail 的策略明确禁止用它做群发或商业批量发送。正式业务应该用专门的服务商，这是没有例外的一条。

Q：DKIM 记录一定要配吗？一定要。没有 DKIM 的话，你的邮件在接收方那里没有任何身份验证依据，只能靠 IP 信誉和 SPF 判定送达。新 IP 没有信誉，SPF 又只能说明「这个 IP 可以代表你发信」而不能保证内容不是垃圾——没有 DKIM 的话，你的邮件基本是必进垃圾箱的。配置成本是二十分钟，没有理由不配。

Q：发信被退信了怎么办？分两种处理。硬退信（5.x.x 里带 does not exist 之类的）说明地址无效，立刻从发送列表移除。软退信（4.x.x）说明是临时问题，按退信时间重试，但同一个地址重试超过三到五次仍然失败就要停。关键是要有自动退信处理机制——手工处理几千个地址不现实。

Q：怎么知道我的发信 IP 被拉黑了？几个信号：突然大面积进垃圾箱、投递日志里大量出现 550 或 554 开头的拒收码、原本正常的投递开始大面积 deferred。确认办法是查主要的黑名单服务，比如 Spamhaus，用 dig +short 你的IP.zen.spamhaus.org 看有没有返回记录。被列入黑名单要尽快找出原因并申诉，多数黑名单都有申诉通道。

Q：营销邮件和事务性邮件能用同一个账号发吗？技术上可以，但强烈建议分开。原因有三：第一，很多服务商明确要求分类，混发可能触发风控；第二，两者的投诉率容忍度完全不同，营销邮件的投诉率高了会影响你整个账户的发信额度；第三，事务性邮件的送达率要求更严，用营销账号发注册验证码，用户收不到验证码的代价远大于营销邮件进垃圾箱。用同一服务商但开两个子账号或两套 API 密钥，是比较经济的做法。

Q：发信方案迁移容易吗？从 SMTP 中继迁到 API 中等，从自建迁到中继最容易。真正难迁的是从自建迁出——你要重新配置 DNS 记录（DKIM 的密钥变了，SPF 可能要改），还要等新域名的信誉积累。所以如果一开始就用中继方案，以后想换服务商或者换 API，代价都很小——这本身就是选型时要考虑的因素。

Q：VPS 用来发信，IP 会不会被牵连到我的网站？同一个 IP 上既有网站服务又有邮件服务，确实存在连带风险。如果邮件服务因为垃圾邮件投诉被列入黑名单，有些邮箱服务商的反垃圾邮件系统会连带降低该 IP 的信誉评分，间接影响同 IP 发出的邮件。务实的做法是：如果一定要自建发信，用独立 IP 并让网站走 CDN；如果用中继或 API，你的 VPS 根本不碰发信，压根不存在这个风险。

Q：怎么估算每月该花多少钱？先测出日均发信量，乘以 30 得到月发信量，再按服务商的价格表算。注意区分事务性和营销邮件的计费——多数服务商对事务性邮件单价低、对营销邮件单价高，或者干脆要求营销邮件单独申请。另外要留意免费额度的规则，比如某些服务商按域名而不是按账户计算免费额度。