aws ses 的 sendrawemail 要求原始邮件内容以原始字节（非 base64 编码）形式传入；sdk 会自动处理 base64 编码/解码，手动编码会导致邮件解析失败，虽返回成功但收件方无法收到。
aws ses 的 sendrawemail 要求原始邮件内容以原始字节（非 base64 编码）形式传入；sdk 会自动处理 base64 编码/解码，手动编码会导致邮件解析失败，虽返回成功但收件方无法收到。
在使用 AWS SDK for Go 调用 SendRawEmail 发送原始 MIME 邮件时，一个常见却隐蔽的错误是：对邮件正文内容进行了额外的 Base64 编码。虽然代码能成功调用 API 并返回 MessageId，但实际邮件无法送达（尤其是 Gmail 等主流邮箱常静默丢弃格式异常的原始邮件），而 SendEmail 接口正常——这恰恰暴露了问题根源在于原始邮件结构的合规性。
关键依据来自 AWS Go SDK 官方文档 对 RawMessage.Data 字段的明确说明：
// Data is automatically base64 encoded/decoded by the SDK.
这意味着：你只需将符合 RFC 5322 标准的原始邮件字节（即未编码的纯文本 MIME 内容）直接赋值给 Data 字段，SDK 会在 HTTP 请求层自动完成 Base64 编码；若提前手动编码（如 base64.StdEncoding.EncodeToString(...)），则最终请求体中会出现双重编码，导致 SES 服务端解码后得到乱码或无效 MIME 结构，从而拒绝投递或静默失败。
✅ 正确写法（修正后的核心代码）：
messageContent := `From: "Alice" <alice>
To: "Bob" <bob>
Subject: Hello
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
This is a test email`
// ⚠️ 关键修正：直接传入原始字节，不再手动 Base64 编码
message := ses.RawMessage{
Data: []byte(messageContent), // ← 去掉 base64.EncodeToString！
}
input := ses.SendRawEmailInput{
Source: aws.String("alice@example.com"),
Destinations: []*string{aws.String("bob@gmail.com")},
RawMessage: &message,
}
output, err := svc.SendRawEmail(&input)
if err != nil {
log.Fatalf("SendRawEmail failed: %v", err)
}
log.Printf("Sent successfully, MessageId: %s", aws.StringValue(output.MessageId))</bob></alice>
? 补充注意事项：
-
邮件头必须完整且规范：至少包含
From、To、Subject和空行分隔的正文；推荐添加MIME-Version: 1.0和Content-Type，避免解析歧义。 -
发件人地址需经验证：确保
Source地址已在 SES 控制台完成邮箱或域名验证（沙盒环境中仅允许向已验证地址发送）。 - Gmail 收件兼容性：Gmail 对原始邮件格式极为敏感，缺失空行、多余空格、非法字符或编码错误均可能导致退信或进入垃圾箱；建议使用 SES Mail Simulator 进行无成本测试。
-
调试技巧：启用 SDK 日志（
session.NewSessionWithOptions(session.Options{Config: aws.Config{LogLevel: aws.LogLevel(aws.LogDebugWithHTTPBody)}})）可查看实际发出的 Base64 编码 payload，验证是否为预期内容。
总结：SendRawEmail 是强大但“零容忍”的接口——它把 MIME 构建责任完全交还给开发者，而 SDK 只负责传输层编码。牢记 “传原文，不传 Base64” 这一铁律，即可避开绝大多数无声失败陷阱。
