Seo AI
AI Agent
Đăng nhậpNhận 451 trong log, email đang nằm queue. Bài này không giải thích lý thuyết — subcode, lệnh kiểm tra, fix thẳng vào vấn đề.
Đọc log trước — xác định subcode và message text
# Real-time
tail -f /var/log/mail.log | grep "451"
# Đếm 451 hôm nay
grep "451" /var/log/mail.log | grep "$(date '+%b %e')" | wc -l
# Domain nhận gây ra nhiều 451 nhất
grep "451" /var/log/mail.log \
| grep -oP "to=<[^>]+>" \
| sort | uniq -c | sort -rn | head -20
# Xem full context theo queue ID
grep "QUEUEID" /var/log/mail.log
# Thống kê deferred hàng ngày
pflogsumm /var/log/mail.log | grep -A10 "deferred"
Bảng tra cứu nhanh theo subcode và message text
451 4.7.1 — Try again later / Greylisted
→ Server nhận đang dùng greylisting tại bước RCPT TO
→ Hành động: không cần làm gì — MTA retry sau 5 phút sẽ pass
→ Xác nhận: lần retry tiếp theo trả về 250 là đúng greylisting
451 4.4.2 — Bad connection / Connection reset
→ Kết nối TCP bị ngắt giữa chừng hoặc DNS lookup timeout phía server nhận
→ Kiểm tra: telnet MX-server 25 từ server gửi
→ Nếu nhiều domain cùng bị: kiểm tra DNS resolver và network outbound
451 4.3.5 — Server configuration problem
→ Milter phía server nhận đang lỗi hoặc không phản hồi
→ Hành động: vấn đề phía server nhận — chờ họ xử lý hoặc thông báo IT admin phía nhận
→ Nếu server nhận là của bạn: kiểm tra milter đang chạy Smtp 421 ổn định cao
451 4.7.0 — SPF verification failed / DNS timeout
→ SPF lookup timeout do DNS chậm hoặc SPF record vượt 10 DNS lookup
→ Kiểm tra: dig TXT yourdomain.com | grep spf và đếm lookup count
→ Fix: rút gọn SPF, giảm số include:
451 4.3.1 — Insufficient system storage
→ Disk phía server nhận đầy hoặc mailbox quota exceeded
→ Hành động: thông báo IT admin phía nhận
→ Nếu server nhận là của bạn: kiểm tra disk ngay
451 4.7.500 — Server busy (Microsoft 365)
→ Exchange Online Protection đang quá tải tạm thời
→ Hành động: MTA tự retry, kiểm tra M365 Service Health Dashboard
→ URL: admin.microsoft.com → Health → Service health
451 4.7.652 — Sending domain not allowed (Microsoft 365)
→ Domain người gửi bị Exchange Online Protection đánh dấu nghi ngờ
→ Kiểm tra SPF, DKIM, DMARC của domain gửi
→ Kiểm tra reputation tại SNDS: sendersupport.olc.protection.outlook.com
451 Milter: to error state
→ Milter (SpamAssassin, ClamAV, Rspamd) crash hoặc timeout
→ Fix: restart milter service trên server nhận
→ Xem chi tiết bên dưới
Lệnh kiểm tra theo từng nguyên nhân
Kiểm tra và quản lý queue
# Xem queue
postqueue -p
# Đếm email đang defer
postqueue -p | grep -c "^[A-F0-9]"
# Lọc message đang nhận 451
postqueue -p | grep -B1 "451"
# Force retry toàn bộ queue
postqueue -f
# Flush và monitor cùng lúc
postqueue -f && tail -f /var/log/mail.log | grep "451\|sent\|bounced"
# Xóa message cụ thể
postsuper -d QUEUEID
# Hold toàn bộ deferred để debug
postsuper -h ALL deferred
# Release sau khi fix xong
postsuper -H ALL deferred && postqueue -f
Kiểm tra SPF lookup count
# Xem SPF record hiện tại
dig TXT yourdomain.com | grep spf
# Đếm lookup thủ công — mỗi include/a/mx/ptr tốn 1 lookup
# Tổng không được vượt 10
# Test online
# https://mxtoolbox.com/spf.aspx
# https://dmarcian.com/spf-survey/
# Ví dụ SPF gọn đúng chuẩn — dưới 10 lookup
# v=spf1 ip4:203.x.x.x ip4:203.x.x.y include:_spf.google.com ~all
# Verify sau khi sửa
dig TXT yourdomain.com | grep spf
# Gửi test email và kiểm tra header: Authentication-Results: spf=pass
Kiểm tra milter trên server nhận (Postfix)
# Kiểm tra Rspamd
systemctl status rspamd
journalctl -u rspamd -n 100 --no-pager
# Kiểm tra SpamAssassin
systemctl status spamassassin
systemctl status spamd
# Kiểm tra ClamAV
systemctl status clamav-daemon
systemctl status clamav-freshclam
# Kiểm tra milter đang cấu hình trong Postfix
postconf smtpd_milters
postconf non_smtpd_milters
postconf milter_default_action
# Nếu milter_default_action = tempfail → 451 khi milter lỗi
# Đổi thành accept để tạm thời bypass milter trong lúc debug:
postconf -e "milter_default_action = accept"
postfix reload
# Restart milter sau khi xử lý xong
systemctl restart rspamd
# hoặc
systemctl restart spamassassin
postfix reload
Kiểm tra DNS và kết nối từ server gửi
# So sánh DNS resolver nội bộ với Google DNS
dig MX remotedomain.com
dig @8.8.8.8 MX remotedomain.com
# Nếu kết quả khác nhau → DNS nội bộ đang có vấn đề
# Test kết nối TCP đến mail server nhận
telnet alt1.gmail-smtp-in.l.google.com 25
telnet smtp.office365.com 25
# Nếu telnet timeout → firewall hoặc routing issue outbound port 25
# Kiểm tra iptables
iptables -L OUTPUT -n | grep 25
iptables -L FORWARD -n | grep 25
# Kiểm tra DNS resolver đang dùng
cat /etc/resolv.conf
systemctl status systemd-resolved
# hoặc
systemctl status named
Kiểm tra disk khi nhận 451 4.3.1
# Disk tổng thể
df -h
# Disk spool Postfix — quan trọng nhất
df -h /var/spool/postfix
# Disk mail storage
df -h /var/mail
df -h /home
# Inode — đôi khi disk còn space nhưng hết inode
df -i /var/spool/postfix
# Top 10 thư mục chiếm nhiều space nhất
du -h /var --max-depth=2 | sort -rh | head -10
# Xóa log cũ nếu cần
journalctl --vacuum-size=500M
find /var/log -name "*.gz" -mtime +30 -delete
Fix theo từng môi trường
Fix SPF vượt 10 DNS lookup
# Trước — quá nhiều include, vượt 10 lookup
v=spf1 include:_spf.google.com include:sendgrid.net include:mailchimp.com
include:amazonses.com include:_spf.salesforce.com ~all
# Sau — flatten bằng ip4 trực tiếp, giảm lookup
v=spf1 ip4:203.x.x.x ip4:198.x.x.x ip4:54.x.x.x
include:_spf.google.com ~all
# Hoặc dùng SPF flattening service
# https://dmarcian.com/spf-flattening/
# https://easydmarc.com/tools/spf-flattening
# Verify lookup count sau khi sửa
# Phải ≤ 10 — kiểm tra tại mxtoolbox.com/spf.aspx
Fix milter_default_action để tránh 451 khi milter lỗi
# /etc/postfix/main.cf
# Option 1: tempfail = 451 khi milter lỗi (mặc định, an toàn hơn)
milter_default_action = tempfail
# Option 2: accept = bỏ qua milter khi lỗi (ít an toàn hơn nhưng email không bị delay)
milter_default_action = accept
# Option 3: reject = từ chối email khi milter lỗi (strict nhất)
milter_default_action = reject
# Khuyến nghị production: giữ tempfail, đảm bảo milter luôn up
# Nếu cần bypass tạm thời trong lúc debug: đổi sang accept
postconf -e "milter_default_action = accept"
postfix reload
# Sau khi milter ổn định, đổi lại
postconf -e "milter_default_action = tempfail"
postfix reload
Fix cấu hình retry queue cho 451
# /etc/postfix/main.cf
# Thời gian tối đa giữ email trong queue
maximal_queue_lifetime = 5d
# Warning bounce trước khi hết hạn
bounce_queue_lifetime = 2d
# Retry interval
minimal_backoff_time = 300s
maximal_backoff_time = 4000s
# Timeout kết nối SMTP
smtp_connect_timeout = 30s
smtp_helo_timeout = 300s
# Với email OTP hoặc time-sensitive — giảm lifetime
# Tạo transport riêng cho loại email này
# /etc/postfix/master.cf
transient unix - - n - - smtp
-o maximal_queue_lifetime=1h
-o bounce_queue_lifetime=1h
postfix reload
postfix check
Fix greylisting — whitelist IP để bypass
# Nếu server nhận của bạn đang dùng Postgrey
# Whitelist IP của mail server gửi tin cậy
# /etc/postgrey/whitelist_clients
# Thêm IP hoặc hostname cần bypass greylisting
mail.trustedpartner.com
203.x.x.x
# Restart Postgrey
systemctl restart postgrey
# Kiểm tra whitelist đang áp dụng
postgrey --lookup=mail.trustedpartner.com
Với hệ thống email server production, nên giữ milter_default_action = tempfail và đảm bảo milter luôn được monitor — thay vì đổi sang accept để tránh 451 nhưng mất lớp bảo vệ spam và virus.
Monitor 451 tự động
# Script alert khi 451 vượt ngưỡng
# /usr/local/bin/check_smtp451.sh
#!/bin/bash
COUNT=$(grep "451" /var/log/mail.log | grep "$(date '+%b %e')" | wc -l)
THRESHOLD=50
if [ "$COUNT" -gt "$THRESHOLD" ]; then
echo "ALERT: $COUNT lần lỗi SMTP 451 hôm nay trên $(hostname)" \
| mail -s "[SMTP ALERT] 451 vượt ngưỡng" [email protected]
fi
# Thêm crontab
crontab -e
# 0 * * * * /usr/local/bin/check_smtp451.sh
# Theo dõi queue size định kỳ
# */15 * * * * postqueue -p | grep -c "^[A-F0-9]" >> /var/log/queue_size.log
# Dùng pflogsumm cho report hàng ngày
# 0 6 * * * pflogsumm /var/log/mail.log | mail -s "Daily Mail Report" [email protected]
Với email công ty trên Microsoft 365, không có access log SMTP trực tiếp nhưng có thể theo dõi 451 qua Message Trace trong Exchange Admin Center: Mail flow → Message trace → Run trace và lọc theo status “Pending” hoặc “Failed.”
Checklist xử lý 451 theo mức độ
# MỨC 1 — 451 rải rác, email đến sau vài phút
□ Xác nhận MTA đang retry: postqueue -p
□ Xác nhận email cuối cùng được sent: grep "sent" /var/log/mail.log
□ Không cần can thiệp thêm
# MỨC 2 — 451 từ một domain kéo dài hơn 1 giờ
□ Đọc message text xác định subcode
□ Kiểm tra MX record domain nhận: dig MX domain.com
□ Test TCP: telnet MX-server 25
□ Kiểm tra SPF lookup count nếu có "SPF" trong message
□ Force retry sau khi xác định nguyên nhân: postqueue -f
# MỨC 3 — 451 từ nhiều domain cùng lúc
□ Kiểm tra DNS resolver: dig MX gmail.com vs dig @8.8.8.8 MX gmail.com
□ Kiểm tra network outbound port 25
□ Kiểm tra tài nguyên server: df -h, free -h, top
□ Kiểm tra milter services: systemctl status rspamd / spamassassin
□ Kiểm tra Postfix process: postfix status
# MỨC 4 — Queue tích lũy lớn, email quan trọng bị delay
□ Hold queue: postsuper -h ALL deferred
□ Xác định và xử lý nguyên nhân gốc
□ Release queue theo batch: postsuper -H ALL deferred
□ Monitor chặt sau release: tail -f /var/log/mail.log
SMTP 451 tự hết trong phần lớn trường hợp — nhưng khi subcode chỉ rõ SPF timeout, milter crash, hay DNS lỗi, cần can thiệp đúng tầng. Đọc log, tra subcode, chạy lệnh kiểm tra, fix đúng chỗ, verify qua queue và header. Không đoán, không thử đại.
451 và 421 khác nhau ở điểm nào trong Postfix log?
421 xảy ra ở bước kết nối TCP hoặc ngay đầu SMTP session — server đóng kết nối trước khi nhận MAIL FROM. Trong log Postfix, 421 thường xuất hiện ở dòng connect to hoặc ngay sau EHLO. 451 xảy ra sau khi session đã bắt đầu, thường ở bước RCPT TO hoặc DATA — log ghi rõ host MX-server said: 451 kèm subcode. Về retry, cả hai đều được MTA xử lý tự động theo exponential backoff.
milter_default_action = accept có an toàn không trong production?
Không nên dùng lâu dài. Khi milter lỗi và action là accept, email đi qua mà không qua lớp kiểm tra spam hoặc virus — tăng nguy cơ malware và spam pass vào hệ thống. Chỉ dùng tạm thời trong quá trình debug hoặc khi cần bypass khẩn cấp, sau đó đổi lại tempfail ngay khi milter ổn định. Smtp 550 cài chính xác
Postgrey whitelist có ảnh hưởng đến bảo mật không?
Whitelist bypass greylisting cho IP hoặc hostname cụ thể — email từ nguồn đó không còn bị delay lần đầu. Về bảo mật, greylisting chỉ là một trong nhiều lớp lọc spam; SPF, DKIM, DMARC và content filter vẫn hoạt động bình thường. Whitelist các mail server của đối tác tin cậy là hợp lý — không nên whitelist dải IP quá rộng.
SPF flattening có nhược điểm gì không?
Có. Khi bên thứ ba (SendGrid, Google, Amazon SES) thay đổi IP trong pool của họ, SPF flattened của bạn sẽ lỗi thời — email từ IP mới của họ sẽ SPF fail. Cần dùng dịch vụ flattening tự động cập nhật (như dmarcian hay EasyDMARC) thay vì flatten thủ công một lần rồi bỏ. Hoặc giữ include: cho các provider quan trọng và chỉ flatten các nguồn IP cố định nội bộ.
