Phân biệt Hard Bounce và Soft Bounce email marketing | Quy trình xử lý email khỏi danh sách

Email bị trả lại liên tục có thể làm tăng Bounce Rate, lãng phí lượt gửi và ảnh hưởng đến uy tín người gửi. Tuy nhiên, xóa tất cả địa chỉ bị bounce cũng có thể khiến doanh nghiệp mất những khách hàng vẫn còn khả năng nhận email. Vì vậy, marketer cần phân biệt rõ Hard Bounce và Soft Bounce trước khi quyết định giữ hay loại một địa chỉ khỏi danh sách.

Bài viết này sẽ giúp bạn nhận biết từng loại bounce, đọc mã lỗi SMTP và quy trình xử lý lỗi này.

Hard Bounce và Soft Bounce là gì?

Email bounce là trạng thái email đã được gửi đi nhưng máy chủ của người nhận không thể phân phối thư đến hộp thư đích. Khi đó, hệ thống thường trả về Non-Delivery Report hoặc SMTP response để cho biết lý do email bị từ chối.

Trong thực tế, email bounce thường được chia thành hai loại chính:

• Hard Bounce là lỗi mang tính lâu dài. Lỗi này thường xảy ra khi địa chỉ email không tồn tại, tài khoản đã bị vô hiệu hóa hoặc domain người nhận không hợp lệ.
• Soft Bounce là lỗi tạm thời. Email có thể được gửi lại thành công khi hộp thư có dung lượng trở lại, máy chủ hoạt động ổn định hoặc giới hạn gửi được gỡ bỏ.

Về mã lỗi, nhóm 4.x.x thường phản ánh lỗi tạm thời, còn 5.x.x thường liên quan đến lỗi lâu dài. Tuy nhiên, doanh nghiệp không nên chỉ dựa vào mã đầu tiên để quyết định xóa email, vì một số lỗi về chính sách, uy tín người gửi hoặc xác thực cũng có thể tạo ra phản hồi 5.x.x.

Tiêu chí	Hard Bounce	Soft Bounce
Bản chất	Lỗi lâu dài	Lỗi tạm thời
Khả năng gửi lại	Thường thấp	Có thể gửi lại
Ví dụ	Email không tồn tại	Hộp thư đầy
Cách xử lý	Suppress sớm	Theo dõi và retry
Rủi ro khi tiếp tục gửi	Cao	Phụ thuộc nguyên nhân

Vì vậy, doanh nghiệp nên đánh giá đồng thời loại bounce, mã SMTP, số lần lỗi và lịch sử gửi của contact trước khi quyết định giữ, retry hay loại địa chỉ email khỏi danh sách.

Hard Bounce là gì? Những nguyên nhân thường gặp

Hard Bounce là trạng thái email không thể được gửi tới người nhận do một lỗi mang tính lâu dài hoặc vĩnh viễn. Trường hợp này thường xảy ra khi địa chỉ email không tồn tại, domain không hợp lệ hoặc tài khoản người nhận đã bị vô hiệu hóa.

Amazon SES cũng xếp các lỗi mang tính persistent, điển hình như địa chỉ email không tồn tại, vào nhóm Hard Bounce. Khi gặp lỗi này, doanh nghiệp nên ngừng gửi tới địa chỉ đó và đưa email vào danh sách suppression để tránh làm tăng bounce rate.

Ví dụ:

550 5.1.1 The email account that you tried to reach does not exist

Mã 550 5.1.1 thường cho thấy hệ thống không tìm thấy tài khoản người nhận. Với trường hợp này, doanh nghiệp không nên tiếp tục retry nếu chưa xác minh lại địa chỉ.

• Địa chỉ email không tồn tại: Đây là nguyên nhân Hard Bounce phổ biến nhất. Địa chỉ có thể bị nhập sai, đã bị xóa hoặc chưa từng tồn tại.

Ví dụ:

customer123@gmail.com

Hệ thống có thể trả về các thông báo như:

550 5.1.1
User unknown
Mailbox does not exist
Recipient not found

Khi xác định rõ mailbox không tồn tại, doanh nghiệp nên suppress địa chỉ ngay thay vì tiếp tục gửi ở các chiến dịch sau.

• Domain người nhận không tồn tại: Hard Bounce cũng có thể xảy ra khi phần domain của địa chỉ email bị nhập sai hoặc không còn hoạt động.

Ví dụ:

name@gmial.com

thay vì:

name@gmail.com

Trong trường hợp này, doanh nghiệp nên kiểm tra lại dữ liệu gốc trước khi loại contact. Nếu đây chỉ là lỗi đánh máy và có thể xác minh địa chỉ chính xác, dữ liệu có thể được sửa. Ngược lại, doanh nghiệp không nên tự suy đoán địa chỉ đúng rồi tiếp tục gửi.

• Tài khoản email đã bị vô hiệu hóa: Tình huống này thường gặp trong Email Marketing B2B, đặc biệt khi danh sách chứa email nhân sự doanh nghiệp.

Ví dụ, địa chỉ:

nguyen.a@company.com

từng hoạt động bình thường nhưng mailbox đã bị khóa sau khi nhân viên nghỉ việc.

Khi server xác nhận tài khoản không còn tồn tại hoặc không còn khả năng nhận thư, doanh nghiệp nên chuyển địa chỉ đó sang trạng thái không hoạt động và ngừng gửi email marketing.

• Email bị từ chối do chính sách hoặc bảo mật: Không phải mọi mã lỗi 5xx đều đồng nghĩa với việc địa chỉ người nhận đã chết. Một số email có thể bị từ chối vì:

• sender reputation thấp;

• domain hoặc IP bị block;

• SPF, DKIM hoặc DMARC gặp lỗi;

• chính sách bảo mật của server nhận;

• nội dung bị hệ thống đánh giá rủi ro.

Vì vậy, marketer cần đọc đầy đủ SMTP response trước khi xóa contact.

Nếu hàng trăm địa chỉ thuộc cùng một domain đồng loạt trả về lỗi policy hoặc security, khả năng cao vấn đề nằm ở sender, authentication hoặc hệ thống nhận, chứ không phải toàn bộ địa chỉ người nhận đều không tồn tại. Trong trường hợp này, doanh nghiệp nên tạm dừng gửi tới nhóm đó và kiểm tra nguyên nhân kỹ thuật trước khi quyết định suppress.

Soft Bounce là gì? Những nguyên nhân thường gặp

Soft Bounce là trạng thái email tạm thời chưa thể được chuyển đến hộp thư người nhận, nhưng địa chỉ email vẫn có khả năng nhận thư trong những lần gửi tiếp theo. Nguyên nhân thường đến từ hộp thư đầy, máy chủ nhận đang bận hoặc server tạm thời không khả dụng.

Trong các trường hợp này, hệ thống Email Marketing thường tiếp tục retry trong một khoảng thời gian nhất định thay vì loại địa chỉ khỏi danh sách ngay.

Ví dụ:

452 4.2.2 Mailbox full

Mã 452 4.2.2 cho biết hộp thư người nhận đã hết dung lượng. Địa chỉ email vẫn tồn tại nên doanh nghiệp chưa cần suppress contact.

• Hộp thư người nhận đầy: Khi mailbox hết dung lượng, server không thể nhận thêm email dù địa chỉ người nhận vẫn hoạt động. Đây là một Soft Bounce điển hình. Doanh nghiệp nên giữ contact và theo dõi những lần gửi tiếp theo. Khi người nhận giải phóng dung lượng hộp thư, email có thể được phân phối bình thường trở lại.

• Máy chủ email tạm thời gặp sự cố: Soft Bounce cũng có thể xuất hiện khi máy chủ nhận đang bảo trì, quá tải hoặc tạm thời không phản hồi. Một số mã thường gặp gồm:

421 4.3.0
451 4.3.0

Trong trường hợp này, sender nên chờ và retry theo cơ chế của ESP. Việc xóa contact không giải quyết được vấn đề vì nguyên nhân nằm ở máy chủ nhận, không phải địa chỉ email.

• Email bị throttling hoặc giới hạn tốc độ gửi: Máy chủ nhận có thể tạm thời từ chối email nếu sender gửi quá nhanh hoặc vượt ngưỡng mà hệ thống cho phép. Ví dụ:

421 4.4.5 Server busy

Khi gặp lỗi này, doanh nghiệp nên kiểm tra tốc độ gửi, số lượng email và phản hồi từ server trước khi tiếp tục. Nếu vội vàng coi đây là email không hợp lệ và xóa contact, doanh nghiệp có thể loại nhầm một khách hàng vẫn đang hoạt động.

• Email vượt quá giới hạn dung lượng: Một số server từ chối email khi nội dung hoặc tệp đính kèm vượt quá dung lượng cho phép. Trong trường hợp này, lỗi nằm ở message, không nằm ở địa chỉ người nhận. Doanh nghiệp nên tối ưu dung lượng email hoặc thay tệp đính kèm bằng đường dẫn tải xuống. Không nên xóa contact chỉ vì một chiến dịch có dung lượng quá lớn.

Hard Bounce và Soft Bounce khác nhau như thế nào?

Hard Bounce và Soft Bounce khác nhau chủ yếu ở khả năng email có thể được gửi thành công trong tương lai. Hard Bounce thường phản ánh lỗi lâu dài ở địa chỉ người nhận, còn Soft Bounce thường xuất phát từ một vấn đề tạm thời.

Hiểu đơn giản, Hard Bounce cho biết doanh nghiệp không nên tiếp tục gửi nếu địa chỉ chưa được sửa hoặc xác minh lại. Ngược lại, Soft Bounce cho biết hệ thống chưa thể nhận email tại thời điểm hiện tại nhưng có thể nhận lại sau đó.

Trường hợp	Xử lý danh sách gửi	Xử lý trong CRM
Email không tồn tại	Suppress	Có thể giữ lịch sử contact
Domain không tồn tại	Xác minh rồi suppress	Không cần xóa ngay
Inbox đầy một lần	Tiếp tục theo dõi	Giữ nguyên
Server tạm thời lỗi	Retry	Giữ nguyên
Soft Bounce liên tục	Có thể tạm suppress	Giữ contact
Policy block	Điều tra trước khi suppress	Giữ contact
Tài khoản bị vô hiệu hóa	Ngừng gửi	Có thể giữ lịch sử khách hàng

Điểm cần lưu ý là suppress một địa chỉ email không đồng nghĩa với xóa khách hàng khỏi CRM. Đây là hai nghiệp vụ khác nhau nhưng nhiều doanh nghiệp thường xử lý chung.

Ví dụ, một khách hàng đã từng mua hàng có thể không còn sử dụng địa chỉ email cũ nhưng vẫn còn số điện thoại, Zalo hoặc lịch sử giao dịch có giá trị. Nếu doanh nghiệp xóa toàn bộ contact chỉ vì email bị Hard Bounce, những dữ liệu này cũng có thể bị mất theo.

Cách xử lý phù hợp hơn là giữ hồ sơ khách hàng trong CRM nhưng chuyển trạng thái email sang Invalid hoặc Suppressed. Doanh nghiệp có thể tiếp tục chăm sóc khách hàng qua các kênh khác và cập nhật lại địa chỉ email khi có thông tin mới.

Khi nào cần loại Hard Bounce khỏi danh sách email?

Với các Hard Bounce xuất phát từ địa chỉ không tồn tại, doanh nghiệp nên ngừng gửi ngay từ lần bounce đầu tiên. Việc tiếp tục gửi tới một địa chỉ đã được xác nhận không hợp lệ chỉ làm tăng bounce rate và ảnh hưởng đến chất lượng danh sách.

Mailgun thường ngừng gửi tới địa chỉ ngay sau khi ghi nhận Hard Bounce. Amazon SES cũng sử dụng cơ chế suppression để hạn chế tiếp tục gửi tới những địa chỉ gây permanent bounce.

Tuy nhiên, không phải mọi Hard Bounce đều nên được xử lý giống nhau. Doanh nghiệp cần dựa vào nguyên nhân cụ thể trước khi quyết định suppress.

• Hard Bounce do User Unknown hoặc Email Does Not Exist: Nếu server xác nhận người nhận không tồn tại, doanh nghiệp nên suppress địa chỉ ngay. Các phản hồi thường gặp gồm:

550 5.1.1
User unknown
Mailbox does not exist
Recipient not found

Đây là nhóm lỗi có mức độ chắc chắn cao nhất và không nên tiếp tục retry.

• Hard Bounce do domain không tồn tại: Nếu hệ thống không tìm thấy domain người nhận, doanh nghiệp nên kiểm tra lại dữ liệu trước khi suppress. Ví dụ:

name@gmial.com

có thể chỉ là lỗi nhập sai gmail.com.

Nếu có thể xác minh đây là typo, doanh nghiệp nên sửa lại địa chỉ. Nếu domain thực sự không tồn tại, contact nên được loại khỏi danh sách gửi.

• Hard Bounce do policy hoặc security: Với các lỗi liên quan đến policy, bảo mật hoặc reputation, doanh nghiệp không nên xóa contact ngay. Nguyên nhân có thể nằm ở chính hệ thống gửi thay vì địa chỉ người nhận. Trước tiên, marketer cần kiểm tra:

• SPF;

• DKIM;

• DMARC;

• sender reputation;

• IP reputation;

• blocklist;

• tốc độ và sản lượng gửi;

• nội dung email;

• authentication alignment.

Nếu nhiều địa chỉ thuộc cùng một domain đồng loạt bounce, doanh nghiệp nên ưu tiên kiểm tra sender và chính sách của server nhận. Trường hợp này thường không có nghĩa toàn bộ contact đều không hợp lệ.

Soft Bounce bao nhiêu lần thì nên loại khỏi danh sách?

Không có một quy chuẩn chung rằng Soft Bounce đúng 3 lần thì phải xóa email. Mỗi ESP có thể áp dụng ngưỡng và cách xử lý khác nhau tùy nguyên nhân, thời gian xảy ra bounce và lịch sử delivery của contact.

Vì vậy, marketer nên đánh giá Soft Bounce theo tần suất, khoảng thời gian và khả năng gửi thành công trở lại, thay vì chỉ cộng dồn số lần lỗi.

Ví dụ:

Contact A

Ngày 1: Mailbox full
Ngày 2: Mailbox full
Ngày 3: Mailbox full

Contact B

Tháng 1: Soft bounce
Tháng 2: Delivered
Tháng 4: Soft bounce
Tháng 5: Delivered
Tháng 8: Soft bounce

Cả hai contact đều có ba lần Soft Bounce, nhưng cách xử lý không nên giống nhau. Contact A đang gặp lỗi liên tiếp trong thời gian ngắn, trong khi Contact B vẫn có nhiều lần delivery thành công giữa các lần bounce.

Sau 1 lần Soft Bounce

Doanh nghiệp nên giữ contact và cho phép hệ thống retry.

Một lỗi đơn lẻ như mailbox full hoặc server tạm thời không khả dụng chưa đủ để kết luận địa chỉ không còn giá trị.

Sau 2–3 lần Soft Bounce liên tiếp

Doanh nghiệp nên kiểm tra nguyên nhân trước khi tiếp tục gửi.

Các yếu tố cần xem gồm:

• mailbox full;

• server unavailable;

• throttling;

• policy block;

• sender reputation.

Nếu lỗi chỉ mang tính tạm thời, contact vẫn có thể tiếp tục được giữ trong danh sách gửi.

Sau 3–5 lần Soft Bounce liên tiếp trong thời gian ngắn

Doanh nghiệp có thể chuyển contact sang temporary suppression để tránh tiếp tục gửi lặp lại tới một địa chỉ đang gặp vấn đề.

Tuy nhiên, contact vẫn nên được giữ trong CRM nếu còn thông tin khách hàng hoặc lịch sử giao dịch có giá trị.

Sau một lần delivery thành công

Nếu email được gửi thành công trở lại, doanh nghiệp có thể reset bộ đếm Soft Bounce tùy theo chính sách của hệ thống.

Cách xử lý này phản ánh chính xác hơn tình trạng hiện tại của mailbox và tránh loại nhầm những địa chỉ vẫn hoạt động bình thường.

Vì vậy, thay vì áp dụng quy tắc cố định như “3 lần là xóa”, doanh nghiệp nên dựa trên số lần Soft Bounce liên tiếp, khoảng thời gian xảy ra lỗi, SMTP response và lịch sử delivery để quyết định retry hay suppress.

Cách đọc mã lỗi SMTP để xác định nguyên nhân Email Bounce

Khi email bị bounce, doanh nghiệp không nên chỉ nhìn trạng thái Hard Bounce hoặc Soft Bounce trên dashboard. Để xác định đúng nguyên nhân, marketer cần đọc thêm SMTP response mà máy chủ người nhận trả về.

Ví dụ, nếu hệ thống chỉ hiển thị:

Soft Bounce

thì chưa đủ để biết vấn đề nằm ở hộp thư, máy chủ hay tốc độ gửi. Khi xem chi tiết SMTP response, doanh nghiệp có thể gặp các thông báo như:

452 4.2.2 Mailbox full

421 4.7.x Temporary rate limit

451 Temporary server error

Ba trường hợp đều có thể được ghi nhận là Soft Bounce nhưng cách xử lý khác nhau. Mailbox đầy cần chờ và retry, rate limit yêu cầu điều chỉnh tốc độ gửi, còn server error thường cần theo dõi cho đến khi hệ thống nhận hoạt động ổn định trở lại.

Vì vậy, marketer nên đọc đồng thời SMTP code, thông báo lỗi và domain nhận trước khi quyết định retry hoặc suppress một địa chỉ email.

Các mã lỗi Hard Bounce và Soft Bounce thường gặp

SMTP response thường gồm mã trạng thái và phần mô tả nguyên nhân. Trong thực tế, nhóm 4.x.x thường liên quan đến lỗi tạm thời, còn nhóm 5.x.x thường phản ánh lỗi lâu dài hoặc thư bị từ chối.

SMTP code	Nguyên nhân thường gặp	Cách xử lý đề xuất
550 5.1.1	Địa chỉ email không tồn tại	Suppress sau khi xác minh
553 5.1.2	Domain hoặc địa chỉ không hợp lệ	Kiểm tra dữ liệu, sau đó suppress nếu cần
450 4.2.1	Mailbox tạm thời không nhận thư	Retry
452 4.2.2	Hộp thư đầy	Retry và theo dõi
421 4.3.0	Hệ thống nhận tạm thời gặp lỗi	Retry
451 4.3.0	Server tạm thời từ chối thư	Retry
4.7.x	Throttling, reputation hoặc policy	Điều tra nguyên nhân trước khi gửi lại
5.7.x	Authentication, security hoặc policy	Kiểm tra sender và cấu hình gửi

Marketer có thể ghi nhớ ba nhóm mã để xử lý nhanh hơn.

• Nhóm 5.1.x thường liên quan đến người nhận. Khi gặp nhóm này, doanh nghiệp nên kiểm tra địa chỉ email, mailbox và domain trước. Nếu hệ thống xác nhận địa chỉ không tồn tại, contact nên được suppress.
• Nhóm 4.x.x thường phản ánh lỗi tạm thời. Doanh nghiệp chưa nên xóa contact mà cần chờ hệ thống retry hoặc kiểm tra tình trạng server, mailbox và giới hạn tốc độ gửi.
• Nhóm 5.7.x thường liên quan đến sender, xác thực hoặc chính sách bảo mật. Khi nhiều email cùng xuất hiện nhóm lỗi này, doanh nghiệp nên kiểm tra SPF, DKIM, DMARC, reputation và chính sách của server nhận trước khi kết luận danh sách email có vấn đề.

Trong thực tế, SMTP code chỉ là điểm bắt đầu để chẩn đoán. Doanh nghiệp nên kết hợp mã lỗi với nội dung phản hồi của server, tỷ lệ bounce theo từng domain và lịch sử gửi để tránh suppress nhầm những contact vẫn còn hợp lệ.

Quy trình xử lý Hard Bounce và Soft Bounce trong Email Marketing

Doanh nghiệp không nên xử lý bounce chỉ bằng cách xóa các địa chỉ bị lỗi sau mỗi chiến dịch. Quy trình hiệu quả cần xác định email nào không còn hợp lệ, lỗi nào chỉ mang tính tạm thời và vấn đề nào thực sự nằm ở hệ thống gửi.

Bước 1: Kiểm tra Bounce Report sau mỗi chiến dịch

Sau khi chiến dịch kết thúc, marketer nên kiểm tra báo cáo bounce thay vì chỉ nhìn tỷ lệ Bounce Rate tổng.

Báo cáo nên có tối thiểu các dữ liệu sau:

• địa chỉ email;

• thời điểm bounce;

• loại Hard Bounce hoặc Soft Bounce;

• SMTP code;

• thông báo lỗi từ server;

• domain người nhận;

• chiến dịch phát sinh lỗi;

• nguồn thu thập contact.

Những dữ liệu này giúp doanh nghiệp xác định lỗi xuất phát từ từng địa chỉ riêng lẻ hay từ một nhóm contact, domain hoặc nguồn dữ liệu cụ thể.

Bước 2: Phân loại Bounce theo SMTP Response

Sau khi lấy dữ liệu, doanh nghiệp nên chia bounce thành ba nhóm để lựa chọn cách xử lý phù hợp.

Nhóm 1: Lỗi vĩnh viễn từ người nhận

Ví dụ:

550 5.1.1
User unknown
Mailbox not found

Nếu server xác nhận mailbox không tồn tại, doanh nghiệp nên suppress địa chỉ ngay và không tiếp tục retry.

Nhóm 2: Lỗi tạm thời từ mailbox hoặc server

Ví dụ:

452 4.2.2
Mailbox full

Trong trường hợp này, địa chỉ email vẫn có thể hoạt động. Doanh nghiệp nên giữ contact, cho phép hệ thống retry và theo dõi những lần gửi tiếp theo.

Nhóm 3: Lỗi liên quan đến reputation hoặc policy

Các phản hồi có thể gồm:

4.7.x
5.7.x
Blocked
Rejected
Spam policy

Với nhóm này, doanh nghiệp không nên xóa contact ngay. Marketer cần kiểm tra SPF, DKIM, DMARC, domain reputation, IP reputation, blocklist, Google Postmaster và sản lượng gửi để xác định nguyên nhân nằm ở sender hay server nhận.

Bước 3: So sánh Bounce Rate theo nhà cung cấp email

Phân tích bounce theo Gmail, Outlook, Yahoo hoặc domain doanh nghiệp giúp marketer xác định vấn đề có xảy ra trên toàn bộ danh sách hay chỉ với một mailbox provider.

Ví dụ:

Gmail: 0,5%
Yahoo: 0,8%
Outlook: 12%

Trong trường hợp này, danh sách chưa chắc có vấn đề. Bounce tập trung ở Outlook cho thấy doanh nghiệp nên kiểm tra Microsoft deliverability, reputation hoặc chính sách nhận thư trước.

Ngược lại, nếu kết quả là:

Gmail: 8%
Yahoo: 7%
Outlook: 9%
Corporate: 10%

bounce xuất hiện đồng đều trên nhiều hệ thống. Khi đó, chất lượng database hoặc nguồn thu thập contact cần được kiểm tra trước.

Bước 4: Phân tích Bounce Rate theo nguồn Lead

Sau khi xác định mailbox provider không phải nguyên nhân chính, doanh nghiệp nên tiếp tục phân tích bounce theo nguồn dữ liệu.

Ví dụ:

Nguồn contact	Bounce Rate
Website đăng ký newsletter	0,8%
Webinar	1,2%
CRM cũ	7,5%
File Sales import	11%

Bảng trên cho thấy vấn đề tập trung ở CRM cũ và dữ liệu Sales import, thay vì toàn bộ danh sách.

Từ đó, doanh nghiệp có thể kiểm tra lại:

• quy trình Sales nhập email;

• validation trên form;

• dữ liệu sau migration;

• tuổi của database;

• nguồn và thời điểm thu thập consent.

Cách phân tích này giúp xử lý nguồn tạo ra bounce, thay vì chỉ xóa email lỗi sau mỗi lần gửi.

Bước 5: Đưa Hard Bounce vào Suppression List ở cấp hệ thống

Một lỗi phổ biến là doanh nghiệp chỉ loại Hard Bounce khỏi chiến dịch vừa gửi nhưng vẫn để contact hoạt động trong các luồng khác.

Ví dụ, một địa chỉ đã Hard Bounce ở:

Campaign A

nhưng vẫn tồn tại trong:

Automation B
Newsletter C
Promotion D
CRM Segment E

Khi đó, hệ thống vẫn có thể tiếp tục gửi tới một địa chỉ đã được xác nhận không hợp lệ.

Cách xử lý đúng là đưa email vào suppression list ở cấp hệ thống để tất cả chiến dịch và automation cùng nhận biết trạng thái này.

Bước 6: Cập nhật trạng thái email thay vì xóa Contact khỏi CRM

Suppress email không đồng nghĩa với việc doanh nghiệp phải xóa toàn bộ hồ sơ khách hàng.

Ví dụ, một contact có:

Email: Hard Bounce
Phone: hợp lệ
Zalo: đã kết nối
Lịch sử mua: 3 đơn hàng

Nếu xóa contact, doanh nghiệp có thể mất cả lịch sử giao dịch và các điểm liên hệ vẫn còn giá trị.

Cách phù hợp hơn là cập nhật:

Email Status = Invalid/Suppressed

sau đó giữ nguyên các dữ liệu còn lại trong CRM. Sales hoặc bộ phận chăm sóc khách hàng có thể sử dụng điện thoại, Zalo hoặc kênh khác để xác minh và cập nhật địa chỉ email mới.

Như vậy, quy trình xử lý bounce hiệu quả không dừng ở việc xóa email lỗi. Doanh nghiệp cần đi từ đọc Bounce Report → xác định SMTP response → phân tích theo mailbox provider và nguồn lead → suppress đúng địa chỉ → cập nhật lại dữ liệu CRM để vừa bảo vệ khả năng gửi email vừa tránh làm mất những khách hàng còn giá trị.

Ví dụ cách xử lý Hard Bounce và Soft Bounce trong thực tế

Giả sử doanh nghiệp gửi 50.000 email và nhận được kết quả:

Delivered: 46.500
Hard Bounce: 1.500
Soft Bounce: 2.000

Doanh nghiệp không nên cộng toàn bộ 3.500 email bị bounce rồi xóa khỏi danh sách. Cách xử lý đúng là phân tích nguyên nhân của từng nhóm.

Trong 1.500 Hard Bounce, giả sử có:

1.100 User Unknown
200 Invalid Domain
200 Policy Block

Doanh nghiệp có thể suppress 1.300 địa chỉ thuộc nhóm User Unknown và Invalid Domain sau khi đã xác minh. Riêng 200 trường hợp Policy Block cần được kiểm tra thêm về reputation, authentication hoặc chính sách của server nhận trước khi loại contact.

Tương tự, với 2.000 Soft Bounce, nếu báo cáo cho thấy:

1.200 Mailbox Full
500 Temporary Server Error
300 Rate Limit

doanh nghiệp chưa nên xóa các địa chỉ này. Đây chủ yếu là lỗi tạm thời và nhiều contact vẫn có khả năng nhận email ở lần gửi sau.

Ví dụ trên cho thấy quản lý bounce cần dựa trên nguyên nhân cụ thể, không nên chỉ dựa vào nhãn Hard Bounce hoặc Soft Bounce.

Cách BizMail hỗ trợ quản lý Hard Bounce và Soft Bounce

BizMail là giải pháp Email Marketing của Bizfly, hỗ trợ doanh nghiệp triển khai chiến dịch, tự động hóa chăm sóc khách hàng và quản lý hoạt động gửi email trên một hệ thống tập trung. Với danh sách lớn, doanh nghiệp có thể theo dõi kết quả gửi và chủ động xử lý những contact gặp lỗi thay vì quản lý thủ công bằng Excel.

Một số tính năng hữu ích trong quá trình kiểm soát Hard Bounce và Soft Bounce gồm:

• Theo dõi trạng thái gửi email: Doanh nghiệp có thể kiểm tra kết quả của chiến dịch để phát hiện các email gửi thất bại và xác định nhóm contact cần xử lý.

• Quản lý danh sách khách hàng tập trung: Contact được quản lý trên hệ thống, giúp doanh nghiệp hạn chế tiếp tục sử dụng những địa chỉ email đã xác định không còn phù hợp.

• Phân nhóm khách hàng: Doanh nghiệp có thể tách các nhóm contact theo trạng thái hoặc điều kiện phù hợp để lựa chọn đối tượng cho từng chiến dịch tiếp theo.

• Email Automation: BizMail hỗ trợ xây dựng các luồng chăm sóc tự động dựa trên hành vi và điều kiện của khách hàng, giúp giảm thao tác gửi thủ công.

• Kết hợp dữ liệu đa kênh trong hệ sinh thái Bizfly: Khi email của khách hàng không còn khả dụng, doanh nghiệp vẫn có thể khai thác các dữ liệu liên hệ khác để tiếp tục chăm sóc qua những điểm chạm phù hợp như Zalo, SMS hoặc CRM.

Thay vì xóa toàn bộ hồ sơ chỉ vì một địa chỉ email bị Hard Bounce, doanh nghiệp nên cập nhật trạng thái email và giữ lại những dữ liệu khách hàng còn giá trị. Cách quản lý này vừa giúp duy trì danh sách gửi sạch, vừa hạn chế bỏ sót cơ hội chăm sóc và chuyển đổi khách hàng.

Muốn quản lý danh sách Email Marketing hiệu quả hơn và hạn chế gửi tới các địa chỉ không còn giá trị? Hãy trải nghiệm BizMail để theo dõi chiến dịch, quản lý contact và tự động hóa hoạt động chăm sóc khách hàng trên một nền tảng tập trung.

Câu hỏi thường gặp về Hard Bounce và Soft Bounce

• Hard Bounce có nên loại khỏi danh sách ngay không? Nếu SMTP response xác nhận địa chỉ không tồn tại, mailbox bị vô hiệu hóa vĩnh viễn hoặc domain không hợp lệ, doanh nghiệp nên ngừng gửi và đưa email vào suppression list. Tuy nhiên, không nhất thiết phải xóa toàn bộ hồ sơ khách hàng khỏi CRM nếu contact vẫn còn dữ liệu hoặc lịch sử giao dịch có giá trị.
• Soft Bounce có nên xóa khỏi danh sách không? Không nên xóa contact chỉ sau một lần Soft Bounce. Doanh nghiệp cần kiểm tra SMTP response và theo dõi những lần gửi tiếp theo vì lỗi có thể chỉ đến từ mailbox đầy, server tạm thời gặp sự cố hoặc throttling.

• Soft Bounce bao nhiêu lần thì nên suppress? Không có một ngưỡng chung áp dụng cho mọi ESP. Doanh nghiệp nên cân nhắc temporary suppression khi Soft Bounce xảy ra liên tiếp nhiều lần trong thời gian ngắn và không có lần delivery thành công xen giữa.

• Lỗi 550 5.1.1 là Hard Bounce hay Soft Bounce? 550 5.1.1 thường là Hard Bounce và cho biết địa chỉ người nhận không tồn tại hoặc không thể được tìm thấy. Nếu server xác nhận đây là lỗi recipient permanent failure, doanh nghiệp nên suppress địa chỉ đó.

• Bounce Rate cao có ảnh hưởng đến Email Deliverability không? Có. Bounce Rate cao, đặc biệt là Hard Bounce, có thể là tín hiệu cho thấy danh sách email kém chất lượng hoặc quy trình quản lý contact chưa tốt. Tuy nhiên, cần kết hợp thêm sender reputation, complaint rate, authentication và engagement trước khi kết luận nguyên nhân.

Kết luận

Hard Bounce và Soft Bounce cần được xử lý theo nguyên nhân thay vì áp dụng một quy tắc chung. Hard Bounce do địa chỉ không tồn tại nên được suppress sớm, còn Soft Bounce cần theo dõi thêm SMTP response và lịch sử gửi. Xử lý đúng giúp doanh nghiệp làm sạch danh sách mà không loại nhầm những khách hàng còn giá trị. Đồng thời, kiểm soát Bounce Rate tốt cũng góp phần bảo vệ sender reputation và cải thiện khả năng email vào Inbox.