Seo AI
AI Agent
Đăng nhậpNhận 421 trong log, email đang nằm trong queue. Bài này không giải thích lý thuyết — chỉ có subcode, lệnh kiểm tra, và cách xử lý thẳng vào vấn đề.
Đọc log trước — mọi thứ bắt đầu từ đây
421 là lỗi tạm thời — MTA sẽ tự retry. Nhưng message text đi kèm cho biết nguyên nhân cụ thể để quyết định có cần can thiệp hay không:
# Xem 421 real-time
tail -f /var/log/mail.log | grep "421"
# Đếm 421 trong ngày hôm nay
grep "421" /var/log/mail.log | grep "$(date '+%b %e')" | wc -l
# Domain nhận đang gây ra nhiều 421 nhất
grep "421" /var/log/mail.log \
| grep -oP "to=<[^>]+>" \
| sort | uniq -c | sort -rn | head -20
Bảng tra cứu nhanh theo message text
“Try again later” / “closing transmission channel”
→ Server nhận đang throttle hoặc quá tải tạm thời
→ Hành động: để MTA tự retry, theo dõi queue
→ Nếu kéo dài hơn 2 giờ: kiểm tra reputation IP
“Too many concurrent SMTP connections”
→ Đang gửi quá nhiều kết nối đồng thời đến cùng một server
→ Hành động: giảm smtp_destination_concurrency_limit
→ Fix ngay: postqueue -p xem queue, điều chỉnh concurrency Smtp 554 hoạt động 24/7
“Try again in 300 seconds” / “Greylisted”
→ Server nhận đang dùng greylisting
→ Hành động: không cần làm gì — MTA retry sau 5 phút sẽ pass
→ Email tiếp theo đến cùng server sẽ không bị greylisting nữa
“Rate limit exceeded” / “4.7.0”
→ Vượt ngưỡng gửi cho phép của provider (Gmail, M365)
→ Hành động: giảm tốc độ gửi, kiểm tra volume trong giờ đó
→ Fix: thêm smtp_destination_rate_delay trong main.cf
“Service temporarily unavailable” / “4.3.2”
→ Server nhận đang bảo trì hoặc overload
→ Hành động: chờ, theo dõi retry trong queue
→ Nếu kéo dài hơn 6 giờ: kiểm tra MX record domain nhận
“Connection timed out” / “Host not found”
→ DNS resolution lỗi hoặc mạng không ổn định từ phía server gửi
→ Hành động: kiểm tra DNS và kết nối từ server gửi
→ Nếu nhiều domain cùng bị: kiểm tra tài nguyên server gửi
Lệnh kiểm tra và quản lý queue
Xem trạng thái queue
# Liệt kê toàn bộ queue
postqueue -p
# Đếm số email đang trong queue
postqueue -p | grep -c "^[A-F0-9]"
# Xem email defer với lý do 421
postqueue -p | grep -A2 "421"
# Xem chi tiết một message cụ thể theo queue ID
postcat -q QUEUEID
# Xem tất cả deferred message
find /var/spool/postfix/deferred -type f | wc -l
Thao tác với queue
# Force retry toàn bộ queue ngay lập tức
postqueue -f
# Flush queue và theo dõi log cùng lúc
postqueue -f && tail -f /var/log/mail.log | grep "421\|sent\|bounced"
# Xóa một message cụ thể khỏi queue
postsuper -d QUEUEID
# Xóa toàn bộ deferred queue (cẩn thận)
postsuper -d ALL deferred
# Hold tất cả message đang defer để debug
postsuper -h ALL deferred
Kiểm tra kết nối đến server nhận
# Kiểm tra MX record domain nhận
dig MX gmail.com
dig MX outlook.com
dig MX remotedomain.com
# Test kết nối TCP đến cổng 25
telnet alt1.gmail-smtp-in.l.google.com 25
# Test với openssl nếu server yêu cầu STARTTLS
openssl s_client -starttls smtp -connect alt1.gmail-smtp-in.l.google.com:25
# Kiểm tra DNS resolver từ server gửi
dig @8.8.8.8 MX gmail.com # so sánh với
dig MX gmail.com # DNS mặc định của server
Kiểm tra tài nguyên server khi 421 xảy ra đồng thời nhiều domain
# CPU và RAM
top -bn1 | head -20
free -h
# Disk
df -h /var/spool/postfix
# File descriptor limit — Postfix cần nhiều FD khi có nhiều kết nối
ulimit -n
cat /proc/sys/fs/file-max
# Số kết nối SMTP đang mở
ss -tnp | grep :25 | wc -l
ss -tnp | grep smtp | wc -l
# Postfix process đang chạy
postfix status
ps aux | grep postfix
Fix theo từng trường hợp
Fix rate limiting — gửi quá nhanh đến Gmail hoặc Microsoft 365
# /etc/postfix/main.cf
# Giới hạn kết nối đồng thời đến mỗi domain
smtp_destination_concurrency_limit = 2
# Delay giữa các message đến cùng một domain
smtp_destination_rate_delay = 1s
# Giới hạn message mỗi kết nối
smtp_destination_recipient_limit = 50
# Áp dụng riêng cho Gmail và Microsoft
# /etc/postfix/transport
gmail.com smtp:[alt1.gmail-smtp-in.l.google.com]:25
outlook.com smtp:[smtp.office365.com]:25
# /etc/postfix/sender_dependent_rate
gmail.com rate_delay=2s concurrency_limit=1
outlook.com rate_delay=2s concurrency_limit=1
postfix reload
Fix khi 421 kéo dài do reputation thấp
# Kiểm tra reputation tại Google Postmaster Tools
# https://postmaster.google.com/
# Mục cần xem: Domain Reputation, IP Reputation, Spam Rate
# Kiểm tra tại Microsoft SNDS
# https://sendersupport.olc.protection.outlook.com/snds/
# Các tín hiệu cần cải thiện:
# 1. Bounce rate > 2% → clean danh sách người nhận
# 2. Spam complaint > 0.1% → review nội dung và opt-in
# 3. SPF/DKIM/DMARC chưa pass → cấu hình lại DNS authentication
# Kiểm tra SPF
dig TXT yourdomain.com | grep spf
# Kiểm tra DKIM
dig TXT mail._domainkey.yourdomain.com
# Kiểm tra DMARC
dig TXT _dmarc.yourdomain.com
Fix cấu hình Postfix retry khi 421 kéo dài
# /etc/postfix/main.cf
# Thời gian tối đa giữ email trong queue
maximal_queue_lifetime = 5d
# Thời gian warning trước khi bounce
bounce_queue_lifetime = 2d
# Retry interval tối thiểu và tối đa
minimal_backoff_time = 300s
maximal_backoff_time = 4000s
# Số lần thử MX record thứ hai khi MX đầu fail
smtp_mx_address_limit = 5
# Timeout connection
smtp_connect_timeout = 30s
smtp_helo_timeout = 300s
smtp_data_done_timeout = 600s
postfix reload
postfix check # verify cấu hình không có lỗi syntax
Fix file descriptor limit khi 421 do server gửi thiếu tài nguyên
# Kiểm tra limit hiện tại
cat /proc/sys/fs/file-max
ulimit -n
# Tăng limit tạm thời
ulimit -n 65536
# Tăng limit vĩnh viễn
echo "fs.file-max = 65536" >> /etc/sysctl.conf
sysctl -p
# Cấu hình limit cho Postfix process
# /etc/systemd/system/postfix.service.d/limits.conf
[Service]
LimitNOFILE=65536
systemctl daemon-reload
systemctl restart postfix
Với hệ thống email server gửi khối lượng lớn, nên tách riêng luồng email giao dịch (OTP, đặt hàng, xác nhận) và email marketing vào hai IP khác nhau. Khi IP marketing bị throttle và nhận 421 liên tục, IP giao dịch không bị ảnh hưởng.
Monitor 421 tự động
# Script đơn giản alert khi 421 vượt ngưỡng
# Lưu vào /usr/local/bin/check_smtp421.sh
#!/bin/bash
COUNT=$(grep "421" /var/log/mail.log | grep "$(date '+%b %e')" | wc -l)
THRESHOLD=100
if [ "$COUNT" -gt "$THRESHOLD" ]; then
echo "ALERT: $COUNT lần lỗi 421 hôm nay — kiểm tra queue và reputation" \
| mail -s "SMTP 421 Alert - $(hostname)" [email protected]
fi
# Thêm vào crontab chạy mỗi giờ
# crontab -e
0 * * * * /usr/local/bin/check_smtp421.sh
# Dùng pflogsumm để báo cáo hàng ngày
pflogsumm /var/log/mail.log | grep -A10 "deferred"
Với email công ty chạy trên Microsoft 365 hoặc Google Workspace, không có quyền truy cập log SMTP trực tiếp — nhưng có thể theo dõi 421 qua Message Trace trong Exchange Admin Center (M365) hoặc Email Log Search trong Google Admin Console.
Checklist xử lý 421 theo mức độ
# MỨC 1 — 421 xuất hiện rải rác, email đến sau vài phút
□ Kiểm tra queue: postqueue -p
□ Xác nhận MTA đang retry bình thường
□ Không cần can thiệp thêm
# MỨC 2 — 421 từ một domain cụ thể kéo dài hơn 2 giờ
□ Đọc message text trong log để xác định nguyên nhân
□ Kiểm tra MX record domain nhận: dig MX remotedomain.com
□ Test kết nối TCP: telnet MX-server 25
□ Kiểm tra reputation IP tại Google Postmaster / SNDS
□ Xem xét giảm concurrency đến domain đó
# MỨC 3 — 421 từ nhiều domain cùng lúc
□ Kiểm tra tài nguyên server: CPU, RAM, disk, FD limit
□ Kiểm tra DNS resolver từ server gửi
□ Kiểm tra network/firewall outbound cổng 25
□ Kiểm tra Postfix process: postfix status
□ Review log toàn diện: pflogsumm /var/log/mail.log
# MỨC 4 — Queue tích lũy lớn, email quan trọng bị delay nghiêm trọng
□ Hold queue: postsuper -h ALL deferred
□ Xác định và xử lý nguyên nhân gốc rễ
□ Release queue theo batch: postsuper -H ALL deferred && postqueue -f
□ Monitor chặt sau khi release
SMTP 421 tự xử lý được trong phần lớn trường hợp — nhưng khi xuất hiện với tần suất cao hoặc kéo dài, đó là tín hiệu cần đọc log, xác định đúng nguyên nhân và can thiệp đúng tầng. Queue tích lũy không kiểm soát và reputation suy giảm là hai hệ quả thực tế nhất nếu bỏ qua 421 quá lâu.
421 và 450 khác nhau thế nào trong Postfix log?
Cả hai đều là lỗi tạm thời và MTA sẽ retry. Điểm khác biệt: 421 thường xảy ra ở bước kết nối hoặc ngay đầu SMTP session — server đóng kết nối trước khi nhận được lệnh MAIL FROM. 450 thường xảy ra sau khi session đã bắt đầu, cụ thể ở bước RCPT TO — mailbox tạm thời không nhận được. Về xử lý, cả hai đều retry tự động theo cùng cơ chế.
Force retry bằng postqueue -f có an toàn không?
An toàn về mặt dữ liệu — không mất email. Tuy nhiên nếu đang có 421 do rate limiting, force retry quá sớm sẽ khiến server nhận tiếp tục trả về 421 và có thể tăng mức throttle. Nên chờ ít nhất 15-30 phút sau lần 421 cuối cùng trước khi force retry, hoặc giảm concurrency limit trước khi flush queue. Smtp 530 xác thực chuẩn
Postfix giữ email trong queue bao lâu trước khi bounce?
Mặc định Postfix giữ tối đa 5 ngày (maximal_queue_lifetime = 5d). Sau đó tạo bounce notification và xóa khỏi queue. Có thể tùy chỉnh ngắn hơn với email giao dịch cần độ tươi cao (ví dụ OTP đặt maximal_queue_lifetime = 1h) hoặc dài hơn với email thông thường.
Gmail trả về 421 4.7.0 liên tục dù volume gửi thấp — nguyên nhân là gì?
Gmail dùng nhiều tín hiệu ngoài volume để quyết định throttle: spam complaint rate, tỷ lệ invalid recipient, lịch sử reputation của IP và domain, và engagement rate (tỷ lệ người nhận mở email). IP mới hoặc domain chưa có lịch sử gửi mail tốt có thể nhận 421 4.7.0 ngay cả khi volume thấp. Kiểm tra Google Postmaster Tools để xem dữ liệu reputation thực tế.
