Tại sao Email bạn Chuyển tiếp cho chính mình lại Rơi vào Spam

Thiết lập chuyển tiếp tự động từ tài khoản cũ của bạn sang cái mới, và một số thư sẽ lặng lẽ biến mất vào spam — không phải vì nhà cung cấp của bạn bị hỏng, mà vì chuyển tiếp viết lại người gửi tin nhắn mà không viết lại bằng chứng mật mã. SPF kiểm tra máy chủ sai, kết quả DMARC lật sang trạng thái thất bại, và một email hợp pháp bạn gửi cho chính mình bị cách ly. Cách khắc phục có một cái tên: ARC, được định nghĩa trong RFC 8617 từ năm 2019.

Tại sao chuyển tiếp khiến thư của tôi thất bại SPF?

Vì SPF kiểm tra máy chủ cuối cùng đã chuyển tiếp tin nhắn, và chuyển tiếp thay đổi máy chủ đó. SPF — Sender Policy Framework — là một bản ghi DNS liệt kê những địa chỉ IP nào được phép gửi thư cho một miền. Khi bank.com gửi cho bạn một biên lai, máy chủ nhận kiểm tra: nó có đến từ IP mà bank.com được phép không? Có. Thông qua.

Bây giờ chuyển tiếp biên lai đó từ Gmail của bạn sang địa chỉ mới. Máy chủ của Google chuyển tiếp nó tiếp. Máy chủ nhận cuối cùng chạy kiểm tra SPF và hỏi: Google có được phép gửi cho bank.com không? Không, nó không được. SPF thất bại. Tài liệu Workspace của chính Google giải thích điều này rõ ràng — những thư được chuyển tiếp thất bại SPF vì máy chủ chuyển tiếp không nằm trong bản ghi SPF của miền ban đầu. Không có gì bị giả mạo. Kiểm tra chỉ đang nhìn vào hop sai.

Vì vậy tại sao điều đó lại gửi nó vào spam?

DMARC. SPF thất bại một mình từng có thể sống được; DMARC biến nó thành một kết quả. DMARC liên kết SPF và DKIM lại với nhau và nói với các bộ nhận phải làm gì khi cả hai đều thất bại: không làm gì, cách ly, hoặc từ chối. Đến năm 2024, các nhà gửi lớn không có lựa chọn — Google và Yahoo bắt đầu yêu cầu DMARC từ bất kỳ ai gửi hơn 5.000 thư mỗi ngày cho người dùng của họ.

DKIM, trụ cột kia, là một chữ ký được nội dung vào tin nhắn. Về mặt lý thuyết nó sống được qua chuyển tiếp, vì nó ký vào nội dung, không phải tuyến đường. Trong thực tế, bất cứ điều gì chạm vào tin nhắn đều làm hỏng nó. Một danh sách gửi thư nào đó nối thêm chân trang "bạn đã đăng ký, hủy đăng ký tại đây", một máy chủ viết lại dòng chủ đề, thậm chí một thay đổi trong cách một dòng bao — chữ ký không còn khớp nữa, và DKIM cũng thất bại. Bây giờ cả hai trụ cột đều sụp đổ, DMARC nói thất bại, và biên lai của chính bạn lại ở thư mục rác.

ARC là gì và nó thực sự khắc phục được điều này không?

ARC — Authenticated Received Chain, RFC 8617 — cho phép một người chuyển tiếp trung thực bảo vệ rằng thư đã vượt qua xác thực trước khi nó chạm vào nó. Máy chủ chuyển tiếp đóng dấu tin nhắn bằng một bản ghi niêm phong nói "khi cái này đến tôi, SPF và DKIM là hợp lệ — tin lời tôi cho phần bạn không thể xác minh." Người nhận cuối cùng, nếu nó tin tưởng người chuyển tiếp đó, có thể bỏ qua lỗi DMARC và gửi.

Điểm khó là "nếu nó tin tưởng." ARC không phải là một mật khẩu; nó là một hệ thống danh tiếng. Người nhận cân nhắc xem người niêm phong ARC có phải là một nhà điều hành được biết đến, hành xử tốt hay không. Google vừa đóng dấu tiêu đề ARC vừa tôn trọng chúng từ những người gửi nó tin tưởng, đó là lý do tại sao một chuyển tiếp từ Gmail đến Gmail thường sống được trong khi một chuyển tiếp qua một số relay đại học cổ xưa thì không.

Nếu bạn tự chạy chuyển tiếp, hai động thái cụ thể sẽ giúp. Sử dụng Server-Side Redirect / viết lại kiểu SRS nếu máy chủ của bạn cung cấp nó, cái này viết lại người gửi phong bì để kiểm tra SPF chống lại máy chủ chuyển tiếp của bạn thay vì miền ban đầu. Và ưu tiên chuyển tiếp giữa các nhà cung cấp đều hỗ trợ ARC. Nếu bạn đang hợp nhất tài khoản và muốn đích đến chỉ cần xử lý mớ xác thực cho bạn, đó chính xác là loại hệ thống ống nước mà một nền tảng email AI được xây dựng để hấp thụ.

Khi nào tôi nên ngừng đổ lỗi cho nhà cung cấp của tôi?

Khi mô hình là "chỉ thư được chuyển tiếp mới thất bại," nhà cung cấp đang làm công việc của nó một cách chính xác — giao thức mới là vấn đề. Đây là dấu hiệu: mở tiêu đề của tin nhắn còn thiếu và tìm dòng Authentication-Results. Nếu bạn thấy spf=fail cùng với một IP gửi thuộc về một người chuyển tiếp hơn là người gửi ban đầu, đó là SPF kiểm tra hop sai. Nếu dkim=fail xuất hiện trên thư đi qua một danh sách hoặc một relay chỉnh sửa thư, đó là một chữ ký bị làm hỏng, không phải một giả mạo.

Sự thật không thoải mái là xác thực email đã bị dán trên, từng lớp, trong hai thập kỷ vào một hệ thống không bao giờ giả định ai đó sẽ nói dối. SPF đến năm 2006, DKIM năm 2007, DMARC năm 2015, ARC năm 2019 — mỗi cái vá một lỗ hổng cái cuối cùng mở ra. Chuyển tiếp là mối nối nơi tất cả bốn mài nhau, và hộp thư của bạn là nơi bạn cảm thấy sự ma sát.