Thư khách gửi vào email công ty biến mất mà không ai biết. Bốn bước tự kiểm trong 3 phút, cách đọc thư trả về và bảng triệu chứng — nguyên nhân — xử lý.
# Email công ty không nhận được thư: nguyên nhân và cách tự kiểm
Trả lời ngắn
Nguyên nhân phổ biến nhất không phải là thư rơi vào spam, mà là tên miền mất hiệu lực hoặc bản ghi MX bị xoá khi đổi nhà cung cấp. Không còn MX thì không còn địa chỉ để thư đi tới: thư bị trả về người gửi, hoặc tệ hơn là biến mất im lặng. Bạn kiểm được trong ba phút bằng lệnh dig MX <tên miền> — kết quả trống nghĩa là mọi địa chỉ thuộc tên miền đó đang không nhận được thư nào.
Mục lục
Vì sao đây là loại sự cố im lặng
Website hỏng thì ai cũng thấy. Nhân viên mở trang, khách gọi điện báo, chủ doanh nghiệp biết trong vòng một buổi.
Email hỏng thì không.
Người gửi bấm Gửi, hộp thư của họ hiện "Đã gửi", thanh trạng thái xanh. Họ không có lý do gì để nghi ngờ. Bên nhận thì không thấy gì cả — mà không thấy gì thì trông y hệt như một ngày không có ai liên hệ. Không có thông báo lỗi, không có cảnh báo, không có con số nào tụt xuống. Chỉ có một hộp thư yên ắng và một cách giải thích rất dễ chấp nhận: dạo này thị trường chậm.
Đó là điểm nguy hiểm thật sự. Với hầu hết sự cố kỹ thuật, bạn phát hiện rồi mới sửa. Với email chết, bạn phải nghi ngờ thì mới phát hiện.
Trong các đợt khảo sát doanh nghiệp vừa và nhỏ tại TP.HCM, Creps gặp mô hình này nhiều lần. Một cơ sở thẩm mỹ vẫn có website chạy bình thường, số điện thoại vẫn nghe máy, nhưng địa chỉ info@ in trên toàn bộ tờ rơi và trên trang liên hệ thì không còn bản ghi MX nào — nghĩa là mọi thư gửi tới địa chỉ đó đều không tới nơi. Một xưởng cơ khí có tên miền đã hết hạn tới mức không còn máy chủ tên miền: website chết và email chết cùng một lúc, nhưng chủ doanh nghiệp chỉ để ý cái thứ nhất. Trường hợp khó chịu nhất là một doanh nghiệp mà địa chỉ info@ trả về lỗi từ chối vĩnh viễn, trong khi một hộp thư phụ ít ai biết vẫn nhận thư bình thường — tức là khách nào viết vào địa chỉ chính thức thì mất, khách nào tình cờ có địa chỉ phụ thì tới.
Điểm chung: không ai trong số họ biết mình đang mất thư. Và không ai biết đã mất bao nhiêu.
Tự kiểm 3 phút: bốn bước
Bốn bước dưới đây chạy được trên máy Mac hoặc Linux ngay trong Terminal. Trên Windows, mở PowerShell và dùng lệnh tương đương ghi kèm. Thay tenmien.com bằng tên miền thật của bạn.
Bước 1 — dig MX: câu hỏi quan trọng nhất
dig MX tenmien.com @8.8.8.8 +short
Trên Windows:
nslookup -type=mx tenmien.com 8.8.8.8
Kết quả có thư mục đích sẽ in ra một hoặc vài dòng dạng số thứ tự ưu tiên kèm tên máy chủ, ví dụ 1 aspmx.l.google.com. và 5 alt1.aspmx.l.google.com.
Kết quả trống rỗng — không in ra dòng nào — nghĩa là tên miền của bạn hiện không khai báo máy chủ thư nào. Mọi thư gửi tới tên miền đó đang không có nơi để đến.
Vì sao lại thêm @8.8.8.8? Đó là chỉ định hỏi thẳng máy chủ DNS công cộng của Google thay vì máy chủ mặc định của mạng bạn đang dùng. Mạng văn phòng thường có DNS nội bộ với bộ nhớ đệm cũ, và bộ nhớ đệm cũ là thứ khiến người kiểm tra thấy bản ghi vẫn còn trong khi thế giới bên ngoài đã thấy nó biến mất. Đây là chi tiết nhỏ nhưng phân biệt một lần kiểm đáng tin với một lần kiểm cho có.
Một cái bẫy ít người biết. MX trống không phải lúc nào cũng dẫn tới thư bị trả về. Theo chuẩn SMTP, khi không tìm thấy MX, nhiều máy chủ gửi sẽ quay sang dùng bản ghi A của tên miền làm nơi nhận thư — cơ chế này gọi là implicit MX. Nếu tên miền của bạn vẫn còn bản ghi A trỏ về máy chủ web, thư sẽ được chuyển tới đúng cái máy chủ đang chạy website, nơi không có dịch vụ thư nào lắng nghe. Kết quả tuỳ cấu hình máy chủ đó: có nơi từ chối, có nơi nhận rồi vứt bỏ. Trường hợp sau chính là kịch bản tệ nhất — người gửi không hề nhận được báo lỗi, thư vẫn mất.
Nói cách khác, "không thấy báo lỗi" không chứng minh được điều gì.
Bước 2 — dig TXT: đọc bản ghi SPF
dig TXT tenmien.com @8.8.8.8 +short
Trong đống kết quả, tìm dòng bắt đầu bằng v=spf1, chẳng hạn "v=spf1 include:_spf.google.com ~all". Dòng này là danh sách những máy chủ được phép gửi thư nhân danh tên miền của bạn. Ba tình huống đáng chú ý:
- Không có dòng
v=spf1 nào. Bạn chưa khai báo gì cả. Thư của công ty bạn gửi đi sẽ bị nhiều hộp thư đánh giá là đáng ngờ.
- Có nhiều hơn một dòng
v=spf1. Đây là lỗi cấu hình thật sự phổ biến, thường xảy ra sau khi công ty đổi nhà cung cấp mà quên xoá bản ghi cũ. Chuẩn SPF quy định chỉ được có đúng một bản ghi; có hai bản ghi thì bên nhận coi như kiểm tra thất bại — tệ hơn cả không khai báo.
- Kết thúc bằng
+all. Nghĩa là "cho phép bất kỳ ai gửi thư nhân danh tên miền này". Nên là ~all hoặc -all.
Bước 3 — DKIM và DMARC ở mức đủ dùng
Bạn không cần hiểu mật mã học để kiểm hai thứ này.
DKIM là chữ ký số mà máy chủ gửi đính vào mỗi lá thư, để bên nhận xác minh thư không bị sửa dọc đường và đúng là do tên miền đó phát ra. Nó nằm ở một bản ghi TXT có tiền tố riêng — gọi là selector, do nhà cung cấp email chỉ định. Với Google Workspace, selector mặc định là google, nên lệnh kiểm là:
dig TXT google._domainkey.tenmien.com @8.8.8.8 +short
Có kết quả dài ngoằng bắt đầu bằng v=DKIM1 là bình thường. Không có gì, trong khi bạn đang dùng dịch vụ email chuyên nghiệp, thì phần ký thư chưa được bật.
DMARC là chính sách bạn công bố cho cả thế giới: nếu một lá thư mang tên miền của tôi mà không qua được SPF lẫn DKIM, hãy làm gì với nó.
dig TXT _dmarc.tenmien.com @8.8.8.8 +short
Kết quả kiểu v=DMARC1; p=none; rua=mailto:... nghĩa là bạn mới chỉ ở mức quan sát — chưa yêu cầu bên nhận chặn gì. Mức chặt hơn là p=quarantine (đẩy vào spam) và p=reject (từ chối thẳng). Không có bản ghi _dmarc nào thì bất kỳ ai cũng có thể mạo danh tên miền công ty bạn để gửi thư, và bạn sẽ không bao giờ biết.
Đây cũng là lý do các doanh nghiệp bị mạo danh gửi thư lừa đảo thường phát hiện quá muộn: không có DMARC thì không có báo cáo, không có báo cáo thì không có tín hiệu.
Bước 4 — gửi một lá thư thử từ hộp thư lạ
Ba bước trên đọc cấu hình. Bước này kiểm chứng thực tế, và là bước không được bỏ.
Dùng một hộp Gmail cá nhân chưa từng liên lạc với công ty bạn — không dùng hộp thư nội bộ, không dùng máy trong cùng văn phòng, vì hệ thống thư nội bộ thường chuyển thư thẳng cho nhau mà không đi ra ngoài Internet. Chính điểm này khiến vô số cuộc kiểm tra kết luận sai: nhân viên gửi cho nhau thấy vẫn tới nên yên tâm, trong khi thư từ bên ngoài không bao giờ vào được.
Gửi thư tới địa chỉ công ty. Rồi làm ba việc:
- Kiểm hộp đến của công ty — thư có tới không.
- Kiểm thư mục Spam của công ty — nếu thư nằm trong đó thì vấn đề khác hẳn, xem mục SPF, DKIM, DMARC.
- Quay lại hộp thư vừa gửi, mở đúng cuộc hội thoại đó ra và đọc từ trên xuống, tìm thư trả lời của
mailer-daemon hoặc postmaster.
Việc thứ ba quan trọng hơn vẻ ngoài của nó. Thư báo lỗi thường được xếp chung cuộc hội thoại với thư gốc, nên nhìn lướt danh sách hộp thư đến sẽ không thấy. Còn kiểm tra bằng cách "xem trong mục Đã gửi có thư không" là cách kiểm tra vô nghĩa: thư luôn nằm trong Đã gửi, kể cả khi nó chưa từng tới đâu.
Đọc thư trả về của mailer-daemon
Khi có thư trả về, nội dung của nó cho biết chính xác chuyện gì đã xảy ra. Bỏ qua phần kỹ thuật dài dòng, tìm dãy số ba chữ số và dãy số chấm đi kèm.
| Mã trong thư trả về |
Nghĩa |
Hàm ý cho bạn |
550 5.1.1 — mailbox does not exist |
Hộp thư không tồn tại |
Tên miền và máy chủ thư vẫn sống, chỉ riêng địa chỉ này sai hoặc đã bị xoá. Thường gặp khi nhân sự nghỉ việc mà không ai chuyển tiếp thư |
552 — exceeded storage allocation |
Hộp thư đầy hoặc không thể nhận |
Hỏng vĩnh viễn hoặc bán vĩnh viễn. Địa chỉ này nên bị gạch khỏi mọi tài liệu cho tới khi chủ hộp dọn dẹp |
554 5.7.1 — transaction failed |
Bị từ chối vì chính sách |
Không phải lỗi địa chỉ mà là lỗi tin cậy: SPF/DMARC không qua, hoặc máy chủ gửi nằm trong danh sách đen |
Nhóm 4xx, ví dụ 451 |
Lỗi tạm thời |
Máy chủ sẽ thử lại. Chưa kết luận được gì — phải chờ |
| Báo lỗi phân giải DNS, domain not found |
Tên miền không tồn tại hoặc không còn máy chủ tên miền |
Tên miền đã hết hạn hoặc bị thu hồi. Xem bài về tên miền hết hạn |
| Không có thư trả về nào, thư vẫn không tới |
Trường hợp nguy hiểm nhất |
Thư bị máy chủ nhận nuốt: implicit MX, bộ lọc chặn im lặng, hoặc cấu hình chuyển tiếp sai |
Chi tiết nghề quan trọng nhất trong bài này: thư trả về không tới ngay. Khi gặp lỗi tạm thời, máy chủ gửi không bỏ cuộc mà xếp thư vào hàng đợi và thử lại nhiều lần trong nhiều giờ. Với Gmail, quá trình này kéo dài tới khoảng 48 giờ trước khi báo thất bại vĩnh viễn — và trong thực tế Creps đã ghi nhận trường hợp thư trả về chỉ xuất hiện vào ngày thứ ba sau khi gửi.
Hệ quả rất cụ thể: kiểm tra sau mười phút rồi kết luận "không có lỗi, chắc thư đã tới" là kết luận sai. Với một lá thư quan trọng — báo giá, hợp đồng, hồ sơ thầu — phải mở lại cuộc hội thoại đó vào ngày hôm sau và ngày kế tiếp.
Ngược lại, có một loại thư trả về đến gần như tức thì, thường trong vòng dưới một phút: loại báo hộp thư không tồn tại hoặc bị từ chối thẳng. Nếu mười lăm giây sau khi gửi mà đã có mailer-daemon, đó là lỗi vĩnh viễn, không cần chờ thêm.
Bảng triệu chứng — nguyên nhân — cách xử lý
| Triệu chứng |
Nguyên nhân thường gặp |
Việc cần làm |
| Mất hết thư, không nhận được gì từ bên ngoài |
Bản ghi MX trống hoặc còn trỏ về nhà cung cấp cũ; tên miền hết hạn; có bản ghi CNAME đặt ở tên miền gốc làm vô hiệu hoá MX |
Chạy dig MX để xác nhận. Kiểm hạn tên miền. Nếu tên miền còn sống thì khai báo lại MX theo đúng hướng dẫn của nhà cung cấp email hiện tại |
| Chỉ mất thư từ một vài nơi, chỗ khác vẫn tới |
Máy chủ thư của bạn bị một vài nhà cung cấp lớn xếp vào danh sách đen; hoặc bên gửi có DMARC chặt trong khi thư của bạn đi qua một địa chỉ trung gian chuyển tiếp |
Xin bên gửi chụp lại thư trả về — mã lỗi trong đó chỉ thẳng ra nguyên nhân. Kiểm địa chỉ IP máy chủ thư trong các danh sách đen công khai |
| Thư của bạn rơi vào spam của khách |
SPF thiếu, sai, hoặc có hai bản ghi; chưa bật DKIM; không có DMARC; gửi thư hàng loạt từ máy chủ dùng chung |
Chuẩn hoá SPF về đúng một bản ghi, bật DKIM, công bố DMARC ở mức quan sát trước rồi siết dần |
| Gửi đi được nhưng không nhận được |
Đúng là vấn đề MX. Gửi và nhận là hai đường độc lập: gửi dùng máy chủ SMTP của nhà cung cấp, nhận phụ thuộc hoàn toàn vào MX |
Đừng dùng "vẫn gửi được" làm bằng chứng email còn hoạt động. Kiểm bằng bước 1 và bước 4 |
| Nhận được nhưng gửi đi bị từ chối |
Hộp thư bị nhà cung cấp hạn chế do nghi gửi thư rác; mật khẩu ứng dụng hết hiệu lực; IP máy chủ bị liệt kê đen |
Đọc mã lỗi trong thư trả về. 554 5.7.1 gần như luôn là vấn đề danh tiếng hoặc xác thực, không phải vấn đề địa chỉ |
Một trường hợp riêng đáng cảnh báo: hộp thư bật chế độ nhận tất cả (catch-all). Khi đó mọi địa chỉ sai chính tả — infor@, inf0@ — đều được chấp nhận, nên không bao giờ có thư trả về. Nhìn từ ngoài, hệ thống hoạt động hoàn hảo. Thực tế là thư nằm trong một hộp mà nhiều tháng không ai mở.
SPF, DKIM, DMARC nói gì với hộp thư của khách
Ba chữ viết tắt này nghe kỹ thuật, nhưng ý tưởng đằng sau rất đời thường.
Hãy hình dung thư điện tử như một phong bì gửi qua bưu điện, và phong bì đó cho phép người gửi tự viết bất cứ tên nào ở mục người gửi. Đó là thiết kế gốc của email từ những năm 1980, khi Internet còn nhỏ và mọi người tin nhau. Ngày nay, bất kỳ ai cũng có thể gửi một lá thư đề tên công ty bạn.
Vì thế mỗi hộp thư nhận đều đóng vai người gác cổng, và họ hỏi ba câu:
- SPF trả lời câu "lá thư này có xuất phát từ nơi được phép không?" — giống danh sách các bưu cục được quyền đóng dấu nhân danh công ty bạn.
- DKIM trả lời câu "nội dung có bị sửa dọc đường không, chữ ký có khớp không?" — giống con dấu niêm phong trên nắp phong bì.
- DMARC trả lời câu "nếu hai câu trên không qua thì làm gì?" — là chỉ dẫn do chính bạn công bố.
Không khai báo gì cả thì người gác cổng không có căn cứ nào để tin bạn. Họ không chặn hẳn — họ làm việc khó chịu hơn: cho thư vào spam. Bạn vẫn thấy "đã gửi", khách vẫn không thấy gì, và cả hai bên đều không biết chuyện gì đang xảy ra.
Đây cũng là lý do nhiều công ty than phiền "báo giá gửi khách hàng không bao giờ được trả lời". Trong không ít trường hợp, vấn đề không nằm ở nội dung báo giá.
Điểm cần nhớ khi đọc tài liệu cấu hình: cả ba thứ này đều là bản ghi DNS, đều do bạn kiểm soát, và đều không tự động chuyển theo khi bạn đổi nhà cung cấp email. Hướng dẫn chính chủ về giá trị MX cần khai báo nằm tại tài liệu Google Workspace; các nhà cung cấp khác đều có trang tương đương.
Quy thiệt hại ra tiền
Phần khó chịu nhất của sự cố này là bạn không thể đo hậu quả của nó, vì thứ bị mất là những lá thư chưa từng xuất hiện.
Nhưng ước lượng được. Lấy ba con số bạn tự biết:
- Trung bình mỗi tháng có bao nhiêu người liên hệ hỏi giá qua email.
- Trong số đó bao nhiêu phần trăm thành khách hàng.
- Giá trị trung bình một đơn hàng.
Nhân ba số đó với số tháng mà email đã hỏng. Với những trường hợp Creps từng khảo sát, khoảng thời gian này thường không tính bằng tuần — nó tính bằng quý, vì không có tín hiệu nào để ai đó phát hiện sớm hơn.
Có ba khoản thiệt hại nữa không nằm trong phép nhân trên.
Khách nghĩ bạn phớt lờ họ. Người viết thư hỏi giá mà không được hồi âm không kết luận "email của họ hỏng". Họ kết luận "chỗ này làm ăn không nghiêm túc" rồi chuyển sang đối thủ. Bạn mất đơn hàng và mất luôn thiện cảm.
Hồ sơ, thông báo và cảnh báo hệ thống cũng đi qua email. Thư mời thầu, hoá đơn điện tử, thông báo gia hạn tên miền, cảnh báo bảo mật từ chính website của bạn — tất cả đều gửi tới địa chỉ quản trị. Một hộp thư quản trị chết sẽ kéo theo dây chuyền: không ai nhận được nhắc gia hạn tên miền, tên miền hết hạn, website sập, và lúc đó vấn đề đã lớn hơn nhiều. Chuyện này liên quan trực tiếp tới các ca tên miền rơi vào tay người khác, xem thêm bài website doanh nghiệp bỗng chuyển hướng sang trang cờ bạc.
Chi phí phục hồi tăng theo thời gian. Sửa cấu hình MX là việc của một buổi. Lấy lại một tên miền đã bị người khác đăng ký thì không có gì bảo đảm.
Chuyển nhà cung cấp email mà không mất thư
Phần lớn ca "email công ty bỗng dưng chết" mà Creps gặp đều bắt đầu từ một việc tưởng vô hại: đổi hosting, đổi nhà đăng ký tên miền, hoặc chuyển sang gói email mới. Ai đó cập nhật DNS, các bản ghi cũ biến mất, và không ai kiểm lại phần thư.
Quy trình dưới đây kéo dài khoảng một tuần nhưng gần như loại bỏ rủi ro.
1. Chép lại toàn bộ cấu hình cũ trước khi đụng vào bất cứ thứ gì. Chạy ba lệnh sau và lưu kết quả ra file:
dig MX tenmien.com @8.8.8.8 +short
dig TXT tenmien.com @8.8.8.8 +short
dig TXT _dmarc.tenmien.com @8.8.8.8 +short
Đây là bản chụp hiện trạng. Nếu có sự cố, nó cho phép bạn quay về đúng cấu hình cũ trong vài phút thay vì gọi điện hỏi nhà cung cấp cũ — bên mà lúc đó bạn vừa chấm dứt hợp đồng.
2. Giảm TTL trước 24–48 giờ. TTL là khoảng thời gian các máy chủ DNS trên thế giới được phép nhớ bản ghi cũ. Nếu TTL đang là 24 giờ và bạn đổi MX ngay, sẽ có nơi tiếp tục gửi thư về máy chủ cũ suốt cả ngày hôm sau. Hạ TTL xuống mức thấp, chẳng hạn 300 giây, chờ hết khoảng TTL cũ, rồi mới đổi. Đây là bước hay bị bỏ nhất và cũng là bước tạo ra nhiều thư thất lạc nhất.
3. Dựng xong hộp thư mới trước khi trỏ MX. Tài khoản phải tồn tại và đăng nhập được ở phía nhà cung cấp mới trước thời điểm chuyển. Trỏ MX về một nơi chưa có hộp thư nào là cách chắc chắn nhất để tạo ra một khoảng thời gian mất thư.
4. Giữ hộp thư cũ chạy song song ít nhất hai tuần. Đừng huỷ dịch vụ cũ trong ngày chuyển. Thư đến muộn, thư đang nằm trong hàng đợi thử lại, và thư từ những nơi còn nhớ bản ghi cũ vẫn sẽ rơi vào đó.
5. Kiểm ngay sau khi đổi, rồi kiểm lại sau 24 giờ. Chạy lại dig MX, gửi thư thử từ một hộp thư bên ngoài theo bước 4, và nhớ mở lại cuộc hội thoại đó vào hôm sau để bắt các thư trả về đến muộn.
6. Đừng quên SPF và DKIM. Đổi nhà cung cấp thì máy chủ gửi thư cũng đổi. Bản ghi SPF cũ vẫn cho phép máy chủ cũ và chưa cho phép máy chủ mới — hệ quả là thư của bạn gửi đi bắt đầu rơi vào spam của khách trong khi hộp thư đến trông vẫn hoàn toàn bình thường. Đây là lý do nhiều công ty nghĩ mọi thứ đã ổn sau khi chuyển, cho tới khi khách hàng phàn nàn vài tuần sau.
Nếu tên miền của bạn là .vn, thông tin đăng ký và tình trạng hiệu lực tra được tại công cụ tra cứu của VNNIC — nên kiểm hạn tên miền cùng lúc với kiểm MX, vì hai thứ này thường chết cùng nhau.
Khi nào tự làm được, khi nào nên gọi người
Tự làm được: chạy bốn bước kiểm tra ở trên, đọc thư trả về, gia hạn tên miền, khai báo lại MX theo hướng dẫn có sẵn của nhà cung cấp email khi bạn còn quyền truy cập trang quản trị DNS.
Nên gọi người: khi tên miền đã bị người khác đăng ký; khi thư của bạn bị nhiều nhà cung cấp lớn chặn cùng lúc; khi có dấu hiệu tên miền bị mạo danh để gửi thư rác; hoặc đơn giản là khi bạn không rõ ai đang giữ quyền quản trị DNS của công ty — tình huống phổ biến đến bất ngờ ở doanh nghiệp đã qua vài đời người phụ trách kỹ thuật.
Ranh giới thực tế: nếu bạn đọc được kết quả dig và biết mình đang thay đổi cái gì, hãy tự làm. Nếu bạn phải đoán, thì mỗi lần đoán sai là thêm một khoảng thời gian mất thư mà không ai đo được.
Câu hỏi thường gặp
Không có bản ghi MX thì email có bị vào spam không?
Không — nó nghiêm trọng hơn spam. Vào spam nghĩa là thư vẫn tới nơi, chỉ nằm sai thư mục và vẫn có thể tìm lại. Không có MX nghĩa là thư không tới hộp thư nào cả: hoặc bị trả về người gửi, hoặc bị một máy chủ nào đó nhận rồi vứt bỏ mà không báo cho ai.
Tôi vẫn gửi email đi được bình thường, vậy email công ty có sao không?
Có thể vẫn có vấn đề. Gửi và nhận là hai đường hoàn toàn tách biệt: khi gửi, phần mềm của bạn kết nối thẳng tới máy chủ SMTP của nhà cung cấp và không hề tra bản ghi MX của chính tên miền bạn. Vì vậy chức năng gửi vẫn chạy tốt ngay cả khi MX đã bị xoá sạch. Chỉ có bước 1 và bước 4 mới trả lời được câu hỏi về chiều nhận.
Gửi thử không thấy báo lỗi, có phải là thư đã tới không?
Không. Thư trả về có thể xuất hiện sau vài giờ tới ba ngày, vì máy chủ gửi còn thử lại nhiều lượt trước khi bỏ cuộc. Ngoài ra có những trường hợp thư bị nuốt im lặng và sẽ không bao giờ có báo lỗi nào. Cách duy nhất chắc chắn là kiểm hộp thư đến của bên nhận.
Tên miền hết hạn thì email mất luôn phải không?
Đúng. Khi tên miền ngừng hiệu lực, toàn bộ bản ghi DNS của nó — gồm cả MX — ngừng hoạt động, nên website và email chết cùng lúc. Gia hạn kịp thời thì mọi thứ trở lại sau khi DNS lan truyền xong. Để quá hạn tới mức tên miền được bán lại cho người khác thì đó là chuyện hoàn toàn khác, phức tạp và tốn kém hơn nhiều.
Mã 550 và 554 khác nhau thế nào?
550 5.1.1 nói về địa chỉ: hộp thư đó không tồn tại. 554 nói về sự tin cậy: thư bị từ chối vì chính sách bên nhận, thường do xác thực không qua hoặc máy chủ gửi bị liệt vào danh sách đen. Sửa hai loại này là hai việc hoàn toàn khác nhau. Danh sách đầy đủ các mã trả về của máy chủ thư có thể tra tại Wikipedia.
Việc nên làm ngay hôm nay
Mở Terminal, chạy dig MX tenmien.com @8.8.8.8 +short với tên miền công ty bạn, và nhìn kết quả. Mất mười giây.
Nếu có dòng trả về, mở tiếp một hộp thư không liên quan, gửi một lá thư thử, rồi ngày mai quay lại đọc cuộc hội thoại đó. Mất thêm hai phút chờ qua đêm.
Hai việc này không đòi hỏi kiến thức chuyên môn và trả lời được câu hỏi mà không bảng điều khiển nào trả lời cho bạn: hộp thư công ty có đang thật sự nhận được thư của khách hay không.
Nếu kết quả có gì bất thường, hoặc bạn không rõ ai đang giữ quyền quản trị DNS của tên miền công ty, Creps có thể rà giúp phần hạ tầng này — MX, SPF, DKIM, DMARC, hạn tên miền — cùng với các hạng mục khác trong mảng công nghệ. Bạn để lại thông tin ở trang liên hệ, chúng tôi kiểm và trả lời bằng kết quả lệnh cụ thể chứ không phải nhận định chung chung.