Bài viết gần đây
| Email Giao Dịch Vào Hộp Thư Chính: SPF, DKIM, DMARC Và 7 Lỗi Thường Gặp
Email giao dịch vào hộp thư chính: SPF, DKIM, DMARC và 7 lỗi thường gặp
Email xác thực, email đặt lại mật khẩu, email gửi sách, email thông báo thanh toán — đó là những email bạn bắt buộc phải gửi tới được người dùng. Nhưng máy chủ thư thường không báo lỗi gì cả: hàm gửi trả về thành công, mọi thứ trong hệ thống ghi là “đã gửi”, còn khách thì ngồi chờ một mã xác nhận không bao giờ tới.
1. Một lỗi không có thông báo lỗi
Có một kiểu lỗi phần mềm mà mọi công cụ giám sát đều bỏ qua: hàm gửi email trả về thành công, log ghi “đã gửi”, nhưng thư không bao giờ tới hộp thư người nhận.
Tôi nhớ lần đầu gặp nó khi hỗ trợ một người dùng không đăng nhập được bằng mã xác nhận gửi qua email. Kiểm tra hệ thống: chức năng gửi mã chạy đúng, mã được sinh ra, mã được lưu, hàm gửi email báo thành công. Không có một dòng lỗi nào. Kiểm tra phía người nhận: họ nói không thấy gì, kể cả trong thư rác.
Đến khi mở hộp thư rác bằng mắt, lá thư nằm ở đó, kèm một dòng cảnh báo nhỏ của nhà cung cấp: “Thư này có thể là giả mạo”.
Không có API nào báo lỗi này cho bạn, vì theo tiêu chuẩn, thư đã được gửi thành công. Nó bị từ chối ở một tầng khác — tầng danh tiếng tên miền. Và tầng đó chỉ được cấu hình bằng bản ghi DNS, không bằng code.
Đây là bài viết về tầng đó: ba bản ghi SPF, DKIM, DMARC, bảy lỗi thường gặp, và cách kiểm tra bằng số thay vì ngồi đoán.
2. Vì sao email là kênh khó tính nhất trong toàn bộ hệ thống
So sánh với một API: khi gọi sai, bạn nhận về mã trạng thái, thông báo lỗi, có khi cả gợi ý cách sửa. Email thì không có gì tương tự. Một lá thư có thể đi qua năm tầng kiểm tra khác nhau, và mỗi tầng có quyền âm thầm hạ cấp nó — từ “vào hộp thư chính” xuống “vào thư rác”, rồi “bị từ chối hoàn toàn”.
Có một cách phân biệt rất thực dụng mà tôi dùng khi chẩn đoán: email thất bại theo hai kiểu khác nhau.
Kiểu thứ nhất là lỗi ở tầng kết nối: tài khoản gửi sai, mật khẩu ứng dụng hết hạn, máy chủ gửi chặn cổng, tên miền của dịch vụ gửi bị đen. Những lỗi này thường để lại thông báo ngay trong ứng dụng, vì đó là lỗi giao tiếp giữa hai máy chủ.
Kiểu thứ hai là lỗi ở tầng danh tiếng: thư đi được, máy chủ nhận nói “cảm ơn”, rồi quyết định của nó mới là điều bạn cần. Tầng này không trả về lỗi cho ứng dụng. Nó chỉ bị phát hiện nếu bạn biết mở phần chi tiết thư của người nhận ra mà đọc các dòng xác thực.
Ba bản ghi dưới đây chính là cách bạn nói trước với máy chủ nhận: “thư này là thật, gửi từ hạ tầng tôi cho phép, nội dung không bị sửa trên đường đi”.
3. Ba bản ghi quyết định, giải thích theo cách dễ nhớ
SPF — ai được phép gửi thay tên miền của bạn
SPF là một bản ghi TXT nói rõ danh sách các máy chủ được phép gửi thư với tên miền của bạn. Khi nhận một lá thư, máy chủ nhận sẽ hỏi hệ thống tên miền: “máy gửi này có nằm trong danh sách được phép của tên miền này không?”
Một cấu hình đơn giản có dạng như sau:
Tên: @
Loại: TXT
Giá trị: v=spf1 ip4:203.0.113.25 include:_spf.google.com -all
Đọc từng phần: v=spf1 là phiên bản, ip4: là địa chỉ máy chủ của bạn, include: là dịch vụ gửi thư bạn dùng thêm, và -all nghĩa là “mọi máy khác đều không được phép” — dấu trừ là dấu mạnh, dấu ngã ~all là dấu mềm (chỉ cảnh báo, không từ chối).
Có một giới hạn kỹ thuật rất hay bị bỏ qua: SPF chỉ cho phép tối đa 10 lần tra cứu tên miền phụ. Mỗi include: là một lần tra cứu, và bản thân nó có thể kéo theo nhiều lần nữa. Khi vượt ngưỡng, cả bản ghi bị coi là không hợp lệ, kể cả khi nội dung đúng. Cách kiểm tra ở phần sau của bài sẽ cho bạn biết con số này.
Điểm quan trọng tiếp theo: SPF kiểm tra địa chỉ máy chủ, không kiểm tra địa chỉ trong dòng From mà người đọc nhìn thấy. Đây là gốc của lỗi phổ biến nhất khi dùng dịch vụ gửi thư của bên thứ ba: thư gửi thành công, máy chủ nhận thấy SPF đúng với tên miền của dịch vụ, nhưng tên miền trong dòng From lại là tên miền của bạn — nên kết quả xác thực không khớp với kỳ vọng của chính sách tên miền.
DKIM — chữ ký số cho từng lá thư
DKIM là cách bạn ký số lá thư bằng một khoá riêng, và công bố khoá công khai trong hệ thống tên miền để máy chủ nhận kiểm tra chữ ký.
Cấu trúc thường gặp:
Tên: mail._domainkey
Loại: TXT
Giá trị: v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GN...
Phần mail trong tên bản ghi gọi là selector (bộ chọn). Mỗi dịch vụ gửi thư dùng một selector riêng, và bạn phải lấy đúng giá trị từ nhà cung cấp dịch vụ gửi. Đây là chỗ hay sai nhất của DKIM: người ta dán đúng khoá nhưng sai selector, hoặc dán khoá của dịch vụ này vào selector của dịch vụ khác, và kết quả là chữ ký không kiểm tra được.
Một điểm tinh tế về DKIM: nó không phải công tắc bật/tắt. Một lá thư có thể được ký tốt, nhưng nếu nội dung bị sửa trên đường đi (ví dụ một công cụ nào đó thêm chân trang quảng cáo, hoặc chuyển link để theo dõi click), chữ ký sẽ hỏng với các phần đã bị sửa. Đó là lý do một số hệ thống gửi hàng loạt chèn chân trang trước khi ký, không phải sau.
DMARC — chính sách khi hai bản ghi trên không khớp
DMARC là bản ghi nói rõ bạn muốn máy chủ nhận làm gì khi SPF hoặc DKIM (hoặc cả hai) không khớp với tên miền trong dòng From.
Tên: _dmarc
Loại: TXT
Giá trị: v=DMARC1; p=none; rua=mailto:dmarc@ten-mien-cua-ban.com
Ba mức chính sách: p=none chỉ ghi nhận và báo cáo, p=quarantine yêu cầu đưa vào thư rác, p=reject yêu cầu từ chối thẳng. Ngoài ra rua= là địa chỉ nhận báo cáo tổng hợp — và báo cáo này là thứ đáng giá nhất trong cả ba bản ghi, vì nó cho bạn biết ai đang gửi thư dưới tên miền của bạn.
Trình tự triển khai đúng gần như luôn giống nhau: bắt đầu bằng p=none kèm địa chỉ nhận báo cáo, đọc báo cáo vài tuần để biết đủ các nguồn gửi thật, cấu hình SPF và DKIM cho từng nguồn, rồi mới siết lên quarantine và reject.
Nhảy thẳng lên p=reject khi chưa biết đủ các nguồn gửi là cách tự khoá mất thư của chính mình. Tôi đã gặp đúng tình huống đó: một hệ thống gửi hoá đơn nằm ở máy chủ không khai báo trong SPF, và khi chính sách bị siết, toàn bộ hoá đơn bị từ chối trong im lặng suốt nhiều ngày.
4. Hai thứ nằm ngoài ba bản ghi nhưng cũng chặn thư
Ba bản ghi trên là phần được nói đến nhiều nhất, nhưng thực tế còn hai thứ khác có thể chặn thư trước cả khi SPF, DKIM, DMARC được kiểm tra.
Bản ghi MX và hộp thư nhận. Nếu tên miền của bạn không có bản ghi MX trỏ tới một hệ thống thư đang hoạt động, thì tên miền đó không nhận được thư — kể cả thư trả lời của khách, kể cả thư cảnh báo của các dịch vụ bạn dùng. Đây là lỗi rất dễ xảy ra khi ai đó “dọn dẹp” bản ghi DNS và xoá nhầm MX. Hậu quả không nằm ở việc gửi mà nằm ở việc nhận: bạn gửi được, khách trả lời được, nhưng không ai đọc được. Hộp thư hỗ trợ chết âm thầm — và bạn chỉ phát hiện khi một khách gọi điện hỏi vì sao không thấy trả lời.
Bản ghi ngược (rDNS) của địa chỉ IP gửi. Với máy chủ gửi của riêng bạn, bản ghi ngược phải trỏ về đúng tên miền bạn đang gửi. Nhiều máy chủ nhận coi bản ghi ngược không khớp là dấu hiệu mạnh của thư rác, và việc này thường do nhà cung cấp hạ tầng quản lý chứ không phải bạn — nên nếu bạn gửi bằng máy chủ riêng, hãy hỏi nhà cung cấp về bản ghi ngược trước khi mở hệ thống cho khách.
Một ghi chú thực dụng: nếu bạn gửi email giao dịch bằng dịch vụ chuyên dụng (không phải máy chủ của mình), hai mục này do dịch vụ lo. Đổi lại, bạn phải cấu hình đúng phần include: trong SPF và selector DKIM của họ.
5. Bảy lỗi thường gặp và cách chữa
Phần này xếp theo thứ tự tần suất tôi gặp khi đi kiểm tra hệ thống của người khác.
Lỗi 1 — Không có bản ghi SPF
Triệu chứng: thư của bạn bị đánh dấu “có thể là giả mạo”, vào thư rác ngay lần đầu gửi tới người nhận mới.
Cách chữa: tạo một bản ghi TXT cho tên miền gốc, liệt kê đúng các nguồn gửi bạn dùng, kết thúc bằng -all.
Lỗi 2 — Có SPF nhưng quá giới hạn tra cứu
Triệu chứng: SPF nhìn đúng, nhưng kết quả kiểm tra luôn là “không xác định” hoặc thất bại.
Nguyên nhân: vượt quá mười lần tra cứu tên miền phụ. Lỗi này hiếm khi do bạn viết sai, mà do bạn dùng nhiều dịch vụ và mỗi dịch vụ kéo theo vài lần tra cứu. Cách chữa: gộp nguồn gửi, dùng dịch vụ chuyển tiếp có SPF gọn, hoặc tách phần gửi hàng loạt sang một tên miền phụ riêng.
Lỗi 3 — DKIM sai selector hoặc sai khoá
Triệu chứng: SPF đạt, DKIM không đạt, và DMARC vì thế mà cũng không đạt.
Nguyên nhân thường là hậu tố, không phải khoá: bạn dán khoá đúng nhưng đặt ở tên bản ghi sai, hoặc dịch vụ gửi đã đổi selector mà bạn không cập nhật.
Cách chữa: luôn lấy thông tin selector và khoá từ đúng trang quản trị của dịch vụ gửi đang dùng, dán không thêm dấu cách, không xuống dòng giữa giá trị. Với DKIM, một khoảng trắng thừa cũng làm chữ ký không kiểm tra được.
Lỗi 4 — DMARC để p=none rồi quên siết trong nhiều tháng
Triệu chứng: mọi chỉ số đều đẹp, bạn yên tâm, nhưng thư giả mạo tên miền bạn vẫn được chấp nhận vì chính sách chưa yêu cầu chặn.
Cách chữa: sau khi đọc báo cáo tổng hợp và xác nhận đã khai báo đủ nguồn gửi, chuyển dần sang quarantine rồi reject.
Lỗi 5 — Gửi qua nền tảng bị chặn cổng thư
Triệu chứng: khi chạy ở máy cá nhân, thư gửi bình thường. Sau khi triển khai lên nền tảng đám mây, thư không bao giờ tới, và log có lỗi kết nối hoặc treo rất lâu rồi hết thời gian chờ.
Nguyên nhân: đa số nền tảng đám mây chặn các cổng gửi thư truyền thống để chống lạm dụng, kể cả trên gói trả phí.
Cách chữa có ba hướng, chọn theo nhu cầu:
Thứ nhất, dùng API gửi thư qua HTTPS của một dịch vụ chuyên dụng. Đây là cách ít việc nhất vì bạn không phải quản lý máy chủ thư, và dịch vụ lo giúp bạn uy tín của địa chỉ gửi.
Thứ hai, dựng một dịch vụ gửi thư riêng chạy trên máy bạn quản lý, và để ứng dụng chính gọi vào đó bằng HTTPS. Cách này phù hợp khi bạn muốn giữ toàn bộ nội dung thư trong hạ tầng của mình.
Thứ ba, chuyển ứng dụng sang hạ tầng không chặn cổng thư. Cách này chỉ đáng làm khi bạn có lý do rõ ràng khác.
Lỗi 6 — Tên miền trong dòng From không khớp cấu hình
Triệu chứng: SPF đạt cho tên miền này, DKIM đạt cho tên miền khác, và kết quả tổng hợp bị đánh giá không khớp.
Cách chữa: chốt trước một nguyên tắc — mọi email giao dịch gửi bằng một tên miền gửi phụ, ví dụ mail.ten-mien.com, và cấu hình SPF, DKIM, DMARC cho tên miền phụ đó. Tách tên miền gửi phụ khỏi tên miền chính còn giúp bạn bảo vệ danh tiếng của tên miền chính nếu phần gửi hàng loạt gặp sự cố.
Lỗi 7 — Nội dung và tần suất khiến người nhận tự đánh dấu
Triệu chứng: kỹ thuật đúng hết, nhưng tỉ lệ vào thư rác vẫn cao.
Nguyên nhân nằm ở hành vi người nhận: nhiều người bấm “báo cáo thư rác” thay vì huỷ đăng ký. Mỗi lần bị báo cáo là một điểm trừ cho danh tiếng tên miền, và điểm trừ đó ảnh hưởng tới cả những email giao dịch bạn đang cần gửi.
Cách chữa: giảm số lần gửi không cần thiết, cho người dùng cách huỷ nhận thư ở chân mỗi thư, và đừng dùng chung một tên miền gửi cho thư giao dịch lẫn thư quảng cáo.
6. Kiểm tra bằng số, không kiểm tra bằng cảm giác
Sau khi cấu hình, đừng kết luận dựa trên việc “tôi vừa gửi thử và thấy thư tới”. Một lá thư tới hộp thư của chính bạn không nói gì nhiều về những lá thư sẽ gửi cho người lạ.
Có bốn phép kiểm tra bằng số mà bạn nên chạy, và cả bốn đều làm được từ dòng lệnh hoặc chỉ cần một bước bấm trong hộp thư.
Kiểm tra bản ghi SPF:
nslookup -type=TXT ten-mien-cua-ban.com
Kết quả phải là một dòng duy nhất bắt đầu bằng v=spf1. Nếu có nhiều hơn một bản ghi SPF trên cùng tên miền, đó là lỗi: tiêu chuẩn chỉ cho phép một bản ghi, nhiều bản ghi sẽ làm kết quả kiểm tra thất bại.
Kiểm tra bản ghi DKIM: tra cứu tên bản ghi theo đúng selector mà dịch vụ cấp cho bạn:
nslookup -type=TXT mail._domainkey.ten-mien-cua-ban.com
Nếu không ra kết quả, gần như chắc chắn là sai selector hoặc bản ghi chưa lan truyền.
Kiểm tra bản ghi DMARC:
nslookup -type=TXT _dmarc.ten-mien-cua-ban.com
Kết quả phải có v=DMARC1 ở đầu.
Kiểm tra thật bằng một lá thư gửi tới hộp thư Gmail của bạn. Đây là phép kiểm tra quan trọng nhất. Mở lá thư, chọn mục xem chi tiết thư gốc, và tìm dòng Authentication-Results. Bạn cần thấy ba kết quả:
spf=pass
dkim=pass
dmarc=pass
Nếu một trong ba khác pass, bạn đã biết chính xác lỗi nằm ở bản ghi nào — không cần đoán. Và nếu cả ba đều pass mà thư vẫn vào thư rác, thì vấn đề nằm ở tầng danh tiếng hoặc nội dung, chứ không phải cấu hình.
Một mẹo nhỏ khi kiểm tra: hãy gửi thử tới một hộp thư mới hoàn toàn, chưa từng nhận thư nào của bạn. Với hộp thư cũ, hệ thống đã có lịch sử và thường tự cho thư của bạn vào hộp thư chính, kể cả khi cấu hình chưa đúng — dẫn tới kết luận sai là “mọi thứ đã ổn”.
7. Một trường hợp thật: hộp thư hỗ trợ chết mà không ai báo
Trong một dự án vận hành dịch vụ phần mềm, sau khi đổi tên miền chính, hộp thư hỗ trợ bỗng nhiên không nhận được thư nào. Việc gửi vẫn tốt: email xác thực vẫn tới người dùng, thông báo thanh toán vẫn đi. Nhưng chiều nhận đã chết, vì bản ghi MX của tên miền cũ bị xoá cùng lúc với việc tên miền đó mất bản ghi trỏ tới máy chủ.
Điều đáng nói là không có bất kỳ cảnh báo nào. Không lỗi ứng dụng, không thông báo, không log. Người dùng vẫn trả lời được email của hệ thống — thư của họ đi vào khoảng không. Phải tới khi một khách gọi điện hỏi “sao em gửi mail mà không thấy anh trả lời”, sự việc mới lộ ra.
Từ đó, danh sách kiểm tra của dự án thêm hai mục mà trước đây không ai nghĩ tới:
Một là, kiểm tra chiều nhận chứ không chỉ chiều gửi: sau mỗi lần đổi tên miền hoặc dọn bản ghi DNS, gửi thử một lá thư từ bên ngoài vào hộp thư hỗ trợ và xác nhận có thư trả lời đi ra.
Hai là, mọi endpoint hay dịch vụ phụ thuộc tên miền đều phải nằm trong danh sách kiểm tra khi đổi tên miền: trang web, API, tên miền gửi thư, hộp thư nhận, và cả đường dẫn quay về sau khi thanh toán. Trong dự án đó, đúng cùng một lần đổi tên miền còn làm hỏng cả đường dẫn quay về của cổng thanh toán — khách trả tiền xong bị đưa về một địa chỉ không tồn tại. Hai sự cố, một nguyên nhân, và cả hai đều không có cảnh báo tự động.
8. Chống lạm dụng chính dịch vụ gửi của bạn
Nếu hệ thống của bạn có chức năng gửi mã xác nhận qua email, bạn vừa có thêm một bề mặt bị lạm dụng: kẻ xấu có thể dùng nút “gửi lại mã” để biến máy chủ của bạn thành công cụ gửi thư rác tới hộp thư người khác.
Cách chặn gồm bốn lớp, và cả bốn đều rẻ:
Thứ nhất, giới hạn tần suất theo cửa sổ thời gian, không giới hạn theo lần bấm. Ví dụ: tối đa năm lần gửi trong mười phút cho mỗi địa chỉ.
Thứ hai, giới hạn theo địa chỉ người nhận và theo địa chỉ mạng gửi cùng lúc. Chỉ giới hạn theo người nhận thì kẻ tấn công đổi danh sách địa chỉ; chỉ giới hạn theo mạng thì họ đổi mạng.
Thứ ba, làm cho việc dò mã trở nên vô nghĩa: mã đủ dài, hết hạn sau vài phút, và số lần thử sai bị đếm — sai quá số lần cho phép thì mã bị huỷ, không phải chỉ báo lỗi.
Thứ tư, ghi lại mọi lần gửi kèm địa chỉ người nhận và địa chỉ mạng của người yêu cầu. Khi bị lạm dụng, log này là thứ duy nhất giúp bạn biết chuyện gì đã xảy ra và từ đâu.
Một chi tiết vận hành đáng nhớ: đừng gửi email trong cùng một yêu cầu HTTP với thao tác người dùng. Nếu máy chủ thư chậm, người dùng sẽ ngồi chờ màn hình quay. Hãy đưa việc gửi ra chạy nền, và ghi trạng thái gửi vào dữ liệu để bạn tra cứu được sau này — ví dụ “đã xếp hàng”, “đã gửi lúc nào”, “lỗi gì”.
9. Checklist 16 điểm trước khi mở hệ thống cho khách
Bản ghi DNS
- Có đúng một bản ghi SPF cho tên miền gửi, kết thúc bằng
-all. - SPF không vượt quá mười lần tra cứu tên miền phụ.
- DKIM đã bật, selector đúng với dịch vụ gửi, khoá dán không có dấu cách thừa.
- Có bản ghi DMARC, và có địa chỉ nhận báo cáo tổng hợp.
- Chính sách DMARC đã siết khỏi mức chỉ ghi nhận, sau khi đã khai báo đủ nguồn gửi.
- Tên miền gửi thư giao dịch là tên miền phụ, tách khỏi tên miền chính.
- Bản ghi MX trỏ tới hệ thống thư đang hoạt động, và hộp thư hỗ trợ thật sự nhận được thư.
- Bản ghi ngược của địa chỉ máy chủ gửi khớp với tên miền đang gửi (nếu gửi bằng máy chủ riêng).
Kiểm tra thật
- Thư gửi tới hộp thư mới hiển thị
spf=pass,dkim=pass,dmarc=pass. - Thư gửi từ bên ngoài vào hộp thư hỗ trợ đã được nhận và trả lời được.
- Thư trả lời của người dùng không bị đưa vào thư rác ở phía bạn.
Trong ứng dụng
- Việc gửi email chạy nền, không nằm trong yêu cầu HTTP của người dùng.
- Có ghi lại trạng thái từng lần gửi và lỗi nếu có.
- Có giới hạn tần suất gửi theo cả người nhận lẫn mạng gửi.
- Không có khoá bí mật nào của dịch vụ gửi nằm trong mã nguồn.
- Có người nhận được cảnh báo khi dịch vụ gửi thư lỗi liên tục.
Hai mục 9 và 10 là hai mục duy nhất trả lời được câu hỏi thật sự quan trọng: khách của bạn có nhận được thư hay không.
10. Câu hỏi thường gặp
Có bắt buộc phải có cả ba bản ghi không? SPF và DKIM là hai cách chứng minh thư hợp lệ; DMARC là chính sách nói bạn muốn xử lý thế nào khi chúng không khớp. Bạn có thể chạy chỉ với SPF, nhưng từ nay các nhà cung cấp hộp thư lớn đều đọc DMARC để quyết định mức tin cậy, nên thiếu DMARC là tự đặt mình vào nhóm yếu thế.
Tên miền phụ có cần bản ghi MX riêng không? Nếu tên miền phụ chỉ dùng để gửi thì không cần bản ghi MX. Nhưng nếu bạn muốn nhận thư trả lời về địa chỉ gửi trên tên miền phụ đó, thì cần.
Vì sao thư tới hộp thư của tôi mà khách không nhận được? Vì hộp thư của bạn đã có lịch sử tốt với chính bạn. Hãy thử với một hộp thư mới, chưa từng nhận thư nào từ bạn — đó mới là phép thử thật.
Đã cấu hình đúng mà vẫn vào thư rác thì sao? Kiểm tra ba kết quả xác thực trước. Nếu cả ba đều đạt, vấn đề thường nằm ở tên miền đã có lịch sử xấu trước đó, hoặc nội dung thư, hoặc tần suất gửi. Trường hợp tên miền xấu thì cần thời gian chứ không có cách sửa tức thời.
Có nên gửi thư quảng cáo bằng cùng tên miền với thư giao dịch không? Không nên. Thư quảng cáo bị đánh dấu là chuyện bình thường; bạn không muốn email đặt lại mật khẩu của khách bị liên đới.
Dùng dịch vụ gửi thư của bên thứ ba thì có cần tự làm gì không? Có, và đó là phần bị bỏ qua nhiều nhất: bạn vẫn phải thêm dải gửi của họ vào SPF và tạo bản ghi DKIM theo selector họ cấp, nếu không thư của bạn sẽ gửi được nhưng không xác thực được với tên miền của bạn.
Làm sao biết có ai đang mạo danh tên miền của mình? Bản ghi DMARC kèm địa chỉ nhận báo cáo tổng hợp sẽ cho bạn biết. Nhìn vào báo cáo vài tuần là thấy được những nguồn gửi bạn không tạo ra.
11. Kết
Cấu hình SPF, DKIM, DMARC mất khoảng một buổi nếu làm lần đầu, và khoảng hai mươi phút cho tên miền tiếp theo. Đổi lại, nó là tầng duy nhất quyết định email xác thực của bạn có tới được người dùng hay không — thứ mà không dòng code nào có thể bù đắp.
Ba việc nên làm ngay, theo đúng thứ tự:
Một, tra cứu xem tên miền của bạn hiện có gì: nslookup -type=TXT cho SPF, cho _dmarc, và cho selector DKIM đang dùng.
Hai, gửi một lá thư thử tới hộp thư mới và đọc dòng Authentication-Results. Nếu thấy ba chữ pass, bạn đã xong phần khó nhất.
Ba, kiểm tra chiều nhận — thứ bị bỏ quên nhiều nhất. Gửi từ ngoài vào hộp thư hỗ trợ, và xác nhận là có người thật đọc được nó.
