简介：这是一套基于 VB.NET 与 SMTP 协议的邮件群发源码项目，面向需要批量发送通知、营销邮件的开发者，也适合初学者学习 System.Net.Mail 中 SmtpClient、MailMessage 的使用，以及附件处理、SMTP 服务器配置等关键环节。压缩包体积约 646KB，共 128 个文件，核心文件包括 15 个 vb 源码文件、11 个 exe 可执行程序、9 个 dll 动态库，以及 sln/vbproj 工程文件、xml 配置、manifest 部署清单和 pdb 调试符号；另有 doc 使用说明、txt 文档与测试文件，便于理解整套发送流程。项目还包含测试案例、DLL 源码说明与部署相关文件，从编写代码、调试到生成可执行程序都有覆盖；对想要快速搭建群发功能或研究 VB.NET 网络编程的开发者，是一份可直接参考和复用的轻量示例。若需理解邮件发送与 SMTP 认证流程，可参考源码注释与配套说明文档。已有 422 人学习浏览，适合用于教学演示、内部通知系统或作为二次开发基础。
1. 邮件群发源码：不是搭个发信工具那么简单
很多人第一次搜“邮件群发源码”，以为拿到手就能批量发信、坐等转化率起飞。实际跑过一轮就会发现：源码只是最外层的壳，真正决定能不能发出去、进不进垃圾箱的，是发信协议选型、连接池设计、退订链路的完整度，还有你压根没想到的 SPF/DKIM 签名配置。这套东西做不扎实，代码写得再漂亮，结果也是被收件方服务器一串数字拒之门外。
这篇文章按我自己的落地路径来拆：先讲清楚邮件群发源码背后必须理解的协议和组件，再给一套能在本地跑通的最小实现，然后逐步加上模板、附件、退订和频控，最后把最容易翻车的几个坑按“现象 → 原因 → 解决”列出来。适合那种不想只跑通 demo、而是真要拿它做通知下发或营销触达的开发者——尤其是用 Python 技术栈、打算自己维护发信链路的团队。
2. 邮件群发源码的核心逻辑：从发信协议到限流参数
2.1 为什么 SMTP 是绕不开的底层协议
邮件群发源码不管外层换了多少种封装，最终都是通过 SMTP(Simple Mail Transfer Protocol) 把邮件交给收件方的邮件服务器。市面上常见的实现方式有两种：直接连收件方域名的 MX 记录发信（直投），或者通过一个中间 SMTP 中继发信（relay）。直投的好处是不依赖第三方服务，缺点是很容易被对方反垃圾策略拦截，而且一旦 IP 信誉度低，基本就是秒进垃圾箱。中继方式则是把邮件交给某个邮件服务商的服务器，由它去投递，送达率相对稳定，代价是你要有中继服务的账号和凭证。
我一般会建议业务量小的项目直接用中继，原因很简单：邮件群发是否成功，很大程度不取决于你发信端写得怎么样，而取决于目标服务器认不认你的来源。通过有信誉的中继发送，相当于租了一条已经被对方信任的“通道”。源码层面无非就是把收件人逐封交给中继服务器，真正需要操心的反而是发信频率和内容合规性。
SMTP 协议本身封装的难点在于会话处理。一次标准的 SMTP 发送要走完“握手→认证→指定发件人→指定收件人→传输正文→退出”这六个阶段，任何一步失败都需要明确的重试策略。代码里的 session 管理、超时控制、异常捕获，全都是围绕这六个阶段展开的。
2.2 邮件群发源码的常见组件拆解
一套相对完整的邮件群发源码，至少应该由五个模块组成：发信引擎（负责连接 SMTP 服务器并发送）、队列管理（负责存储待发任务、记录发送状态）、模板引擎（负责渲染邮件正文，尤其是 HTML 模板）、收件人管理（负责名单清洗、去重）、退订处理（负责处理用户取消订阅的请求）。很多开源源码只实现了发信引擎那一层，队列和退订往往是缺失的，但这恰恰是邮件群发能否长期稳定跑下去的关键。
拿队列管理举例：如果你一次性加载 10 万封收件人列表到内存里循环发送，不仅内存吃紧，而且一旦进程中断，已经发过的和还没发的就完全分不清了。常见做法是把任务持久化到表里，每一封邮件都是一个 task 记录，状态分为 pending、sent、failed、bounced。发送进程只负责从 pending 里拉数据，发完更新状态。这样就算进程崩溃，重启之后也能从断点继续。
模板引擎的选择上，Python 生态里最常用的就是 Jinja2。它天然支持变量插值、条件判断、循环，足够渲染一封带用户名的个性化邮件。要注意的是邮件 HTML 的兼容性和网页不太一样：很多邮件客户端不支持 JavaScript，也不支持外部 CSS 干脆用表格布局加内联样式，模板写得太花哨，反而容易触发垃圾邮件过滤。
2.3 如何选型：标准库还是第三方库
Python 标准库里的 smtplib 和 email.mime 组合，是邮件群发源码最底层、最可控的选型。它支持 SSL 和 STARTTLS，也能构造 multipart 消息体，没有任何外部依赖。缺点是代码量偏大，需要自己处理连接复用、重试、超时等问题，对新手不太友好。
第三方库层面，比较常见的有两档：yagmail 属于轻量封装，适合小批量、人肉发信的脚本，但对大批量场景缺乏连接优化的支持；另一档是 Celery 加 smtplib 组合，把发信任务交给分布式队列执行，适合消息量大、需要横向扩展的场景。选型时的核心判断标准是：你的瓶颈在代码效率还是在送达率？如果是送达率，换什么库都解决不了，得从发送方式和正文质量下手。
我自己做过一次对比测试：同样 1 万封邮件，用 yagmail 循环发送耗时接近 40 分钟，瓶颈在于它每封邮件都重新建立一次 SMTP 连接；而用 smtplib 做连接复用，1 万封压到 8 分钟左右（在批量收件方没有限制的前提下）。所以如果邮件数量上了规模，连接复用是必须做的基础优化。
3. 用 smtplib 在本地跑通第一封群发邮件：最小源码与参数拆解
3.1 最小可运行源码：从配置到发送一次完整流程
下面这组代码是我平时用来验证 SMTP 连通性的最小脚本，也是邮件群发源码的雏形：单发一封带有 HTML 正文的邮件。先跑通它，再往里面加批量循环和队列逻辑。代码里我刻意把配置独立成变量，方便你直接换成自己的中继服务器参数。
import smtplib from email.mime.text import MIMEText from email.mime.multipart import MIMEMultipart from email.header import Header from email.utils import formataddr SMTP_HOST = "smtp.example-relay.com" # 你的中继服务器地址 SMTP_PORT = 587 # 587 是 STARTTLS 端口，465 是 SSL 端口 SMTP_USER = "notification@yourdomain.com" # 发件账号 SMTP_PASS = "your-password" # 发件账号的授权码或密码 FROM_ADDR = SMTP_USER TO_ADDR = "receiver@example.com" SUBJECT = "这是一封测试邮件" HTML_BODY = "<h2>Hello</h2><p>这是一封通过 smtplib 发送的测试邮件。</p>" def build_message(from_addr, to_addr, subject, html_body): msg = MIMEMultipart("alternative") msg["From"] = formataddr((str(Header("通知中心", "utf-8")), from_addr)) msg["To"] = to_addr msg["Subject"] = Header(subject, "utf-8") part = MIMEText(html_body, "html", "utf-8") msg.attach(part) return msg def send_one(content): msg = build_message(FROM_ADDR, TO_ADDR, SUBJECT, content) with smtplib.SMTP(SMTP_HOST, SMTP_PORT, timeout=10) as server: server.ehlo() server.starttls() # 启用 STARTTLS 加密 server.ehlo() # 加密后重新握手 server.login(SMTP_USER, SMTP_PASS) server.sendmail(FROM_ADDR, [TO_ADDR], msg.as_string()) print("smtp send ok") if __name__ == "__main__": send_one(HTML_BODY)这段代码的逻辑是先用 MIMEMultipart 构造一封支持纯文本和 HTML 双版本的邮件，然后通过 with 语句进入 SMTP 会话。with 语法保证了连接不管成功还是异常最终都会被关闭，不会留下悬挂连接占用系统句柄。sendmail 的第二个参数必须是列表，因为 SMTP 协议本身支持一封邮件同时发给多个收件人，但这里我们只传一个，方便控制发送状态。
参数说明方面有四个点要注意：第一，SMTP_PORT 选 587 就配 starttls()，选 465 就要用 smtplib.SMTP_SSL 而不是 SMTP，两者不能混用，否则会在握手阶段报错。第二，timeout=10 是连接超时，批量发送时建议调到 20 以上，避免网络抖动直接触发超时。第三，Header 对中文主题做编码，如果不加，sendmail 时会因为非 ASCII 字符报错。第四，sendmail 和 login 是两个独立步骤，login 失败时服务器会返回 535 错误，需要检查账号密码和授权码状态。
3.2 批量发送时不能直接 for 循环的三个原因
很多人在跑通单封邮件后，顺手就把发送代码塞进了一个 for 循环里遍历收件人列表。小规模测试没问题，但一旦收件人数上千，这做法会引出三个连锁问题：邮件发着发着连接被服务器断开、发信频率被判定为异常、失败后无法定位是哪个收件人出了问题。
第一个问题的机制是：SMTP 服务器通常设置了单连接发送上限，比如 100 封或 300 封，超过之后必须重新握手建立新连接。for 循环不加处理，连接被断开后没有重连逻辑，后续邮件全部抛异常。第二个问题是频率问题：同一连接快速发送大量邮件，会触发收件方服务器的速率限制，常见响应码是 421 或 450，这种限流和内容无关，纯粹是收发节奏问题。第三个问题是可观测性问题：如果某一封发送失败导致整个循环中断，前面发成功的那些没有记录，后面没发的也找不到断点，等于作业白跑。
我建议的批量结构是：外层循环负责读取任务，内层做一个连接池，每发 N 封（比如 50 封）主动重连一次，同时捕获每一次 sendmail 的异常并更新任务状态。伪代码思路是这样的：
from itertools import islice def batch_send(tasks, batch_size=50, max_retry=3): # 每个 batch 用一个新的连接，避免触发单连接上限 for batch in iter(lambda: list(islice(tasks, batch_size)), []): with smtplib.SMTP(SMTP_HOST, SMTP_PORT, timeout=20) as server: server.ehlo() server.starttls() server.ehlo() server.login(SMTP_USER, SMTP_PASS) for task in batch: for attempt in range(max_retry): try: server.sendmail(FROM_ADDR, [task["to"]], build_message(...).as_string()) mark_sent(task["id"]) break except smtplib.SMTPException as e: if attempt == max_retry - 1: mark_failed(task["id"], str(e))这里最关键的设计是先按批次取数据，而不是一次性把所有收件人加载进内存。islice 这种懒加载方式能保证十万级收件人列表下内存占用稳定。batch_size 参数需要根据 SMTP 服务器限制动态调整，一般是取服务器允许单连接发送上限的一半，留有余量。重试三层是指：每封邮件内部重试三次，三次之间不需要 sleep，因为 SMTP 连接异常通常很快；但如果是服务器返回 450 这种临时性错误码，重试前必须 sleep 一段时间（比如 30 秒以上），否则一定会再失败。
3.3 本地测试时的关键配置：发件域名、端口、认证方式对照表
本地跑通邮件群发源码之前，建议先确认目标 SMTP 服务器的认证方式。不同的邮件服务商对 SMTP 认证的支持有差异，常见的认证机制是 LOGIN 和 PLAIN。smtplib 的 login 方法会自动协商，但有些服务商必须在连接后显式声明认证方式，否则会报“auth method not supported”。
端口方面做一个简单对照：465 端口对应 SMTPS，从连接一开始就是 SSL 加密，代码里要用 smtplib.SMTP_SSL 建立连接；587 端口对应 STARTTLS，先明文连接，再通过 starttls() 升级为加密通道；25 端口通常是 MTA 之间的通信端口，大部分邮件服务商不开放给终端用户使用，本地测试别用 25。发件域名要和 SMTP 账号所在域名保持一致，否则收件方服务器会校验发件人域名和认证域名不一致，直接拒绝。
# 465 端口的连接方式示例 import smtplib server = smtplib.SMTP_SSL(SMTP_HOST, SMTP_PORT, timeout=20) server.login(SMTP_USER, SMTP_PASS)这段和 587 端口的主要区别是不调 starttls，因为连接建立时隧道已经加密。还有一种小众情况是服务器支持 SMTPUTF8 扩展，用于发件地址或收件地址中包含非 ASCII 字符的场景，这个不在大多数国内业务范围内，了解即可。
认证配置这块还有一个常见的坑：很多服务商的“邮箱密码”和“SMTP 授权码”是分开的。代码里填 SMTP_PASS 的地方必须用授权码，而不是登录网页版邮箱的密码。用错之后服务商返回的报错是 535 Authentication Failed，但你去检查邮箱密码却又是对的。这个坑我见很多人踩过，建议直接把你用的授权码存到环境变量或密钥管理服务里，不要硬编码在源码里。
4. 从源码到可用系统：模板、附件、退订与发送频控
4.1 用 Jinja2 渲染个性化邮件正文：变量替换与 HTML 兼容性
邮件群发如果只是每封发送完全相同的内容，那用简单字符串拼接就够了。但实际场景里，收件人姓名、订单号、优惠链接这些变量几乎必然出现。用字符串拼接维护用户名的不同称呼（比如“先生”“女士”），代码会很快变成一坨不可维护的 if-else。这种场景下用 Jinja2 模板引擎是行业内的标准做法。
模板文件单独放在 templates 目录下，正文的长相和代码逻辑完全分离。发信代码加载模板后，通过 render 方法传入用户字段字典，得到最终 HTML 字符串。下面是模板渲染的最小示例：
from jinja2 import Environment, FileSystemLoader env = Environment(loader=FileSystemLoader("templates")) template = env.get_template("welcome.html") html_content = template.render( user_name="张三", gift_code="SUM2024001", expire_days=3 )这段代码的核心优势在于模板文件里可以这样写：问候语里嵌入 user_name，优惠说明里引用 gift_code 和 expire_days。render 时缺失任何变量都会抛异常，这在批量发送前是一个很好的自检机制，能提前发现模板字段和收件人数据字段不一致的问题。
不过，Jinja2 默认的变量语法对邮件场景有一个小陷阱：如果模板里有 JSON 风格的代码块（比如{{"key": "value"}}），Jinja2 会把它当成变量输出表达式去解析，导致模板语法错误。解决办法是减少模板里不必要的花括号，或者用{% raw %}标签包住 JSON 片段。另一个值得注意的是邮件 HTML 的兼容性：Gmail、网易邮箱对 CSS 的支持各不相同，外部样式表基本不可用，必须用内联 style 属性写样式。建议做一套 Table 布局的模板，而不是用 Flex 或 Grid，否则部分邮箱客户端里排版会完全错乱。
4.2 附件发送：MIME 类型与文件名编码的边界问题
MIMEMultipart 可以同时携带正文和附件，这是邮件群发源码里相对容易出错的部分。附件的 MIME 类型如果标错，收件方可能直接屏蔽或者附件无法在线预览。常见的对应关系是：PDF 对应 application/pdf，Excel 对应 application/vnd.openxmlformats-officedocument.spreadsheetml.sheet，纯文本对应 text/plain。另外，文件名如果不是纯 ASCII，直接用 add_header 设置 Content-Disposition 会导致文件名乱码，必须经过 RFC 2231 编码。
from email.mime.application import MIMEApplication from email.utils import encode_rfc2231 import os def attach_file(msg, file_path): with open(file_path, "rb") as f: part = MIMEApplication(f.read()) filename = os.path.basename(file_path) part.add_header("Content-Disposition", "attachment", filename=encode_rfc2231(filename)) msg.attach(part) return msg逻辑说明：MIMEApplication 以二进制方式读取文件，不经过 base64 编码，而是由 email 库在生成消息字符串时自动做 base64 编码。手动加 Content-Disposition 头时用 encode_rfc2231 处理非 ASCII 文件名，这样才能在 Outlook、Gmail 里看到正常的文件名。如果不处理，中文文件名会变成一长串百分号编码，用户体验很差。
还有一个边界问题：邮件群发源码里如果附带的是动态生成的报表，每个收件人看到的附件内容不同，建议在生成附件后直接写入临时目录，发送完成后用 os.remove 清理。如果附件很大（超过 10MB），多数邮件服务商会拒收或强制转成超大邮件超时。瓶颈不在 SMTP 代码，而在附件大小，别硬扛，该压缩就压缩。
4.3 合规与退订：邮件群发源码里最容易缺失的模块
邮件群发和垃圾邮件之间的边界，除了内容本身，还有一个关键动作：退订机制。几乎所有主流邮箱服务商的反垃圾策略里，都要求商业邮件包含退订链接，否则会直接判定为垃圾邮件。国内外的法规（如反垃圾邮件相关的管理条例）也都明确要求商业邮件提供退订渠道。源码里如果没有退订处理模块，等于一封邮件得罪了收件人、服务商、监管三项。
退订逻辑不必复杂：邮件正文底部带一个唯一链接，比如https://yourdomain.com/unsubscribe?token=xxx，用户点击后后端把 token 对应的收件人从列表中标记为退订。发信前先从名单里剔除已退订的邮箱。唯一要注意的点是 token 不能是简单的自增 ID，否则别人可以遍历，替别人退订，导致正常用户被误伤。比较稳妥的做法是sha256(email + salt)生成不可逆 token。
import hashlib import hmac SALT = "your-stable-salt" def generate_unsubscribe_token(email: str) -> str: return hmac.new( SALT.encode("utf-8"), email.encode("utf-8"), hashlib.sha256 ).hexdigest()用 HMAC 而不是单纯字符串拼接的好处是：token 不可预测，且同一个邮箱每次生成的 token 一致（如果你不需要 token 过期的话）。退订链接里带 email 明文也可以，但 Base64 编码后的邮箱很容易被解码，不够干净。这个模块最好在系统设计初期就做进去，等邮件量大了再回补退订功能，会涉及历史数据的重清洗，很麻烦。
4.4 频率控制：连接池、时延和发送节奏的参数设置
频率控制是邮件群发源码里决定生死的一环。如果你的发送节奏是每秒钟 100 封，收件方服务器很可能直接用 421 错误拒绝你的连接，极端情况下还会把发件 IP 拉入黑名单。频率控制要做两层：一层是单连接内的发送间隔，另一层是全局的每小时发送上限。
单连接内的间隔设置取决于对方的服务器策略。有些服务器用令牌桶限流，短时间突发不会触发，但持续高压会触发；有些服务器是滑动窗口，连续高频一定触发。供参考的保守参数是：单连接每封间隔 0.5 到 1 秒，每连接发送 50 封后重连。全局上限方面，如果你用的是企业邮箱 SMTP，常见限制是每天几百封到几千封，超出后拒收并退回。这些限制常常写在服务商帮助文档里，建议查一下源码候选的 SMTP 服务商帮助文档再写死参数。
import time SEND_INTERVAL = 0.8 # 单封发送间隔（秒） BATCH_SIZE = 50 # 单连接最大发送量（封） def controlled_send(tasks): for i, task in enumerate(tasks): send_with_retry(task) if (i + 1) % BATCH_SIZE == 0: print(f"batch {i//BATCH_SIZE + 1} done, reconnect...") # 这里需要断掉当前连接并重新建立 time.sleep(SEND_INTERVAL)逻辑说明：BATCH_SIZE 和 SEND_INTERVAL 的组合决定了单条连接的请求速率。比如间隔 0.8 秒、batch 50，意味着一个连接里 50 封邮件分布在 40 秒左右，属于比较温和的节奏。如果你要两小时内发完 10 万封，这个参数会被顶破，需要引入多线程或多机分布式发送。多线程时要注意 SMTP 连接不是线程安全的，每一组线程都要独立的连接对象，并且要把全局发送频率统一到一个计数器里做限速。
关于 sleep 位置有一个实践经验：sleep 放在每封邮件成功之后而不是之前，万一连接中断，重连流程不会被 sleep 拖慢。另外，遇到 421/450 响应码时，不能简单地按固定间隔重试，而是要按响应里包含的重试时间或按指数退避（翻倍递增）处理，否则会造成“服务器让我等 5 分钟、我 0.5 秒后又来撞一次”的恶性循环。
5. 邮件群发源码落地避坑：从判垃圾到连接被拒的问题排查
5.1 邮件进垃圾箱：SPF、DKIM、DMARC 三个记录缺一不可
遇到的现象：本地测试时收件人能收到邮件，但只要批量发送超过几十封，邮件开始大量进入垃圾箱，甚至直接丢失。很多人会怀疑是发信频率太高，但实际上频率正常。原因在于发信域名的 DNS 里缺少 SPF、DKIM、DMARC 三件套。SMTP 服务器接收邮件后，会反向校验发件域名的 SPF 记录是否允许这个发信 IP 代发；DKIM 记录检查邮件是否被签名且签名密钥是否有效；DMARC 告诉接收方如果前面两项失败，是拒绝、隔离还是放行。三件套缺失或配置冲突，邮件被当作钓鱼邮件的概率极高。
解决方式：在发件域名的 DNS 管理界面加三组 TXT 记录。SPF 记录里指定你使用的 SMTP 服务器 IP 或域名，例如v=spf1 ip4:203.0.113.10 ~all，表示只有这个 IP 可以代表域名发信，~all 是软失败的标记。DKIM 记录由 SMTP 服务商提供公钥值，不同服务商的 selector 不同。DMARC 记录通常是v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com，p=quarantine 表示未通过校验的邮件进垃圾箱而不是直接拒收，这个参数在生产环境初期可以降低邮件丢件率。
需要注意的坑是 SPF 有 10 次 DNS 查询的上限。如果发信链路里嵌入了多家服务商，SPF 记录里的 include 段太多，会直接超过限制导致 SPF 永久失败。解决方法是精简发信链路，或者用子域名单独做邮件发送（例如 mail.yourdomain.com），让主域名的 SPF 只做一个 include。
5.2 发送报错 SMTPAuthenticationError：授权码和密钥配置排查
现象是代码能连接上 SMTP 服务器，但 login 阶段返回 535 或者 454，提示认证失败。这个报错 90% 的情况是账号密码填错了，但为什么填对了还报错？三种常见原因：一是上文提到的授权码和登录密码混淆；二是账号被服务商风控锁定（比如短时间大量登录尝试）；三是服务器要求必须使用 SSL 加密认证，而你的连接还是 STARTTLS 升级过程中断了。
解决步骤是：首先检查 SMTP_PASS 是不是从服务商后台申请的独立授权码；其次尝试用 465 端口 + SMTP_SSL 方式连接一次，排除 STARTTLS 中间人拦截的问题；最后如果都排除了，登录平台后台查看该账号是否被限制发信。
# 用 openssl 验证 SMTP 服务器是否正常接受认证（命令仅为连通性验证） openssl s_client -connect smtp.example-relay.com:465 -quiet执行后能看到服务器的证书链和加密协商状态。如果这里的证书过期或自签名，smtplib 在有些版本里会拒绝握手，报错却不提示证书问题。这种情况需要在代码里指定上下文，但一般不建议跳过证书验证，风险太大。
5.3 远程主机拒连：连接被拒、超时和 IP 信誉问题
现象是 sendmail 阶段出现 connection refused 或 timeout，但不是每次发送都复现，而是间歇性出现。原因大概率是发信 IP 的声誉值被收件方服务器盯上了。邮件服务器之间是有一张“信誉网络”的，你的发信 IP 如果短时间内向某个域发了大量不合格邮件，对方会临时封禁。封禁通常不是全量，而是对特定域或者特定 IP 段的策略。
解决方面有两个方向：一是换用信誉度更高的中继服务商，这些服务商本身维护了大量可靠 IP 池，分散发送不会让单个 IP 承担太大压力；二是减下频率、提高内容质量，最直接的方式是检查是否有硬弹（邮箱地址不存在）比率的异常升高，硬弹是拉低 IP 信誉最快的行为。群里发信正常但硬弹和软弹列表一定要落库分析，不能只看成功数量。
另外一个容易被忽略的点是发信时间集中度：凌晨 3 点突然发出 5 万封邮件，很容易被收件方服务器当成异常行为。按工作时间段均匀投递，比快速发完更安全。
5.4 连接被断开后重发失败：会话状态管理问题
现象是发送过程中插入重试逻辑后，发现重试时不断报 “SMTPServerDisconnected: Connection unexpectedly closed”。原因是 SMTP 连接是有状态的，连接断开后 server 对象未重新创建，而是被当成可用连接继续使用。重试逻辑写在 sendmail 外层，但重试时依然引用同一个断开的 connection，自然失败。
解决方式是每次重试之前重新建立连接对象。封装一个send_with_retry函数，内部捕获异常后先关闭旧连接，再重新创建，而不是复用传入的 server 实例。同时记录当前任务是否已发送成功，避免重连后重复发送同一封。邮件重复发送在 SMTP 层无法避免，只能靠业务层做幂等标记。smtplib 没有原生幂等机制，需要在数据库里给每个 task 加一个 send_id，客户端收到服务器的成功响应后标记，但响应丢失时会重复发送，这也是邮件群发不能绝对避免重复投递的行业共识。
5.5 编码混乱：中文主题、附件文件名与 HTML 乱码
现象是收件人看到主题正常，但正文乱码；或者主题正常、发件人显示名乱码。原因在 MIME 头编码方式和新浪、腾讯等邮箱客户端的解析兼容性差异。MIMEText 构造时指定 utf-8 后，中文 HTML 正文乱码的问题很少见，重点检查的是 Subject 和 From 头。
Subject 一定要用 Header(subject, "utf-8") 或 Header(subject, "gbk") 按需编码。From 头里如果要显示发件人姓名，用 formataddr + Header 组合。不要直接把中文塞进 msg["From"]，否则有些服务器发送时会报 ASCII 编码错。附件文件名前面已经提过用 encode_rfc2231，但如果附件名里有空格或引号，还要做转义处理。实践证明，最好的方案是控制附件文件名全部用拼音或英文，彻底避开兼容性问题，但这个要求不是所有业务都能接受，所以正解还是写一个统一的 MIME 头编码函数，所有头字段都过一遍这个函数统一编码。
6. 生产环境落地：用消息队列串起发信链路并监控每封邮件的回头率
先明确一个判断：拿到邮件群发源码后，不建议立刻拿真实用户名单跑量。正确顺序是先建立一个“最小闭环”来验证链路稳定性。我当时的一个模拟项目X里，做法是先把队列、发送 worker、退订接口三个模块拼起来，跑通一封真实邮件，确认能进收件箱，再进行量级扩展。这一步看起来慢，但省掉后面大量排查时间。
闭环里的消息队列用 Redis 的列表结构就够用，把发信任务以 JSON 字符串形式 push 到队列，发送 worker 从队列 pop 后逐封发送。这比直接操作数据库要简单，而且天然支持多 worker 并发消费。对于千万级任务量，这个结构也扛得住，只要控制好 worker 数量和 Redis 连接池大小。不建议一上来就上沉重的 MQ 框架，因为邮件发送链路本身没有复杂的消息路由需求，Redis 队列只是做一个解耦和缓冲。
import redis import json r = redis.Redis(host="localhost", port=6379, db=0) def enqueue_tasks(email_list): # 把待发任务写入队列 for email in email_list: task = {"to": email, "template": "welcome.html", "created_at": time.time()} r.rpush("mail_queue", json.dumps(task)) def worker_loop(): while True: raw = r.blpop("mail_queue", timeout=5) if raw is None: continue task = json.loads(raw[1]) send_with_retry(task) r.incr("mail_sent_total")blpop 是阻塞式读取，队列空时 worker 会挂起等任务，不会空耗 CPU。这个结构天然支持多个 worker 进程横向扩展，Redis 负责分配合法任务给不同 worker。缺点是要自己维护任务超时：如果 worker 在中途崩溃，队列里的任务会丢失，因为邮件任务属于非原子操作。解决方式是在任务里加 retry_count，worker 处理前先检查是否超过最大重试次数，超过的转入死信队列人工处理。
监控层面，最核心的指标是退订率和送达后打开行为。退订链接已经带了 token，后端记录退订来源；打开率则需要邮件正文里的像素追踪标记，整封邮件埋一张 1x1 的透明图片，带上任务 ID。图片标记虽然简单，但要注意一些邮件客户端默认不加载外部图片，所以打开率是低估值。这个指标不是万能的，但作为发送质量的风向标足够用。
我自己的使用习惯是：每次批量发送前，先发 50 封到一个专门测试邮箱列表（包含主流邮箱的若干地址），确认没有进垃圾箱后再全量投放。这个动作虽然朴素，但比打印日志排查高效得多。发完一批后，观察 Redis 里的 sent/failed 计数是否和数据库记录一致，不一致说明发送逻辑有漏更新或重复发送的风险。这套检查流程走习惯了之后，每次批量发送前心里会很有底。希望这些细节对你正在搭的邮件群发源码有帮助。
本文还有配套的精品资源，点击获取
