Seo AI
AI Agent
Đăng nhậpNhận bounce 554, cần fix nhanh. 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 bounce message
Mọi bounce 554 đều có Diagnostic-Code. Đây là dòng quan trọng nhất, đừng bỏ qua nó:
# Ví dụ các dạng bounce 554 thực tế
# Blacklist:
554 5.7.1 Service unavailable; Client host [x.x.x.x] blocked using zen.spamhaus.org
# DMARC reject:
554 5.7.0 Reject, id=xxxxx - domain owner policy
# Open relay bị từ chối:
554 5.7.1 Relaying denied
# Microsoft 365 policy:
554 5.2.0 STOREDRV.Submission.Exception:SendAsDeniedException
# Nội dung bị spam filter:
554 Transaction failed: Message rejected due to content policy
# PTR không hợp lệ:
554 5.7.1 Helo command rejected: Host not found
Đọc message text sau dấu chấm phẩy — đó là manh mối định hướng toàn bộ quá trình debug.
Bảng tra cứu nhanh theo subcode và message
554 5.7.1 — blocked / blacklisted
→ IP hoặc domain đang bị blacklist
→ Kiểm tra: mxtoolbox.com/blacklists.aspx
→ Fix: gỡ nguyên nhân gốc → submit delisting Smtp 550 kết nối nhanh
554 5.7.0 — domain owner policy / DMARC reject
→ DMARC p=reject đang chặn email không pass SPF hoặc DKIM
→ Kiểm tra: dig TXT _dmarc.yourdomain.com
→ Fix: sửa SPF/DKIM trước, hạ DMARC về p=none trong lúc debug
554 5.7.1 — Relaying denied
→ Server bị coi là open relay hoặc IP không được phép relay
→ Kiểm tra: mxtoolbox.com/diagnostic.aspx (Open Relay Test)
→ Fix: siết cấu hình relay trên Postfix/Exim
554 5.7.1 — Helo command rejected / Host not found
→ PTR record không hợp lệ hoặc HELO/EHLO hostname không resolve được
→ Kiểm tra: dig -x IP_SERVER
→ Fix: thêm PTR record tại nhà cung cấp VPS
554 5.2.0 — Exchange / SendAsDeniedException
→ Mail flow rule hoặc Send As permission trên Microsoft 365 đang block
→ Fix: kiểm tra transport rule và mailbox permission qua PowerShell
554 — content policy / spam score quá cao
→ Nội dung email kích hoạt spam filter phía server nhận
→ Kiểm tra: mail-tester.com trước khi gửi thật
→ Fix: tối ưu nội dung, giảm link, cân bằng text/image
Lệnh kiểm tra theo từng nguyên nhân
Kiểm tra blacklist
# Spamhaus ZEN qua DNS (viết IP ngược chiều)
# VD: IP 203.162.1.2 → query 2.1.162.203.zen.spamhaus.org
dig +short 2.1.162.203.zen.spamhaus.org
# Trả về 127.0.0.x = đang bị list | NXDOMAIN = sạch
# Barracuda
dig +short 2.1.162.203.b.barracudacentral.org
# Kiểm tra nhiều blacklist cùng lúc
# https://multirbl.valli.org/
# https://mxtoolbox.com/blacklists.aspx
Kiểm tra PTR record
# Kiểm tra PTR hiện tại
dig -x 203.162.1.2
# Kết quả mong đợi: 2.1.162.203.in-addr.arpa → mail.yourdomain.com
# Kiểm tra HELO hostname có resolve không
dig A mail.yourdomain.com
# Phải trả về đúng IP của server
# Kiểm tra forward-confirmed reverse DNS (FCrDNS)
# PTR → hostname → phải resolve ngược lại đúng IP ban đầu
Kiểm tra DMARC và authentication
# DMARC policy hiện tại
dig TXT _dmarc.yourdomain.com
# p=reject với SPF/DKIM chưa ổn = nguyên nhân 554 5.7.0
# SPF record
dig TXT yourdomain.com | grep spf
# DKIM record (thay 'mail' bằng selector đang dùng)
dig TXT mail._domainkey.yourdomain.com
# Kiểm tra selector DKIM đang dùng từ header email thật
# Tìm dòng: DKIM-Signature: v=1; s=SELECTOR; d=yourdomain.com
Kiểm tra open relay trên Postfix
# Test thủ công qua telnet
telnet localhost 25
EHLO testclient
MAIL FROM:<[email protected]>
RCPT TO:<[email protected]>
# Nếu server trả về 250 = đang là open relay — cần fix ngay
# Nếu trả về 554/550/relay denied = cấu hình đúng
# Kiểm tra cấu hình relay hiện tại
postconf smtpd_relay_restrictions
postconf smtpd_recipient_restrictions
postconf mynetworks
Đọc log Postfix tìm 554
# Real-time
tail -f /var/log/mail.log | grep "554"
# Lọc theo IP hoặc domain cụ thể
grep "remotedomain.com" /var/log/mail.log | grep "554"
# Xem full transaction theo queue ID
grep "QUEUEID" /var/log/mail.log
# Thống kê rejection theo ngày
pflogsumm /var/log/mail.log | grep -A10 "reject reason"
Fix theo từng môi trường
Fix open relay trên Postfix
# /etc/postfix/main.cf
smtpd_relay_restrictions =
permit_mynetworks,
permit_sasl_authenticated,
defer_unauth_destination
smtpd_recipient_restrictions =
permit_mynetworks,
permit_sasl_authenticated,
reject_unauth_destination
mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128
# Reload sau khi sửa
postfix reload
# Verify
postconf smtpd_relay_restrictions
Fix PTR record
# PTR record không cấu hình ở DNS provider thông thường
# Cần vào control panel của nhà cung cấp VPS:
# Vultr: Servers → chọn server → Settings → Reverse DNS
# DigitalOcean: Networking → Domains → PTR
# Linode: Remote Access → Reverse DNS
# Giá trị PTR nên trỏ về hostname mail server
# VD: 203.162.1.2 → mail.yourdomain.com
# Hostname trong PTR phải khớp với HELO/EHLO
# Kiểm tra HELO đang dùng trong Postfix:
postconf myhostname
postconf smtp_helo_name
Fix DMARC đang chặn email hợp lệ
# Tạm thời hạ DMARC về p=none để debug
# DNS TXT record: _dmarc.yourdomain.com
v=DMARC1; p=none; rua=mailto:[email protected]; fo=1
# Sau khi SPF và DKIM pass ổn định → nâng dần
# p=quarantine (25% → 50% → 100%)
# p=reject (chỉ khi đã xác nhận không còn false positive)
# Đọc DMARC report để xem nguồn nào đang fail
# Report gửi về địa chỉ rua= mỗi 24 giờ
# Parser online: https://dmarcian.com/dmarc-inspector/
Fix Microsoft 365 — 554 5.2.0 SendAsDeniedException
# Kiểm tra Send As permission
Get-RecipientPermission -Identity "[email protected]" | Select Trustee, AccessRights
# Kiểm tra mail flow rule đang block
Get-TransportRule | Where $_.State -eq "Enabled" | Select Name, Priority
# Kiểm tra anti-spam outbound policy
Get-HostedOutboundSpamFilterPolicy | Select Name, RecipientLimitPerMessage, ActionWhenThresholdReached
# Kiểm tra tài khoản có bị hạn chế gửi mail không
Get-Mailbox -Identity "[email protected]" | Select RecipientLimits, MessageCopyForSendOnBehalfEnabled
Fix blacklist — quy trình chuẩn
# Bước 1: Xác định nguyên nhân bị list
# Đọc thông tin trên trang của blacklist — thường ghi rõ lý do
# Bước 2: Xử lý nguyên nhân gốc
# Server bị compromise → đổi credential, vá lỗ hổng, review outbound log
# Gửi spam → dừng campaign, clean danh sách, review content
# IP cold → không fix được bằng delisting, cần warm-up đúng cách
# Bước 3: Submit delisting
# Spamhaus: https://www.spamhaus.org/lookup/
# Barracuda: https://www.barracudacentral.org/rbl/removal-request
# Microsoft: https://sendersupport.olc.protection.outlook.com/snds/
# MXToolbox tổng hợp link delisting: https://mxtoolbox.com/blacklists.aspx
# Bước 4: Verify sau 24-48 giờ
dig +short 2.1.162.203.zen.spamhaus.org
# NXDOMAIN = đã gỡ thành công
Với hệ thống email server tự quản lý, sau khi fix blacklist nên bật rate limiting outbound và alerting để phát hiện sớm nếu server bị compromise lần tiếp theo — tránh bị list lại trước khi kịp phát hiện.
Checklist xác nhận sau khi fix
□ Không còn xuất hiện trong Spamhaus ZEN, Barracuda, Microsoft blacklist
□ PTR record trỏ đúng hostname, hostname resolve ngược lại đúng IP (FCrDNS pass)
□ HELO/EHLO hostname khớp với PTR
□ Postfix không còn là open relay — MXToolbox Open Relay Test pass
□ SPF bao gồm đủ IP và relay, lookup count ≤ 10
□ DKIM key OK — opendkim-testkey trả về "key OK"
□ DMARC policy phù hợp với trạng thái SPF/DKIM
□ Gửi test qua mail-tester.com — đạt 8/10 trở lên
□ Header email nhận được: SPF=pass, DKIM=pass, DMARC=pass
□ Log Postfix không còn dòng 554 sau 24 giờ theo dõi
Test nhanh toàn bộ hệ thống
# Test authentication đầy đủ — gửi đến địa chỉ Port25
# Gửi email từ domain cần test đến: [email protected]
# Nhận lại report SPF/DKIM/DMARC/PTR đầy đủ qua email
# Test spam score trước khi gửi campaign
# https://www.mail-tester.com/
# Test MX, SPF, DKIM, DMARC, blacklist cùng lúc
# https://mxtoolbox.com/emailhealth/
# Kiểm tra deliverability thực tế đến Gmail, Outlook, Yahoo
# https://www.glockapps.com/ (có free tier)
Với email công ty chạy trên nền tảng cloud như Microsoft 365 hay Google Workspace, hầu hết các lệnh kiểm tra DNS bên trên vẫn áp dụng được — điểm khác biệt là phần fix sẽ thực hiện trong admin console hoặc qua PowerShell thay vì trực tiếp trên server.
SMTP 554 luôn có subcode và message text đủ để định hướng xử lý. Quy trình chuẩn: đọc bounce → tra subcode → chạy lệnh kiểm tra đúng tầng → fix → verify qua checklist. Không đoán, không thử đại — log và DNS record đã có đủ thông tin cần thiết
PTR record và A record khác nhau thế nào trong bối cảnh SMTP?
A record ánh xạ hostname về IP (forward DNS). PTR record ánh xạ ngược — từ IP về hostname (reverse DNS). Trong SMTP, server nhận kiểm tra PTR để xác nhận IP người gửi có hostname hợp lệ. FCrDNS (Forward-Confirmed Reverse DNS) yêu cầu cả hai chiều khớp nhau: PTR trỏ hostname, hostname resolve ngược lại đúng IP ban đầu. Thiếu PTR hoặc FCrDNS không pass thường dẫn đến 554 hoặc spam filter trên nhiều server lớn.
Warm-up IP mới cần bao lâu để tránh 554?
Với volume vài trăm email mỗi ngày, thường cần 3-4 tuần tăng dần. Với volume lớn hơn, cần 6-8 tuần. Nguyên tắc: tăng không quá 2x mỗi tuần, duy trì bounce rate dưới 2% và complaint rate dưới 0.1% trong suốt quá trình warm-up. Gửi vượt ngưỡng quá sớm trên IP cold gần như chắc chắn dẫn đến blacklist và 554. Auth login chạy tự động
Tại sao sau khi gỡ blacklist vẫn còn gặp 554 ở một số server?
Mỗi mail server nhận có cache riêng cho reputation data. Một số server cập nhật blacklist theo thời gian thực, một số cache lại trong vài giờ đến vài ngày. Nếu đã verify trên blacklist gốc là đã gỡ nhưng vẫn gặp 554 từ một server cụ thể, liên hệ trực tiếp postmaster của domain đó để yêu cầu flush cache reputation.
554 và 550 cùng xuất hiện trong log — nên xử lý cái nào trước?
Xử lý 554 trước — đây là mức độ nghiêm trọng hơn, thường phản ánh vấn đề ở tầng reputation hoặc server policy tổng thể. Sau khi 554 được giải quyết (gỡ blacklist, fix relay, fix PTR), các lỗi 550 còn lại thường là vấn đề cụ thể hơn như SPF/DKIM từng domain — dễ xử lý hơn và ít có tác động lan rộng.
