Email từ tên miền của bạn
Bot có thể gửi email cho khách hàng của bạn — từ một địa chỉ trên tên miền của bạn, ví dụ noreply@example.com. Nhưng thư lại được gửi đi từ máy chủ của chúng tôi. Vì vậy, trước lần gửi đầu tiên bạn cần thêm một lần ba bản ghi vào DNS của tên miền. Dưới đây: vì sao cần, thêm chính xác cái gì và điều gì xảy ra sau đó.
Vì sao không có bản ghi DNS thì thư không tới
Hãy nhìn từ phía bên nhận — Gmail, Outlook hay máy chủ thư của khách hàng bạn. Họ nhận được một lá thư tự nhận là từ tên miền của bạn, nhưng lại đến từ một máy chủ không thuộc tên miền đó. Đó đúng là hình ảnh của một thư giả mạo: phishing hoạt động y như vậy.
Cách duy nhất để bên nhận phân biệt là hỏi chính tên miền: «người gửi này có thực sự hành động nhân danh bạn không?» Câu trả lời bạn công bố trong DNS của tên miền mình, bởi DNS là nơi duy nhất chỉ bạn định đoạt — và vì thế là nơi duy nhất bên nhận tin.
Chừng nào chưa có câu trả lời đó, một máy chủ thư nghiêm túc buộc phải coi lá thư là đáng ngờ. Tốt nhất là vào Spam; tệ nhất là bị từ chối và người nhận không bao giờ biết tới nó.
Vậy nên ba bản ghi bên dưới không phải thủ tục hình thức hay một ô đánh dấu trong giao diện. Chúng chính là sự cho phép của bạn.
Ba bản ghi và vai trò của từng cái
DKIM — chữ ký chứng minh tính xác thực
DKIM là chữ ký mật mã gắn vào mọi thư gửi đi. Nền tảng tạo cho tên miền của bạn một cặp khóa: khóa riêng ở lại chỗ chúng tôi và ký thư, khóa công khai bạn công bố trong DNS. Bên nhận lấy khóa công khai từ DNS của bạn và kiểm tra chữ ký. Khớp nghĩa là thư do người giữ khóa riêng gửi và nội dung không bị thay đổi dọc đường.
Không có DKIM: không có gì để kiểm tra chữ ký. Thư trông như không ký, không đáng tin, và không thiết lập nào bù đắp được. DKIM là quan trọng nhất trong ba bản ghi.
SPF — những máy chủ nào được gửi nhân danh bạn
SPF trả lời câu hỏi khác: từ những máy chủ nào thì thư của tên miền này được chấp nhận. Đó là danh sách nguồn — máy chủ thư của hosting, các dịch vụ gửi thư bạn đang dùng, và để bot có thể viết, máy chủ gửi của chúng tôi.
Không có SPF: thư đến từ máy chủ mà tên miền của bạn «không biết». Với bộ lọc, đó là dấu hiệu giả mạo kinh điển và cộng dồn với mọi nghi ngờ khác.
DMARC — bên nhận phải làm gì khi kiểm tra thất bại
DKIM và SPF trả lời «thư có thật không». DMARC trả lời câu tiếp theo: làm gì nếu không. Đó là chỉ dẫn của bạn cho bên nhận — không làm gì và chỉ gửi báo cáo, đưa vào spam, hoặc từ chối. DMARC cũng là địa chỉ mà bên nhận gửi báo cáo tổng hợp về thư nhân danh bạn, kể cả những nỗ lực giả mạo của kẻ khác.
Hãy bắt đầu với chính sách nhẹ nhất, «chỉ báo cáo». Siết chặt về sau, khi bạn chắc rằng mọi người gửi hợp lệ của mình (kế toán, CRM, bản tin, bot này) đều vượt qua kiểm tra. Chính sách nghiêm bật quá sớm sẽ bắt đầu ăn chính thư của bạn.
Không có DMARC: mỗi bên nhận tự quyết theo cách riêng, còn bạn không bao giờ biết điều gì xảy ra với thư nhân danh mình.
Thêm những bản ghi nào
Trước hết hãy thêm tên miền trong bảng điều khiển: mục Email → «Sending domains» → nút «Add domain». Hộp thoại có ba ô: bản thân tên miền (ví dụ shop.example.com), phần cục bộ của địa chỉ (phần trước @, thường là noreply) và tên người gửi mà người nhận nhìn thấy thay cho địa chỉ. Lưu xong, các bản ghi DNS của bạn hiện ra trên màn hình.
Cả ba đều là bản ghi TXT trong DNS tên miền của bạn. Thêm ở nơi bạn quản lý tên miền: bảng điều khiển của nhà đăng ký hoặc nhà cung cấp DNS.
Các giá trị bên dưới lấy example.com làm ví dụ — hãy thay bằng tên miền của bạn. Giá trị chính xác cho tên miền của bạn hiển thị trên thẻ tên miền trong bảng điều khiển — hãy sao chép từ đó, nhất là DKIM: giá trị của nó chứa khóa công khai của riêng bạn, mỗi tên miền một khác và không thể lấy từ tài liệu.
Trên màn hình, mỗi bản ghi được tách thành hai ô riêng — «Host» và «Value» — mỗi ô có nút «Copy» riêng. Hãy sao chép từng ô một vào các ô tương ứng ở nhà cung cấp DNS: hai phần này không dán được thành một khối.
| Loại | Tên bản ghi (host) | Giá trị |
|---|---|---|
| TXT | mybot._domainkey.example.com | v=DKIM1; k=rsa; p= và tiếp theo là khóa dài lấy từ bảng điều khiển |
| TXT | example.com (gốc tên miền) | v=spf1 include:esp.getmybot.dev ~all |
| TXT | _dmarc.example.com | v=DMARC1; p=none; rua=mailto:dmarc@example.com |
Hai chỗ hay vấp nhất:
- Nhiều bảng điều khiển tự nối tên miền vào tên bản ghi. Nếu ô tên đã hiện «.example.com», hãy chỉ nhập
mybot._domainkeychứ không nhập tên đầy đủ, nếu không sẽ thànhmybot._domainkey.example.com.example.com. - Giá trị DKIM rất dài và không được chứa ngắt dòng hay dấu cách bên trong khóa. Hãy sao chép bằng nút bấm, đừng bôi đen bằng chuột.
Nếu tên miền đã có bản ghi SPF
Một tên miền chỉ được có một bản ghi SPF. Nếu bạn đã gửi thư qua hosting, CRM hay dịch vụ bản tin khác thì bản ghi đó đã tồn tại. Đừng thêm cái thứ hai — hãy viết thêm một include vào bản ghi hiện có, trước ~all ở cuối:
v=spf1 include:spf.nhacungcap.vn include:esp.getmybot.dev ~all
Hai bản ghi SPF trên một tên miền là lỗi giống hệt như không có: kiểm tra không đạt, vì bên nhận không biết phải tin cái nào.
Lưu ý: được «bao phủ» qua bản ghi của người khác là chưa đủ. Ngay cả khi nhà cung cấp hiện tại của bạn có bao gồm chúng tôi trong SPF của họ, include của chúng tôi vẫn phải nằm trực tiếp trong bản ghi của bạn — lý do ở phần xác minh tên miền bên dưới.
Vì sao dùng include chứ không phải địa chỉ IP
Lỗi thường gặp nhất là dán một địa chỉ IP nhìn thấy trong tiêu đề thư hay trên diễn đàn. Đừng làm thế.
include:esp.getmybot.dev là con trỏ tới danh sách máy chủ gửi do chính chúng tôi duy trì. Hôm nay tên đó trỏ tới một máy chủ chuyển tiếp duy nhất. Ngày mai chúng có thể nhiều hơn, có thể chuyển chỗ hoặc bị thay. Khi đó chúng tôi cập nhật danh sách ở phía mình và bản ghi của bạn vẫn chạy, không cần đụng tới gì cả. Toàn bộ ý nghĩa nằm ở đây: địa chỉ đổi ở một nơi duy nhất chứ không phải trong DNS của từng khách hàng.
Một địa chỉ IP viết tay sẽ đơn giản là không còn đúng vào lúc đó. Thư bắt đầu trượt SPF mà không hề có cảnh báo — không lỗi trong bảng điều khiển, không thông báo. Bạn sẽ biết từ những khách hàng «chẳng nhận được gì».
Hãy viết đúng include:esp.getmybot.dev và đừng thêm gì vào đó.
Xác minh tên miền
Xác minh tên miền là việc nền tảng tự nhìn vào DNS tên miền của bạn và xác nhận cả ba bản ghi đều ổn. Nếu cả ba đạt, tên miền chuyển sang trạng thái đã xác minh và việc gửi được cho phép. Chừng nào còn một bản ghi chưa đạt, tên miền vẫn chờ.
Thứ được kiểm tra nhiều hơn là «bản ghi có tồn tại»:
| Bản ghi | Thực chất kiểm tra điều gì |
|---|---|
| DKIM | Bản ghi đã công bố và chứa khóa công khai của chính bạn. DKIM của người khác, hoặc cũ từ khóa trước, đều không đạt. |
| SPF | Bản ghi tồn tại và chứa trực tiếp include:esp.getmybot.dev. Những giá trị na ná như include:esp.getmybot.dev.ten-mien-khac.example không được tính. |
| DMARC | Có bản ghi công bố và bắt đầu bằng v=DMARC1. Bản thân chính sách (p=, rua=) không bị kiểm tra — đó là quyết định của bạn, không phải sự cho phép dành cho chúng tôi. |
Vì sao DMARC được kiểm tra nhẹ hơn: nó bảo bên nhận phải làm gì với kết quả DKIM và SPF, chứ không trao cho chúng tôi quyền gửi nhân danh bạn. Quyền đó chỉ đến từ hai bản ghi đầu, và cả hai đều được kiểm tra nội dung đầy đủ.
Include của người khác không được tính
include:esp.getmybot.dev phải nằm trong chính bản ghi SPF của bạn. Nếu SPF của bạn bao gồm một nhà cung cấp bên thứ ba mà bản ghi của họ lại bao gồm chúng tôi, xác minh sẽ không chấp nhận: nền tảng không lần theo chuỗi include của người khác. Lý do rất đơn giản — như vậy câu trả lời cho «đúng tên miền này có cho phép chúng tôi không» luôn rõ ràng.
Trên thực tế: dù bạn chắc chắn mình đã được «bao phủ qua nhà cung cấp», hãy thêm include của chúng tôi trực tiếp vào bản ghi của bạn. Chính màn hình đó cũng nói vậy trong phần giải thích bản ghi SPF: nếu tên miền đã có bản ghi SPF, hãy thêm giá trị include:... vào trong đó thay vì thay thế toàn bộ bản ghi, bởi tên miền có thể còn gửi thư qua những đường khác. Ghi chú này luôn hiển thị, không phải chỉ xuất hiện sau một lần kiểm tra thất bại.
DNS không cập nhật tức thì. Sau khi lưu bản ghi ở nhà đăng ký, chúng cần lan ra các máy chủ tên: thường là vài phút, đôi khi vài giờ, hiếm khi tới một ngày. Điều đó tùy nhà cung cấp và TTL. Đây là chuyện bình thường và không phụ thuộc vào chúng tôi.
Dù vậy không cần chờ thụ động. Nền tảng tự kiểm tra lại các tên miền đang chờ mỗi giờ một lần, nhưng trên thẻ tên miền có nút «Verify now» — cùng phép kiểm tra ấy, chạy tức thì, kết quả hiện ngay trên màn hình. Hãy bấm ngay sau khi lưu bản ghi: nếu có lỗi gõ nhầm, bạn biết sau một giây chứ không phải sau một giờ. Bấm bao nhiêu lần tùy ý.
Trạng thái tên miền hiển thị trên thẻ: «Pending verification», «Verified» hoặc «Not verified». Khi chưa được xác minh, thẻ còn kèm cảnh báo «Sending from this domain is disabled until it is verified.»
Kết quả không chỉ là «không đạt». Mỗi bản ghi trong ba bản ghi có trạng thái riêng trên màn hình — «Passing», «Not passing» hoặc «Not checked yet» — và dòng giải thích riêng cho biết chỗ nào sai.
Với SPF, màn hình phân biệt hai tình huống, và đây là điểm phân biệt quan trọng nhất trong cả quy trình:
- Tên miền hoàn toàn không có bản ghi SPF. Hãy công bố một bản, với giá trị ở bảng phía trên.
- Có bản ghi SPF nhưng trong đó không có include của chúng tôi. Hãy thêm include vào bản ghi sẵn có: đừng tạo bản thứ hai và đừng thay thế toàn bộ. Chính thông báo đó cũng nói rõ trường hợp chuỗi: nếu include chỉ đến được chúng tôi qua bản ghi SPF của nhà cung cấp khác thì không được tính, vì chuỗi không được lần theo.
Trường hợp thứ hai là khoảnh khắc rối rắm nhất của cả quy trình: bản ghi đã có sẵn, bạn vừa tự đọc lại nó, mà xác minh vẫn từ chối. Thông báo lỗi giờ nói đúng những gì ghi chú luôn hiển thị cạnh bản ghi đã nói: hãy thêm include của chúng tôi vào cái bạn đang có.
Nếu xác minh không đạt:
- Đọc xem bản ghi nào trong ba bản ghi bị đánh dấu «Not passing» và phần giải thích của nó nói gì, rồi làm theo đó.
- Chắc chắn các bản ghi thực sự đã công bố — nhiều bảng điều khiển yêu cầu bấm riêng «áp dụng thay đổi».
- Kiểm tra tên bản ghi xem tên miền có bị lặp không (xem ở trên).
- Kiểm tra chỉ có một bản ghi SPF và include của chúng tôi nằm ngay trong bản ghi đó.
- Chờ một lát rồi kiểm tra lại: thay đổi có thể chưa lan tới.
Chưa xác minh thì không gửi được — điều này là cố ý
Chừng nào tên miền chưa được xác minh, thư không được gửi. Không phải «gửi rồi rơi vào spam» — mà hoàn toàn không đi: nỗ lực gửi kết thúc bằng lỗi tên miền chưa xác minh, thấy được trong nhật ký.
Đây là chủ ý, không phải sự cố. Thư từ một tên miền chưa tự bảo chứng cho mình sẽ biến thành khiếu nại spam, mà khiếu nại thì làm hỏng uy tín của hạ tầng gửi dùng chung cho mọi khách hàng của nền tảng. Không gửi một lá thư rẻ hơn là gửi rồi mất nửa năm chui ra khỏi danh sách chặn. Vì thế ở đây là cấm chứ không phải cảnh báo.
Nếu bạn thấy lỗi này, hãy kiểm tra bản ghi DNS và bấm xác minh trước khi viết cho bộ phận hỗ trợ. Trong đại đa số trường hợp, nguyên nhân là lỗi gõ nhầm ở tên bản ghi.
Hủy đăng ký, khiếu nại và thư trả về
Ba quy tắc gây bất ngờ nếu không biết trước.
Mọi thư quảng cáo đều có nút hủy đăng ký một chạm. Nền tảng tự thêm liên kết hủy vào chân thư cùng các tiêu đề kỹ thuật để trình thư vẽ nút «Hủy đăng ký» ngay cạnh địa chỉ người gửi. Không thể bỏ đi — không bằng thiết lập, cũng không bằng cách dàn trang thư. Việc hủy có hiệu lực ngay, không cần mở thư và không có bước xác nhận. Gmail và các nhà cung cấp lớn khác đòi hỏi điều này ở người gửi hàng loạt: thư thiếu nó chắc chắn vào spam.
Hủy đăng ký là dứt khoát và không thể hoàn tác từ giao diện. Địa chỉ đã hủy sẽ không nhận thư của bot này nữa. Không có nút «khôi phục» và cũng không có đường vòng bằng cách nhập lại danh sách: việc hủy không bao giờ bị đảo ngược qua đầu người ta. Chỉ chính họ mới quay lại được — bằng cách để lại địa chỉ trên biểu mẫu đăng ký của bạn một lần nữa.
Còn một trường hợp nghiêm khắc hơn: nếu ai đó bấm «Đây là spam» trong trình thư, địa chỉ bị đóng vĩnh viễn. Ngay cả đăng ký lại qua biểu mẫu của bạn cũng không mở lại được — vì chúng tôi đã biết lần trước kết thúc thế nào, và gửi tới những địa chỉ như vậy là cách phá uy tín tên miền nhanh nhất. Địa chỉ bị đóng thủ công theo yêu cầu pháp lý cũng hành xử y hệt.
Thư trả về cứng đóng địa chỉ vĩnh viễn. Nếu máy chủ của người nhận trả lời rằng hộp thư đó không tồn tại, địa chỉ được đánh dấu không gửi được và loại khỏi các lần gửi sau. Đây không phải trạng thái tạm thời: tiếp tục gõ cửa một hộp thư không tồn tại là con đường nhanh nhất tới bộ lọc spam, kéo theo mọi địa chỉ khác.
Thư trả về mềm (hộp đầy, máy chủ tạm thời không truy cập được) không đóng địa chỉ — việc gửi vẫn tiếp tục.
Vì sao số lượt mở thấp hơn thực tế
Thống kê email có chỉ số lượt mở, và nó luôn thấp hơn thực tế. Đây không phải lỗi đếm, mà là cách lượt mở được đo.
Một lượt mở được ghi nhận khi trình thư tải từ máy chủ một ảnh theo dõi nhỏ xíu lúc hiển thị thư. Trình thư hiện đại mặc định không tải ảnh từ xa; còn những trình có tải (Apple Mail và các cơ chế bảo vệ riêng tư tương tự) thì tải trước cho tất cả mọi người, kể cả người chưa từng mở thư. Trường hợp đầu làm mất lượt mở, trường hợp sau gán nó cho người không hề có mặt. Không có cách nào đếm lượt mở chính xác hơn — cả với chúng tôi lẫn bất kỳ ai.
Vì vậy trong giao diện, cạnh con số có ghi chú: đó là cận dưới, không phải con số chính xác. Hãy dùng nó để so sánh các thư với nhau, nơi cùng một sai lệch áp cho tất cả, nhưng đừng dùng như câu trả lời cho «bao nhiêu người đã đọc thư».
Nếu cần chỉ số tương tác đáng tin, hãy nhìn vào «Link clicks». Nhấp vào liên kết là hành động thật của người thật; không ai làm trước thay họ. «Delivered», «Unsubscribes», «Complaints» và «Bounces» cũng được đếm chính xác: chúng do máy chủ thư báo về, không phải do một tấm ảnh trong thư. Tất cả đều nằm trong khối «Sending stats» trên cùng màn hình Email.