SMTP 550 nguyên nhân - Cách khắc phục tối ưu deliverability mail

Khác với nhiều lỗi SMTP có thể tự hồi phục, mã 550 là tín hiệu dứt khoát từ phía server nhận: Email của bạn bị từ chối vĩnh viễn. Không có retry, không có hàng đợi chờ — thư mất ngay tại điểm đó. Tùy theo subcode đi kèm, lý do từ chối có thể là địa chỉ không tồn tại, vi phạm chính sách bảo mật, domain bị blacklist, hoặc thiếu xác thực SPF/DKIM/DMARC. Bài viết này phân tích từng trường hợp cụ thể và hướng dẫn xử lý theo môi trường thực tế.

Vị trí của mã 550 trong kiến trúc phản hồi SMTP

Trong giao thức SMTP, nhóm mã 5xx biểu thị lỗi vĩnh viễn — server đã nhận yêu cầu, hiểu nó và quyết định từ chối. Không giống nhóm 4xx (lỗi tạm thời, MTA gửi sẽ thử lại theo schedule), một lần nhận mã 5xx, MTA sẽ tạo bounce notification gửi về người gửi và xóa message khỏi queue. Mã 550 cụ thể thuộc nhóm “Requested action not taken: mailbox unavailable” theo RFC 5321. Tuy nhiên trong thực tế, server nhận dùng 550 cho nhiều lý do khác nhau — từ địa chỉ Email không tồn tại, domain bị block, đến vi phạm chính sách anti-spam. Chính vì vậy, subcode mở rộng theo RFC 3463 (Enhanced Status Codes) là thông tin quan trọng nhất để định hướng xử lý.

Phân tích các mã lỗi 550 phổ biến

550 5.1.1 — The Email giá rẻ account does not exist

Địa chỉ Email người nhận không tồn tại trên server đích. Đây là trường hợp đơn giản nhất về mặt kỹ thuật nhưng lại gây nhiều nhầm lẫn nhất trong thực tế. Nguyên nhân thường gặp: nhập sai địa chỉ, tài khoản đã bị xóa, hoặc domain đã đổi MX record nhưng địa chỉ cũ vẫn còn trong danh sách gửi. Với hệ thống Email chính hãng marketing hoặc CRM tự động, 550 5.1.1 tích lũy theo thời gian làm tăng hard bounce rate — ảnh hưởng trực tiếp đến reputation của sending domain.

550 5.1.2 — Bad destination mailbox address

Địa chỉ Email giá rẻ có cú pháp hợp lệ nhưng domain không có MX record hoặc không phân giải được. Thường gặp khi domain người nhận hết hạn, MX record bị xóa nhầm, hoặc DNS propagation chưa hoàn tất sau khi chuyển nhà cung cấp Email giá rẻ.

550 5.7.1 — Message rejected due to policy

Server nhận từ chối dựa trên chính sách bảo mật — không phải vì địa chỉ sai mà vì Email giá rẻ vi phạm một hoặc nhiều điều kiện kiểm tra. Đây là subcode phức tạp nhất vì “policy” có thể là SPF fail, DKIM invalid, DMARC reject, IP blacklist, content filter, hoặc rate limit. Cần đọc thêm message text đi kèm để xác định cụ thể.

550 5.4.1 — Recipient address rejected: Access denied

Mã đặc thù của Microsoft Exchange và Exchange Online. Thường xuất hiện khi domain người nhận tồn tại nhưng địa chỉ cụ thể bị từ chối do chính sách recipient filtering, safe sender list, hoặc mail flow rule trên tenant người nhận.

550 5.7.26 — Unauthenticated Email from domain

Gmail và Google Workspace dùng subcode này khi Email chính hãng đến từ domain không có SPF hoặc DKIM hợp lệ, và domain đó có DMARC policy là reject. Kể từ tháng 2/2024, Google enforce chính sách này nghiêm ngặt hơn cho các sender gửi khối lượng lớn.

550 5.7.0 — Email chính hãng rejected per SPF policy

SPF record của domain người gửi không bao gồm IP của server đang gửi mail. Server nhận kiểm tra SPF, thấy ~all hoặc -all và IP không khớp, trả về 550. Phổ biến khi doanh nghiệp chuyển sang mail server mới hoặc dùng SMTP relay bên thứ ba mà chưa cập nhật SPF.

Nguyên nhân gốc rễ theo từng tầng hạ tầng

Tầng DNS: SPF, DKIM, DMARC không đồng bộ

Đây là nguyên nhân phổ biến nhất dẫn đến 550 5.7.1 và 550 5.7.26. Ba cơ chế này phối hợp với nhau để xác thực danh tính người gửi: Smtp 530 rất trực quan

• SPF xác nhận IP server gửi có được phép gửi thay cho domain không
• DKIM xác nhận nội dung Email không bị can thiệp qua chữ ký mã hóa
• DMARC định nghĩa chính sách xử lý khi SPF hoặc DKIM fail: none, quarantine, hoặc reject

Khi domain có DMARC p=reject nhưng SPF không bao gồm IP của mail server đang dùng, mọi Email gửi đi đều nhận 550 tại server nhận có enforce DMARC. Lỗi này đặc biệt nguy hiểm vì không xuất hiện trong quá trình test nội bộ — chỉ lộ ra khi Email đến server bên ngoài.

Tầng reputation: IP và domain blacklist

Nếu IP của mail server hoặc sending domain xuất hiện trong các blacklist như Spamhaus, SORBS, Barracuda, hoặc Microsoft SNDS — server nhận sẽ từ chối với 550 ngay khi kết nối. Điều này có thể xảy ra với IP mới chưa có reputation (cold IP), hoặc IP đã từng bị dùng để gửi spam bởi tenant trước trên VPS cloud. Kiểm tra blacklist nhanh:

# Kiểm tra qua MXToolbox
https://mxtoolbox.com/blacklists.aspx

# Hoặc qua command line với dig
dig +short 2.0.0.127.zen.spamhaus.org
# Nếu trả về 127.0.0.x → IP đang bị list trên Spamhaus ZEN
# (thay 2.0.0.127 bằng IP server viết ngược)

Tầng content: Filter nội dung và attachment

Một số 550 5.7.1 không liên quan đến DNS hay IP mà do nội dung Email kích hoạt content filter phía server nhận. Thường gặp với: attachment có phần mở rộng bị chặn (.exe, .js, .vbs), URL trong nội dung trỏ đến domain blacklist, hoặc từ ngữ trong subject/body khớp với rule spam filter.

Tầng cấu hình server nhận: Recipient filtering

Trên Exchange Server và Microsoft 365, recipient filtering có thể từ chối địa chỉ cụ thể ngay cả khi mailbox tồn tại — do mail flow rule, transport rule, hoặc blocked sender list. Đây là nguyên nhân của 550 5.4.1 trong môi trường Exchange.

Cách khắc phục theo từng trường hợp

Xác minh và cập nhật SPF record

Kiểm tra SPF hiện tại:

dig TXT yourdomain.com | grep spf
# hoặc
nslookup -type=TXT yourdomain.com

SPF record chuẩn cho domain dùng một mail server và một SMTP relay bên ngoài:

v=spf1 ip4:203.x.x.x include:_spf.google.com include:sendgrid.net ~all

Lưu ý quan trọng: SPF có giới hạn tối đa 10 DNS lookup. Mỗi include: tốn ít nhất một lookup. Vượt quá 10 lookup, SPF trả về permerror và Email giá rẻ sẽ fail SPF bất kể IP có trong list hay không. Dùng công cụ như MXToolbox SPF Record Checker để đếm lookup count.

Cấu hình DKIM trên Postfix với OpenDKIM

# Cài đặt
apt install opendkim opendkim-tools

# Tạo key pair
mkdir -p /etc/opendkim/keys/yourdomain.com
opendkim-genkey -D /etc/opendkim/keys/yourdomain.com/ -d yourdomain.com -s mail

# /etc/opendkim.conf
Domain                  yourdomain.com
KeyFile                 /etc/opendkim/keys/yourdomain.com/mail.private
Selector                mail
Socket                  inet:8891@localhost

# Thêm DNS TXT record
# mail._domainkey.yourdomain.com → nội dung trong file mail.txt
cat /etc/opendkim/keys/yourdomain.com/mail.txt

Sau khi publish DKIM record lên DNS, verify bằng:

opendkim-testkey -d yourdomain.com -s mail -vvv

Thiết lập DMARC đúng lộ trình

Không nên bật p=reject ngay từ đầu. Lộ trình chuẩn:

# Giai đoạn 1: Monitor — không block, chỉ gửi report
v=DMARC1; p=none; rua=mailto:[email protected]; ruf=mailto:[email protected]; fo=1

# Giai đoạn 2: Quarantine — Email fail đi vào spam
v=DMARC1; p=quarantine; pct=25; rua=mailto:[email protected]

# Giai đoạn 3: Reject — từ chối hoàn toàn (chỉ khi đã verify SPF và DKIM ổn định)
v=DMARC1; p=reject; rua=mailto:[email protected]

Chuyển thẳng sang p=reject mà chưa xác nhận SPF và DKIM hoạt động đúng là nguyên nhân phổ biến nhất khiến toàn bộ Email outbound bị 550 5.7.26 trên Gmail và các server enforce DMARC.

Xử lý IP blacklist

Nếu IP đang bị list, quy trình xử lý: Auth login tư vấn sâu

• Xác định IP đang bị list trên blacklist nào qua MXToolbox hoặc MultiRBL
• Tìm hiểu nguyên nhân bị list: server bị compromise, outbound spam, hay cold IP
• Vá nguyên nhân gốc rễ trước khi request delisting
• Submit delisting request trực tiếp trên website của từng blacklist
• Spamhaus thường xử lý trong 24 giờ nếu IP đã sạch; Microsoft SNDS có thể mất 1-3 ngày

Với IP cloud mới, cần warm-up dần: bắt đầu với vài trăm Email chính hãng/ngày, tăng dần theo tuần. Gửi lớn ngay từ đầu trên IP cold gần như chắc chắn dẫn đến blacklist và 550.

Khắc phục 550 5.4.1 trên Microsoft 365

Kiểm tra mail flow rule đang block địa chỉ cụ thể:

# PowerShell Exchange Online
Get-TransportRule | Where $_.State -eq "Enabled" | Select Name, Description
Get-HostedContentFilterPolicy | Select -ExpandProperty BlockedSenders
Get-HostedContentFilterPolicy | Select -ExpandProperty BlockedSenderDomains

Kiểm tra recipient filtering:

Get-RecipientFilterConfig | Select BlockListEnabled, BlockedRecipients

Với email công ty tạo niềm tin chạy trên Microsoft 365, lỗi 550 5.4.1 đôi khi xuất phát từ phía tenant người nhận chứ không phải lỗi cấu hình bên gửi — cần liên hệ IT admin phía nhận để xác nhận.

Kiểm tra và debug lỗi 550 theo quy trình chuẩn

Một quy trình debug có hệ thống sẽ tiết kiệm thời gian hơn nhiều so với thử từng giải pháp:

# Bước 1: Đọc bounce message đầy đủ
# Bounce notification chứa toàn bộ SMTP dialog, đọc phần "Diagnostic information"

# Bước 2: Kiểm tra DNS authentication
dig TXT yourdomain.com | grep spf
dig TXT mail._domainkey.yourdomain.com
dig TXT _dmarc.yourdomain.com

# Bước 3: Kiểm tra blacklist
# MXToolbox: https://mxtoolbox.com/blacklists.aspx
# MultiRBL: https://multirbl.valli.org/

# Bước 4: Test gửi mail với header đầy đủ
# Dùng mail-tester.com hoặc glockapps.com để xem authentication result

# Bước 5: Kiểm tra log phía server gửi
tail -f /var/log/mail.log | grep "550"
# Postfix ghi rõ remote server response trong log

Với email server kết nối nhanh tự quản lý, log Postfix chứa đầy đủ response từ server nhận kèm subcode — đây là nguồn thông tin chính xác nhất, ưu tiên đọc log trước khi dùng công cụ bên ngoài.

Tác động của 550 đến sender reputation và deliverability dài hạn

Lỗi 550 không chỉ ảnh hưởng đến Email hiện tại mà tích lũy tác động theo thời gian. Các mail provider lớn như Gmail, Microsoft, Yahoo theo dõi bounce rate của sending domain và IP. Hard bounce rate vượt 2% thường kích hoạt throttling — server nhận bắt đầu làm chậm hoặc từ chối thêm Email giá rẻ từ domain đó. Với hệ thống gửi Email chính hãng marketing hoặc transactional Email chính hãng khối lượng lớn, cần duy trì:

• Hard bounce rate dưới 2%
• Complaint rate (người đánh spam) dưới 0.1%
• Danh sách người nhận được verify và làm sạch định kỳ
• Unsubscribe được xử lý ngay lập tức

Google Postmaster Tools và Microsoft SNDS cung cấp dữ liệu thực tế về reputation của domain và IP gửi — nên thiết lập monitor từ đầu thay vì chờ đến khi gặp vấn đề.

Phân biệt 550 với các lỗi SMTP từ chối khác

Không phải mọi lỗi từ chối Email giá rẻ đều là 550. Phân biệt đúng giúp xử lý nhanh hơn:

• 421: Service temporarily unavailable — server nhận đang quá tải hoặc bảo trì. MTA sẽ retry tự động.
• 450: Mailbox unavailable tạm thời — thử lại sau. Khác với 550 là vĩnh viễn.
• 530: Authentication required — lỗi xác thực phía server gửi, không liên quan đến server nhận.
• 550: Từ chối vĩnh viễn — không retry, bounce ngay.
• 552: Message size exceeds fixed limit — Email quá lớn so với giới hạn server nhận.
• 554: Transaction failed — thường là policy vi phạm nghiêm trọng hơn, đôi khi kèm blacklist toàn domain.

Lỗi SMTP 550 là tín hiệu rõ ràng và có thể xử lý được nếu đọc đúng subcode và trace đúng tầng vấn đề. Phần lớn các trường hợp 550 trong môi trường doanh nghiệp hiện đại đều liên quan đến ba điểm: DNS authentication chưa đồng bộ (SPF, DKIM, DMARC), IP hoặc domain bị blacklist do lịch sử gửi mail, hoặc policy phía server nhận từ chối dựa trên content hay địa chỉ. Cách tiếp cận hiệu quả nhất là thiết lập đúng từ đầu — cấu hình SPF bao phủ đủ IP, DKIM ký đúng, DMARC triển khai theo lộ trình — thay vì debug từng lỗi sau khi chúng xảy ra. Kết hợp với monitor reputation qua Google Postmaster Tools và Microsoft SNDS, hệ thống Email chính hãng sẽ duy trì deliverability ổn định mà không cần can thiệp thường xuyên. Lỗi smtp 535 sửa triệt để

Lỗi 550 có tự hết không nếu thử gửi lại?

Không. Mã 550 thuộc nhóm 5xx vĩnh viễn — MTA gửi sẽ không thử lại và tạo bounce notification ngay lập tức. Chỉ hết khi nguyên nhân gốc rễ được xử lý: cập nhật SPF, gỡ blacklist, hoặc sửa địa chỉ người nhận sai.

SPF đã đúng nhưng vẫn gặp 550 5.7.1, tại sao?

SPF chỉ là một trong ba lớp xác thực. Nếu domain có DMARC policy là reject hoặc quarantine, và DKIM không hợp lệ hoặc thiếu alignment, Email chính hãng vẫn bị 550 dù SPF pass. Kiểm tra DKIM và DMARC alignment — header From: domain phải khớp với domain trong DKIM signature và SPF.

Làm thế nào biết IP đang bị blacklist nào?

Dùng MXToolbox Blacklist Check hoặc MultiRBL để kiểm tra đồng thời trên hàng chục blacklist. Kết quả trả về tên blacklist cụ thể và thường có link trực tiếp đến trang delisting request của từng list.

550 5.1.1 có nghĩa là địa chỉ Email người nhận không tồn tại — nhưng địa chỉ đó vẫn đang dùng bình thường, tại sao?

Có thể do server nhận cấu hình directory harvest protection — trả về 550 5.1.1 cho mọi địa chỉ bên ngoài không có trong whitelist, kể cả địa chỉ hợp lệ, để tránh bị enumerate danh sách mailbox. Trường hợp này cần liên hệ trực tiếp với IT admin phía nhận để whitelist domain gửi.

Warm-up IP mất bao lâu để tránh 550 do reputation?

Thời gian warm-up phụ thuộc vào volume gửi mục tiêu. Với volume trung bình vài nghìn Email giá rẻ/ngày, thường cần 4-6 tuần tăng dần. Với volume lớn (hàng trăm nghìn/ngày), có thể cần 8-12 tuần. Trong quá trình warm-up, monitor bounce rate và complaint rate chặt chẽ — tăng tốc quá nhanh khi rate còn cao sẽ phản tác dụng.