Vì sao việc gửi email giao dịch là một con quái vật khác
Có một sự phân biệt quan trọng giữa email tiếp thị và email giao dịch mà nhiều nhà phát triển bỏ lỡ khi họ lần đầu bắt đầu nghĩ nghiêm túc về khả năng gửi đến (deliverability). Email tiếp thị — bản tin, chiến dịch quảng bá, thông báo — đi đến những người đăng ký đã đồng ý nhận. Chúng có thể chịu được sự chậm trễ thỉnh thoảng và thậm chí việc thỉnh thoảng bị đưa vào thư mục spam. Nếu một bản tin vào spam đối với 2% danh sách của bạn, điều đó đáng tiếc nhưng doanh nghiệp của bạn vẫn tiếp tục.
Email giao dịch thì hoàn toàn khác. Liên kết xác minh, đặt lại mật khẩu, xác nhận mua hàng, mã xác thực hai yếu tố, cảnh báo bảo mật tài khoản — những thứ này đến vào những thời điểm quan trọng trong hành trình của người dùng. Một email đặt lại mật khẩu vào spam nghĩa là người dùng của bạn bị khóa khỏi tài khoản của họ và có khả năng sẽ gửi một yêu cầu hỗ trợ hoặc, tệ hơn, không bao giờ quay lại. Một email xác minh vào spam nghĩa là một người dùng mới không thể hoàn tất đăng ký và phễu thu hút người dùng của bạn có một rò rỉ âm thầm, vô hình.
Vậy mà, email giao dịch lại thường được thiết lập kém cẩn thận hơn các chiến dịch tiếp thị. Nhiều nhà phát triển dùng bất kỳ đoạn mã gửi email nào mà framework của họ cung cấp, cấu hình nó với một máy chủ SMTP dùng chung, triển khai nó, kiểm thử một lần với hộp thư của chính họ — thứ có ngưỡng spam rộng lượng — rồi đi tiếp. Các vấn đề chỉ lộ ra khi người dùng thật trên Gmail, Outlook, hay Yahoo báo cáo email bị thiếu. Đến lúc đó, vấn đề đã âm thầm thất bại trong sản xuất suốt nhiều tuần.
SPF: nền tảng của xác thực email
Sender Policy Framework (SPF) là một bản ghi DNS TXT trên miền gửi của bạn cho cả thế giới biết những máy chủ thư nào được ủy quyền gửi email thay mặt bạn. Khi Gmail nhận một email được cho là từ [email protected], nó thực hiện một tra cứu DNS cho bản ghi SPF của miền bạn. Nếu địa chỉ IP của máy chủ thực sự đã gửi email đó được liệt kê trong bản ghi SPF của bạn, email đó vượt qua SPF. Nếu không có bản ghi SPF nào cả — hoặc máy chủ gửi không được liệt kê — email đó bị đối xử với sự nghi ngờ ngay cả trước khi bất kỳ đánh giá nội dung nào bắt đầu.
Thiết lập SPF khá đơn giản một khi bạn biết mình đang làm gì. Thêm một bản ghi TXT vào DNS của miền bạn. Giá trị phụ thuộc vào nhà cung cấp gửi thư của bạn. Nếu bạn dùng SendGrid: v=spf1 include:sendgrid.net ~all. Nếu bạn dùng AWS SES: v=spf1 include:amazonses.com ~all. Nếu bạn dùng Mailgun: v=spf1 include:mailgun.org ~all. Tài liệu của nhà cung cấp của bạn sẽ cho bạn giá trị include chính xác. Hậu tố ~all là một "soft fail" — email từ các máy chủ không được liệt kê bị đánh dấu nhưng không bị từ chối thẳng thừng. Một khi bạn tự tin rằng bản ghi SPF của bạn đầy đủ và đúng, bạn có thể nâng cấp lên -all (hard fail), lệnh này chỉ thị cho các máy chủ nhận từ chối hoàn toàn thư không được ủy quyền.
Một cạm bẫy phổ biến: giới hạn 10 lần tra cứu DNS. Các bản ghi SPF nối nhiều chỉ thị include: lại với nhau có thể vượt quá giới hạn này, khiến SPF thất bại ngay cả khi tất cả máy chủ của bạn về mặt kỹ thuật đều được liệt kê. Hãy dùng MXToolbox để kiểm tra bản ghi SPF của bạn — nó sẽ đánh dấu các vấn đề về số lần tra cứu một cách rõ ràng. Việc hiểu SPF, DKIM, và DMARC liên hệ với nhau như thế nào được trình bày kỹ trong tài liệu của SendGrid về xác thực email.
DKIM: bằng chứng mật mã rằng email của bạn không bị giả mạo
DomainKeys Identified Mail (DKIM) thêm một chữ ký mật mã vào mỗi email bạn gửi. Chữ ký được tạo bằng một khóa riêng do nhà cung cấp gửi thư của bạn giữ, và các máy chủ thư nhận xác minh nó dựa trên một khóa công khai mà bạn công bố như một bản ghi DNS TXT. Nếu chữ ký hợp lệ, hai điều được chứng minh: email thực sự bắt nguồn từ hạ tầng gửi thư của bạn, và nội dung không bị sửa đổi giữa lúc gửi và lúc nhận.
Không cấu hình DKIM, việc các tác nhân độc hại giả mạo miền của bạn trở nên dễ dàng hơn đáng kể — gửi những email trông như đến từ [email protected] nhưng thực ra được gửi bởi một người hoàn toàn khác. Đây là cách các chiến dịch lừa đảo hoạt động. Các bộ lọc spam cũng biết điều này, đó là lý do một email thiếu chữ ký DKIM hợp lệ từ một miền đáng lẽ phải có bị đối xử với sự nghi ngờ cao hơn. Spamhaus và các dịch vụ uy tín khác đưa lịch sử ký DKIM vào điểm uy tín của miền.
Thiết lập DKIM được thực hiện thông qua nhà cung cấp gửi thư của bạn. Họ tạo một cặp khóa, giữ khóa riêng trên hạ tầng của họ, và cấp cho bạn một khóa công khai để thêm vào DNS của bạn như một bản ghi TXT. Một khi bản ghi DNS đó được công bố và lan truyền, mỗi email họ gửi thay mặt bạn sẽ tự động mang một chữ ký DKIM hợp lệ. Hầu hết các nhà cung cấp lớn — SendGrid, Mailgun, Amazon SES, Postmark — hướng dẫn bạn qua quy trình này trong quá trình thiết lập ban đầu. Nếu bạn đã bỏ qua nó, hãy quay lại và cấu hình ngay bây giờ.
DMARC: lớp chính sách gắn kết mọi thứ lại với nhau
DMARC (Domain-based Message Authentication, Reporting, and Conformance) xây dựng dựa trên SPF và DKIM bằng cách định nghĩa các máy chủ nhận nên làm gì khi một email không vượt qua các kiểm tra đó. Nó cũng giới thiệu "sự căn chỉnh" (alignment) — yêu cầu miền trong tiêu đề From của email thực sự khớp với miền đã vượt qua SPF hoặc DKIM. Điều này ngăn kẻ tấn công vượt qua kiểm tra SPF trên một miền trong khi giả mạo một miền khác ở địa chỉ From hiển thị.
Cách tiếp cận đúng đắn với DMARC là bắt đầu từ từ. Hãy bắt đầu với một chính sách chỉ-giám-sát: v=DMARC1; p=none; rua=mailto:[email protected]. p=none bảo các máy chủ nhận không hành động đối với các thất bại, chỉ gửi cho bạn các báo cáo. Những báo cáo tổng hợp đó sẽ cho bạn biết máy chủ nào đang gửi email thay mặt bạn và liệu chúng có vượt qua SPF và DKIM không. Hãy xem xét chúng trong vài tuần trước khi thực hiện bất kỳ thay đổi chính sách nào.
Một khi bạn tự tin mọi thứ hợp lệ đều vượt qua, hãy chuyển sang p=quarantine (email thất bại đi vào thư mục spam) và cuối cùng p=reject (email thất bại bị từ chối thẳng thừng). Quá trình chuyển tiếp này bảo vệ uy tín của miền bạn khỏi việc giả mạo trong khi cho bạn thời gian để bắt được bất kỳ nguồn email hợp lệ nào bạn có thể đã bỏ lỡ. Một chính sách DMARC p=reject kết hợp với SPF và DKIM vượt qua khiến kẻ tấn công gần như không thể mạo danh miền của bạn một cách hiệu quả.
Uy tín IP: vì sao máy chủ gửi của bạn quan trọng
Ngay cả với SPF, DKIM, và DMARC hoàn hảo, email của bạn vẫn có thể vào spam nếu địa chỉ IP mà chúng được gửi đi có uy tín kém. Các máy chủ thư nhận duy trì — hoặc tham vấn các dịch vụ bên thứ ba duy trì — danh sách chặn và điểm uy tín cho các địa chỉ IP gửi. Một IP có lịch sử gửi spam, hoặc xuất hiện trong danh sách chặn được duy trì bởi các dịch vụ như Spamhaus, sẽ có email đi ra của nó bị đối xử với sự nghi ngờ bất kể thiết lập xác thực của bạn.
Nếu bạn dùng một địa chỉ IP dùng chung từ một nhà cung cấp hosting dùng chung hoặc một dịch vụ SMTP giá rẻ, uy tín của bạn bị ràng buộc với tất cả những người khác dùng cùng IP đó. Một kẻ gửi spam trên cùng nhóm dùng chung có thể phá hủy khả năng gửi đến cho tất cả người gửi trên IP đó. Đây là một trong những lập luận mạnh nhất cho việc dùng một nhà cung cấp email giao dịch chuyên dụng — SendGrid, Amazon SES, Postmark, Mailgun — thay vì gửi email trực tiếp từ máy chủ ứng dụng của bạn hoặc qua một dịch vụ SMTP dùng chung.
Trên một IP gửi mới, bạn cũng sẽ cần "làm nóng" IP một cách từ từ. Gửi một đợt tăng đột ngột về khối lượng email từ một IP mới trông như hành vi spam đối với các máy chủ nhận. Hãy bắt đầu với khối lượng thấp hơn và tăng dần trong nhiều ngày hoặc nhiều tuần. Hầu hết các nhà cung cấp email chuyên dụng xử lý việc làm nóng IP một cách tự động nếu bạn ở trên một nhóm gửi dùng chung, hoặc cung cấp lịch làm nóng IP nếu bạn dùng một IP chuyên dụng.
Nội dung và dòng chủ đề: điều gì kích hoạt bộ lọc
Ngoài xác thực và uy tín IP, bản thân nội dung email của bạn cũng được các bộ lọc spam đánh giá. Một số mẫu nhất định kích hoạt phân loại spam một cách đáng tin cậy. Các từ kích hoạt spam trong dòng chủ đề — "MIỄN PHÍ", "BẢO ĐẢM", "HÀNH ĐỘNG NGAY", quá nhiều dấu chấm than, VIẾT HOA TOÀN BỘ — là những thứ hiển nhiên mà hầu hết các nhà phát triển tránh. Ít hiển nhiên hơn: các dòng chủ đề quá mơ hồ ("Thông điệp quan trọng dành cho bạn"), quá khẩn cấp ("Tài khoản của bạn sẽ bị đóng"), hoặc quá mang tính quảng bá đối với thứ đáng lẽ là một email giao dịch.
Tỷ lệ văn bản trên hình ảnh cũng quan trọng. Một email chủ yếu là hình ảnh với văn bản tối thiểu là một mẫu spam kinh điển — những kẻ gửi hàng loạt dùng hình ảnh để che giấu từ khóa khỏi các bộ lọc dựa trên văn bản. Email giao dịch nên chủ yếu dựa trên văn bản với hình ảnh tối thiểu. HTML bị lỗi — thẻ chưa đóng, thuộc tính sai định dạng — là một dấu hiệu cảnh báo khác. Luôn gửi một phiên bản văn bản thuần túy kèm với phiên bản HTML của bạn. Các bộ lọc spam nhìn email chỉ-HTML với sự nghi ngờ cao hơn, và các hệ thống email doanh nghiệp thường loại bỏ HTML hoàn toàn.
Kiểm thử việc gửi email của bạn — theo cách đúng đắn
Phương pháp kiểm thử nhanh nhất và thực tế nhất cho việc gửi email là: gửi một email thử tới một hộp thư temp mail mới và kiểm tra cả thư mục hộp thư đến lẫn thư mục spam. Điều này cho bạn phản hồi tức thì, rõ ràng về việc email của bạn có đến được hộp thư hay bị lọc ra. Không giống việc kiểm thử bằng tài khoản Gmail của chính bạn — nơi có thể đã đưa bạn vào danh sách trắng như một người gửi thường xuyên — một địa chỉ tạm thời mới không có lịch sử trước đó với miền của bạn, điều này mô phỏng chính xác hơn trải nghiệm tiếp xúc lần đầu của một người dùng mới.
Bạn nên kiểm thử việc gửi mỗi khi bạn thay đổi bất cứ điều gì có thể ảnh hưởng đến nó: chuyển đổi nhà cung cấp email, cập nhật đáng kể mẫu HTML của bạn, thay đổi miền gửi, thêm một miền phụ gửi mới, hoặc triển khai lên một môi trường mới (staging, sản xuất). Nó mất hai phút và cho bạn bằng chứng dứt khoát. Phương án thay thế — chờ người dùng báo cáo vấn đề — nghĩa là các vấn đề về khả năng gửi đến của bạn đã âm thầm thất bại suốt một khoảng thời gian không xác định.
Ngoài việc kiểm tra hộp thư đến/spam, hãy dùng công cụ kiểm tra sức khỏe email của MXToolbox để kiểm tra sức khỏe tổng thể của miền bạn: SPF, DKIM, DMARC, trạng thái danh sách đen, và cấu hình bản ghi MX tất cả ở một nơi. Hãy biến điều này thành một phần trong danh sách kiểm tra trước-khi-ra-mắt của bạn cho bất kỳ ứng dụng hoặc miền gửi mới nào. Cũng hãy kiểm tra các hướng dẫn của OWASP về các thực hành tốt nhất cho email liên quan đến bảo mật.
Tỷ lệ trả lại và khiếu nại spam: những chỉ số quan trọng
Hai chỉ số có ảnh hưởng ngoại cỡ đến khả năng gửi đến dài hạn: tỷ lệ trả lại (bounce rate) và tỷ lệ khiếu nại spam. Một tỷ lệ trả lại trên 2% cho các máy chủ nhận và nhà cung cấp gửi thư của bạn biết rằng bạn đang gửi tới rất nhiều địa chỉ không hợp lệ hoặc không tồn tại — đó là một mẫu gắn liền với các danh sách email được mua và các hoạt động spam. Ngay cả khi bạn làm mọi thứ khác đúng, một tỷ lệ trả lại cao sẽ gây ra các vấn đề về khả năng gửi đến. Hãy gỡ các trả lại cứng (hard bounce) khỏi danh sách gửi của bạn ngay lập tức và vĩnh viễn.
Một tỷ lệ khiếu nại spam trên 0,1% (một khiếu nại trên mỗi nghìn email được gửi) là ngưỡng mà hầu hết các nhà cung cấp gửi thư sẽ bắt đầu hạn chế tài khoản của bạn. Postmaster Tools của Gmail báo cáo tỷ lệ khiếu nại trực tiếp nếu bạn đã thiết lập nó. Hãy theo dõi các chỉ số này qua bảng điều khiển của nhà cung cấp gửi thư của bạn. Nếu tỷ lệ khiếu nại đang tăng, hãy điều tra vì sao — liệu bạn có đang gửi tới những người dùng không đồng ý một cách rõ ràng không? Email của bạn có quá thường xuyên không? Có sự không khớp nào giữa điều người dùng mong đợi và điều họ đang nhận được không?
Danh sách kiểm tra khả năng gửi đến đầy đủ
- Bản ghi SPF: Bản ghi DNS TXT trên miền gửi của bạn liệt kê tất cả máy chủ gửi được ủy quyền. Kiểm tra bằng MXToolbox.
- DKIM: Việc ký mật mã được cấu hình qua nhà cung cấp gửi thư của bạn, khóa công khai được công bố trong DNS.
- DMARC: Bắt đầu với giám sát
p=none, tiến tớip=quarantinerồip=rejectsau khi xem xét các báo cáo tổng hợp. - Nhà cung cấp gửi chuyên dụng: Dùng SendGrid, SES, Postmark, hoặc Mailgun — không phải máy chủ ứng dụng của bạn hay SMTP dùng chung.
- Dòng chủ đề sạch: Cụ thể, liên quan, không có từ kích hoạt, không có dấu câu hay chữ hoa quá mức.
- HTML + văn bản thuần túy: Luôn kèm cả hai. Không bao giờ gửi email chỉ-HTML.
- Không dùng công cụ rút gọn URL: Dùng các URL đầy đủ, trực tiếp trong phần thân email và các liên kết xác minh.
- Liên kết hủy đăng ký: Kèm theo ngay cả trong email giao dịch nơi thích hợp — một số nhà cung cấp yêu cầu nó.
- Địa chỉ vật lý: Được yêu cầu bởi CAN-SPAM và các quy định tương tự ở nhiều khu vực tài phán.
- Xử lý trả lại cứng: Gỡ ngay lập tức; không bao giờ thử lại một trả lại cứng.
- Giám sát khiếu nại: Thiết lập Gmail Postmaster Tools; theo dõi bảng điều khiển tỷ lệ khiếu nại.
- Kiểm thử hộp thư đến: Gửi email thử tới các hộp thư tạm thời mới trước mỗi lần triển khai và sau bất kỳ thay đổi mẫu hoặc cấu hình nào.
- Kiểm tra sức khỏe MXToolbox: Kèm vào danh sách kiểm tra trước-khi-ra-mắt của bạn cho mỗi miền và môi trường mới.
Khi nào nên dùng một dịch vụ email giao dịch chuyên dụng
Nếu ứng dụng của bạn gửi bất kỳ email nào mà người dùng cần nhận để hoạt động — liên kết xác minh, đặt lại mật khẩu, xác nhận mua hàng — bạn nên dùng một nhà cung cấp email giao dịch chuyên dụng ngay từ ngày đầu tiên. Chi phí thấp (thường miễn phí tới hàng chục nghìn email mỗi tháng), độ tin cậy tốt hơn đáng kể so với SMTP tự làm, và hạ tầng khả năng gửi đến — các nhóm IP dùng chung với uy tín được quản lý, ký DKIM tự động, xử lý trả lại và khiếu nại — được duy trì bởi các đội mà toàn bộ công việc của họ là giữ email nằm trong hộp thư.
Sai lầm tự-làm phổ biến nhất là chạy một máy chủ thư trên cùng IP với ứng dụng web của bạn, hoặc dùng dịch vụ SMTP đi kèm của một nhà cung cấp hosting giá rẻ. Các IP này thường xuyên bị thêm vào danh sách chặn bởi các dịch vụ như Spamhaus vì môi trường hosting được chia sẻ với những tác nhân xấu. Chuyển sang một nhà cung cấp giao dịch chuyên dụng thường là công việc của một buổi chiều và có tác động tích cực tức thì lên khả năng gửi đến. Đó là một trong những cải tiến hạ tầng có đòn bẩy cao nhất mà một đội nhỏ có thể thực hiện. Các đội có ý thức về quyền riêng tư cũng nên xem lại hướng dẫn từ Electronic Frontier Foundation về việc xử lý dữ liệu người dùng một cách có trách nhiệm khi email có liên quan. Ngoài ra, việc giám sát các địa chỉ dựa trên các cơ sở dữ liệu vi phạm đã biết qua Have I Been Pwned có thể bổ sung cho việc ngăn chặn gian lận của bạn khi các tài khoản mới được tạo.