Lỗi khai báo email tên miền: 9 chỗ sai hay lặp nhất
Thư công ty vào spam thường không phải lỗi nội dung mà lỗi khai báo DNS. Chín chỗ sai dưới đây kèm dấu hiệu nhận ra và hậu quả nếu để lâu không sửa.
Thư báo giá gửi đi, khách bảo không nhận được. Mở thư mục spam bên họ thì thấy nằm đó. Phần lớn ca như vậy bắt nguồn từ bản ghi DNS khai thiếu hoặc khai sai, không phải từ nội dung. Chín chỗ dưới đây lặp nhiều nhất, kèm dấu hiệu nhận ra và hậu quả.
Lỗi khai báo email tên miền chia hai nhóm: thư không tới và thư bị nghi giả mạo
Nhóm một làm thư không tới hộp: sai MX, TTL quá dài lúc chuyển nhà, autodiscover trỏ nhầm. Nhóm hai làm thư tới mà bị đánh dấu đáng ngờ: SPF hỏng, thiếu DKIM, DMARC bỏ ngỏ, thiếu PTR.
SPF, DKIM và DMARC làm ba việc khác nhau, không thay nhau được. SPF khai ai được gửi thay tên miền. DKIM ký chữ ký lên thư đi. DMARC nói máy chủ nhận làm gì khi hai cái kia không khớp. Gói email doanh nghiệp của BizMaC cấp sẵn cả ba, việc còn lại là dán vào vùng DNS.
| # | Chỗ sai | Nhận ra bằng | Hậu quả |
|---|---|---|---|
| 1 | Sai bản ghi MX | Thư gửi tới không vào hộp nào | Mất thư đến |
| 2 | Hai bản ghi SPF | Kết quả kiểm trả về permerror | Toàn bộ SPF bị bỏ qua |
| 3 | SPF vượt 10 lượt tra | Công cụ kiểm báo quá giới hạn | SPF hỏng dù cú pháp đúng |
| 4 | Quên khoá DKIM | Thư đi không có chữ ký | Điểm tin cậy thấp |
| 5 | DMARC để p=none mãi | Báo cáo về mà không siết | Kẻ mạo danh vẫn gửi được |
| 6 | Gửi từ IP ngoài SPF | Thư từ phần mềm nội bộ vào spam | Thư giao dịch thất lạc |
| 7 | Sai autodiscover | Outlook không tự dò được cấu hình | Mỗi máy khai tay, dễ sai |
| 8 | Thiếu bản ghi PTR | IP không tra ngược ra tên miền | Máy chủ nhận từ chối thẳng |
| 9 | TTL đặt quá dài | Đổi bản ghi vài giờ chưa có hiệu lực | Chuyển nhà bị gián đoạn |
Chín lỗi khai báo email tên miền và cách nhận ra từng lỗi
Xếp theo mức phổ biến, không theo mức nghiêm trọng. Lỗi số 8 hiếm gặp hơn mà nặng nhất: thư bị từ chối ngay ở cổng, không có cả cơ hội vào spam.
1 Sai bản ghi MX
Hay xảy ra khi: vừa chuyển nhà cung cấp email nhưng chưa xoá MX cũ, hoặc gõ nhầm mức ưu tiên.
MX chỉ nơi nhận thư của tên miền. Sót MX cũ bên cạnh MX mới thì thư chia hai nơi: người gửi thấy đi được, bên nhận chỉ thấy một phần. Mức ưu tiên số nhỏ chạy trước, gõ ngược là thư đi nhầm.
2 Hai bản ghi SPF cùng lúc
Hay xảy ra khi: thêm dịch vụ gửi thư mới bằng cách dán thêm một dòng SPF nữa.
Một tên miền chỉ được đúng một bản ghi SPF. Có hai dòng thì máy chủ nhận trả permerror và bỏ qua cả hai. Cách đúng là gộp: giữ một dòng, thêm include của dịch vụ mới vào giữa.
3 SPF vượt 10 lượt tra
Hay xảy ra khi: tên miền dùng nhiều dịch vụ gửi thư, mỗi dịch vụ thêm một include.
Chuẩn SPF trong RFC 7208 giới hạn 10 lượt tra DNS mỗi lần kiểm. Mỗi include, a và mx tính một lượt, include lồng nhau cộng dồn. Vượt ngưỡng là permerror, giống hệt khai sai cú pháp.
Thư công ty đang vào spam mà chưa rõ vì sao?
Mở ticket từ tài khoản chính chủ, kỹ thuật BizMaC soát lại MX, SPF, DKIM và DMARC của tên miền rồi chỉ đúng dòng cần sửa.
4 Quên khoá DKIM
Hay xảy ra khi: bật email theo tên miền xong nhưng chỉ dán MX và SPF, bỏ qua bước lấy khoá.
DKIM ký chữ ký mật mã lên mỗi thư đi. Máy chủ nhận tra khoá công khai trong DNS để đối chiếu. Thiếu DKIM thì thư vẫn tới, chỉ mất một tín hiệu tin cậy. Bước này hay bị quên vì không hỏng ngay.
5 DMARC để p=none mãi không siết
Hay xảy ra khi: khai DMARC theo hướng dẫn rồi để nguyên, không đọc báo cáo trả về.
Chính sách p=none nghĩa là chỉ quan sát, không yêu cầu máy chủ nhận làm gì với thư giả mạo. Mức khởi đầu này đúng, dùng vài tuần để đọc báo cáo. Giữ nguyên suốt năm thì bản ghi chỉ còn để thu số liệu.
6 Gửi từ IP ngoài danh sách SPF
Hay xảy ra khi: phần mềm kế toán, CRM hoặc website gửi thư trực tiếp thay vì qua máy chủ thư.
Website gửi thư đặt hàng bằng hàm gửi của máy chủ web, IP đó không nằm trong SPF. Thư ghi người gửi là địa chỉ công ty nhưng đi từ máy lạ. Kết quả: thư giao dịch vào spam, thư viết tay thì không.
7 Sai autodiscover
Hay xảy ra khi: công ty chuyển nhà cung cấp nhưng vẫn giữ bản ghi autodiscover của bên cũ.
Outlook tra bản ghi autodiscover để tự điền máy chủ và cổng. Trỏ sai thì nó dò ra cấu hình cũ, người dùng nhập mật khẩu mãi không vào. Quản trị hay nghi mật khẩu trong khi lỗi ở DNS.
8 Thiếu bản ghi PTR
Hay xảy ra khi: tự dựng máy chủ thư trên VPS mà chưa xin đặt tên ngược cho IP.
PTR ánh xạ ngược từ IP về tên miền, chỉ nhà cung cấp IP đặt được. Nhiều máy chủ nhận kiểm ngay ở bước bắt tay. Không có PTR thì thư bị từ chối thẳng, không vào cả spam.
9 TTL đặt quá dài
Hay xảy ra khi: sắp chuyển email sang nhà cung cấp khác mà TTL vẫn để mức 24 giờ.
TTL nói máy chủ DNS trung gian được nhớ bản ghi bao lâu. Để 86400 giây tức một ngày, đổi MX xong vẫn có nơi gửi về máy cũ suốt thời gian đó. Cách đúng: hạ TTL xuống 300 giây trước ngày chuyển.
Thứ tự kiểm khi thư công ty vào spam
Tìm theo thứ tự này thay vì sửa lung tung, vì mỗi bước loại được một nhóm nguyên nhân. Cả bốn bước dùng công cụ tra DNS công khai.
- Tra MX trước. Sai ở đây thì thư không tới, chưa cần xét gì thêm.
- Đếm bản ghi SPF và số lượt tra. Phải đúng 1 bản ghi, từ 10 lượt tra trở xuống.
- Mở một thư đã gửi, xem phần ký bởi. Trống nghĩa là DKIM chưa chạy.
- Đọc báo cáo DMARC hai tuần. Nguồn gửi lạ hiện ra ở đây, trước khi siết chính sách.
Bốn bước đều sạch mà thư vẫn vào spam thì vấn đề ở uy tín IP gửi hoặc nội dung thư. Đó là lúc cân nhắc tách hạ tầng gửi bằng máy chủ thư riêng, để uy tín gửi không phụ thuộc hàng xóm.
Câu hỏi thường gặp về lỗi khai báo email tên miền
Khai đủ SPF, DKIM, DMARC rồi thư vẫn vào spam thì do đâu?
Ba bản ghi đó chỉ chứng minh thư đúng là của bạn, không nói thư có đáng đọc hay không. Nguyên nhân còn lại thường là uy tín IP gửi, tần suất gửi tăng đột ngột, hoặc người nhận từng bấm báo spam.
Đổi MX bao lâu thì có hiệu lực?
Phụ thuộc TTL của bản ghi cũ. TTL 300 giây thì phần lớn nơi cập nhật trong 5 tới 15 phút. TTL 86400 giây thì có nơi giữ bản cũ tới một ngày. Hạ TTL trước ngày chuyển là cách rút ngắn.
Một tên miền khai được mấy bản ghi DKIM?
Nhiều, vì mỗi khoá nằm ở một selector riêng. Đó là điểm khác với SPF. Dùng song song hai dịch vụ gửi thư thì mỗi bên một selector, không xung đột.
Có nên siết DMARC lên mức từ chối ngay từ đầu không?
Không nên. Đọc báo cáo ở mức quan sát vài tuần để thấy hết nguồn gửi hợp lệ, gồm cả website và phần mềm nội bộ. Siết sớm khi còn nguồn chưa khai thì thư của chính bạn bị chặn.
Ghi nhanh
- Sai MX thì mất thư đến. Sai SPF, DKIM, DMARC thì thư tới mà bị nghi ngờ. Tìm theo thứ tự đó.
- Chỉ được một bản ghi SPF, và tối đa 10 lượt tra DNS cho mỗi lần kiểm.
- DMARC ở mức quan sát chỉ là bước đệm, để nguyên nhiều tháng thì không chặn được gì.
- Trước khi chuyển nhà cung cấp, hạ TTL xuống 300 giây và chờ hết chu kỳ cũ.
Lưu ý: Bài viết chia kinh nghiệm chung, còn mỗi doanh nghiệp một quy mô và một cách vận hành. Muốn biết cách nào hợp với trường hợp của bạn — chọn gói nào, làm theo thứ tự nào, chi phí ra sao — chuyên viên BizMaC tư vấn và làm giúp bạn phần kỹ thuật.
Để BizMaC dựng website cho doanh nghiệp bạn
Giao diện chuẩn UX, cấu trúc chuẩn SEO, chạy mượt trên di động và dễ tự quản trị sau khi bàn giao. BizMaC làm website cho doanh nghiệp Việt từ năm 2007, đi kèm hướng dẫn vận hành chứ không bàn giao xong là hết.
