当您发送的消息无法传递到收件人的邮箱并以失败通知形式返回给发件人时,就会发生电子邮件退回。虽然单次退回似乎无关紧要,但高退回率会随着时间侵蚀您的发件人信誉,导致越来越多的合法电子邮件被过滤到垃圾邮件或完全拒收。本指南解释了硬退回和软退回之间的关键差异、如何读取 SMTP 错误代码、分析邮件服务器日志以及实施能够真正降低退回率的修复。

电子邮件传递如何运作以及为什么会发生退回

当您发送电子邮件时,您的邮件传输代理 (MTA) 会打开与目标邮件服务器的 SMTP 连接。接收服务器然后以状态代码响应,指示它是接受消息、暂时不可用还是永久拒收传递。如果服务器无法接受消息,它会生成非传递报告 (NDR)——也称为退回邮件——并将其返回给发件人。

退回消息包含三个关键信息:SMTP 状态代码、提供额外上下文的增强状态代码 (ESC) 和易读的诊断字符串。理解如何解析这些信息是有效修复传递问题的起点。

什么是硬退回?

硬退回是永久传递失败。接收服务器以 5xx SMTP 代码响应,表示再多的重试也不会导致成功传递。发送 MTA 记录失败并立即停止重新传输尝试。

硬退回最常见的原因包括:

硬退回很严重,因为每一个都是直接信号表明您的列表质量很差。Google、Microsoft 和 Yahoo 将退回率用作其过滤决策中的关键因素——具有持续高硬退回率的发件人会看到其邮件被路由到垃圾邮件或完全被阻止。

什么是软退回?

软退回是临时传递失败。接收服务器以 4xx SMTP 代码响应,表示它现在无法接受消息,但稍后可能能够接受。发送 MTA 将消息排队并按计划重试传递——通常每 15-30 分钟间隔增加一次——在 24 到 72 小时内,然后放弃并生成退回通知。

软退回的常见原因包括:

虽然单个软退回是电子邮件传递的正常部分,但软退回多次针对同一地址重复是一个警告信号。许多电子邮件平台会自动将重复的软退回转换为硬退回以防止无限重试循环。

硬退回 vs 软退回:SMTP 代码参考

类型 SMTP 代码 增强代码 含义 操作
硬 550 5.1.1 用户未知/邮箱不存在 立即从列表中删除
硬 551 5.1.6 用户不是本地;不允许转发 从列表中删除
硬 554 5.7.1 被拒——垃圾邮件或策略违规 检查黑名单 + SPF/DKIM/DMARC
软 421 4.3.2 服务不可用/速率限制 让 MTA 自动重试
软 452 4.2.2 邮箱已满/超出配额 MTA 重试;如果持续通知收件人
软 452 4.3.1 系统存储空间不足 MTA 自动重试

读取和分析退回日志

有效的退回管理始于直接读取 MTA 日志。Linux 托管环境中最常见的两个 MTA 是 Postfix 和 Exim。两者都记录详细的退回信息,告诉您确切地为什么传递失败——不仅仅是它失败了。

分析 Postfix 日志

Postfix 日志通常位于 /var/log/maillog 或 /var/log/mail.log。包含退回事件的行以 status=bounced 标记。

# View all bounce events in Postfix log
grep "status=bounced" /var/log/maillog | tail -50

# Example output:
# Jun 9 10:23:11 mailserver postfix/smtp[1234]: ABC123: to=<[email protected]>,
#   relay=mail.example.com[93.184.216.34]:25,
#   status=bounced (host mail.example.com said:
#   550 5.1.1 The email account does not exist)

# Count bounces grouped by destination domain
grep "status=bounced" /var/log/maillog \
  | grep -oP 'to=<[^@]+@\K[^>]+' \
  | sort | uniq -c | sort -rn | head -20

分析 Exim 日志

Exim 被 DirectAdmin 和许多共享托管环境使用。主要日志位于 /var/log/exim_mainlog。退回事件以 ** 标记。

# View bounce events in Exim log
grep " \*\* " /var/log/exim_mainlog | tail -50

# Example output:
# 2026-06-09 10:25:00 1lOXxx-0000YY-00 ** [email protected]
#   R=dnslookup T=remote_smtp: SMTP error after RCPT TO:
#   550 5.1.1 User unknown

# Count today's bounces
grep "$(date '+%Y-%m-%d')" /var/log/exim_mainlog | grep " \*\* " | wc -l

系统地修复硬退回

硬退回需要立即和系统的行动。以下步骤解决根本原因而不仅仅是症状。

第 1 步——从列表中删除退回的地址

任何生成硬退回的电子邮件地址必须立即从您的邮件列表中删除,并且永不重试。继续向已知无效地址发送是过滤系统使用的最清晰的垃圾邮件信号之一。以下 Python 脚本从 Postfix 日志中提取唯一的硬退回地址:

import re

bounced_emails = set()
with open('/var/log/maillog') as f:
    for line in f:
        if 'status=bounced' in line:
            match = re.search(r'to=<([^>]+)>', line)
            if match:
                bounced_emails.add(match.group(1).lower())

with open('hard_bounce_list.txt', 'w') as out:
    for email in sorted(bounced_emails):
        out.write(email + '\n')

print(f"Found {len(bounced_emails)} hard-bounced addresses")

第 2 步——验证和修复您的 DNS 身份验证记录

相当大比例的硬退回,特别是那些带有 554 5.7.1 或 550 5.7.26 代码的,源于 SPF、DKIM 或 DMARC 配置错误。接收服务器拒绝电子邮件是因为它无法验证它真的来自您的域。

# Check SPF record
dig TXT yourdomain.com | grep "v=spf1"

# Check DKIM public key
dig TXT selector1._domainkey.yourdomain.com

# Check DMARC policy
dig TXT _dmarc.yourdomain.com

# A correct SPF record looks like:
# "v=spf1 mx a ip4:您r.server.ip include:mail.provider.com ~all"

# A correct DKIM record looks like:
# "v=DKIM1; k=rsa; p=MIGfMA0GCSq..."

# A monitoring DMARC record (start here):
# "v=DMARC1; p=none; rua=mailto:[email protected]"

第 3 步——检查和解决黑名单列表

如果硬退回发生在带有策略拒绝代码的多个目标域上,您的发送 IP 或域可能被列入黑名单。使用以下方法检查 Spamhaus——最广泛使用的黑名单:

# Check an IP against Spamhaus ZEN (reverse octets first)
# Example: checking 93.184.216.34 → query 34.216.184.93.zen.spamhaus.org
dig 34.216.184.93.zen.spamhaus.org A

# If query returns 127.0.0.x = LISTED (blocked)
# If query returns NXDOMAIN = NOT LISTED (clean)

# Check multiple lists at once using MXToolbox (manual):
# https://mxtoolbox.com/blacklists.aspx

# After delisting:
# 1. Fix root cause (spam complaints, compromised account)
# 2. Submit delisting request 到 each list
# 3. Monitor 对于 re-listing over next 30 days

减少软退回和不必要的重试

大多数软退回通过 MTA 的重试机制自动解决。然而,当特定软退回类型持续重复时,主动干预比等待更有效。

处理重复的邮箱已满退回 (452)

如果关键联系人的邮箱反复显示已满,通过替代渠道(电话、即时消息)与他们联系让他们知道。对于在您自己的服务器上的用户,您可以通过 DirectAdmin 或命令行增加他们的配额:

# Increase mailbox quota via DirectAdmin API
curl -k "https://您r-server:2222/CMD_API_电子邮件_QUOTA" \
  -u admin:password \
  -d "domain=yourdomain.com&user=username"a=1024"
  # quota value 是 in MB

配置 Postfix 发送速率限制以避免 421 错误

发送批量电子邮件时,每个域的速率限制可防止您从大型提供商触发 421 限流响应。在 Postfix 中配置这些:

# /etc/postfix/main.cf — rate limiting configuration
smtp_destination_rate_delay = 1s          # 1 second delay between messages
smtp_extra_recipient_limit = 10           # max 10 recipients per connection
default_destination_concurrency_limit = 2  # max 2 simultaneous connections per domain
smtp_destination_recipient_limit = 50     # max 50 recipients per destination

# Apply changes
postfix reload

专业提示:在发送任何大规模电子邮件活动前,运行电子邮件列表验证以在无效地址成为退回之前删除它们。将其与所有新注册的双重选择加入相结合。您发送前的目标应该是预测的硬退回率低于 2% 和软退回率低于 5%。

使用 SPF、DKIM 和 DMARC 保护发件人信誉

正确配置的电子邮件身份验证是防止策略拒绝退回的最有效方法。从 2024 年开始,Google 和 Yahoo 对批量发件人强制使用 SPF、DKIM 和 DMARC。即使对于事务性电子邮件,这三条记录也是必要的。

SPF——定义授权发件人

# Complete SPF record example
yourdomain.com. IN TXT "v=spf1 mx a ip4:192.0.2.1 include:sendgrid.net ~all"

# Explanation:
# mx         = servers listed in MX records 是 authorized
# a          = A record of domain 是 authorized
# ip4:x.x.x  = explicit IP authorization
# include:   = inherit authorization from another domain's SPF
# ~all       = softfail (mark but don't reject) — recommended during migration
# -all       = hardfail (reject immediately) — recommended 对于 stable setups

DKIM——密码学签名

# Generate DKIM key pair (OpenSSL)
openssl genrsa -out dkim_private.pem 2048
openssl rsa -in dkim_private.pem -pubout -out dkim_public.pem

# The public key goes into DNS as a TXT record:
# selector1._domainkey.yourdomain.com TXT "v=DKIM1; k=rsa; p=<BASE64_PUBLIC_KEY>"

# Verify DKIM signing 是 working by checking email headers:
# Look for: DKIM-Signature: v=1; a=rsa-sha256; d=yourdomain.com; s=selector1
# And verify result: Authentication-Results: dkim=pass

DMARC——策略和报告

# Start 带 p=none (monitoring mode)
_dmarc.yourdomain.com. IN TXT "v=DMARC1; p=none; rua=mailto:[email protected]"

# After reviewing aggregate reports 对于 2-4 weeks, move 到 quarantine:
"v=DMARC1; p=quarantine; pct=25; rua=mailto:[email protected]"

# Gradually increase pct until reaching reject:
"v=DMARC1; p=reject; rua=mailto:[email protected]; ruf=mailto:[email protected]"

持续退回率监控

减少您的退回率不是一次性修复——它需要持续监控。以下工具和实践可长期控制您的退回率:

#!/bin/bash
# /usr/local/bin/check_bounce_rate.sh
DATE=$(date '+%Y-%m-%d' -d "yesterday")
TOTAL=$(grep "$DATE" /var/log/maillog | grep "status=" | wc -l)
BOUNCED=$(grep "$DATE" /var/log/maillog | grep "status=bounced" | wc -l)

if [ "$TOTAL" -gt 0 ]; then
  RATE=$(echo "scale=2; $BOUNCED * 100 / $TOTAL" | bc)
  echo "Date: $DATE | Sent: $TOTAL | Bounced: $BOUNCED | Rate: ${RATE}%"
  if (( $(echo "$RATE > 5" | bc -l) )); then
    echo "ALERT: Bounce Rate exceeded 5% — immediate investigation required"
  fi
fi

# Add 到 crontab 到 run at 08:00 daily:
# 0 8 * * * /usr/local/bin/check_bounce_rate.sh | mail -s "Daily Bounce Report" [email protected]

常见问题

硬退回和软退回有什么区别?

硬退回是永久传递失败,接收服务器以 SMTP 5xx 代码响应,表示电子邮件永远无法传递。常见原因包括不存在的地址、无效域名和永久策略块。这些必须立即从您的列表中删除。软退回是临时失败 (SMTP 4xx),MTA 将消息排队并重试传递 24-72 小时。常见原因包括邮箱已满、服务器停机和速率限制。

什么样的退回率是可接受的?我何时应该担心?

硬退回率低于 2% 通常是可接受的。一旦您超过 2%,您的发件人信誉开始受到影响。如果您的硬退回率超过 5%,您有可能面临 IP 或域名黑名单,这会导致广泛的传递失败。您应该每 3-6 个月清理一次电子邮件列表,并实施双重选择加入以防止无效地址随时间的积累。

我如何在邮件日志中读取 SMTP 退回错误代码?

SMTP 代码分为两类:4xx 用于临时失败(软退回)和 5xx 用于永久失败(硬退回)。常见示例:421 = 服务暂时不可用或速率限制,452 = 邮箱已满或存储空间不足,550 = 邮箱不存在或策略拒绝,554 = 被拒作为垃圾邮件或违反策略。增强状态代码提供更多特定性——例如,550 5.1.1 特别表示用户未知。

我如何修复由黑名单列表引起的高退回率?

首先检查您的 IP 或域是否使用 MXToolbox 或 MultiRBL 被列入黑名单。如果被列入,调查根本原因——垃圾邮件投诉、被破坏账户发送垃圾邮件或僵尸网络活动——并首先解决。然后提交取消列入请求到您出现的每个黑名单,说明采取的纠正措施。同时,验证您的 SPF/DKIM/DMARC 记录配置正确,清理您电子邮件列表中的无效地址,并实施双重选择加入以防止将来积累坏地址。

您自己域名上的商业电子邮件托管

AsiaGB 电子邮件配备预配置的 SPF、DKIM 和 DMARC 以实现高可递送性。起价 200 泰铢/年。

查看电子邮件计划