Khi một email xác thực bị trễ, nút gửi lại thường là câu trả lời hiển nhiên. Nó thường làm tình hình tồi tệ hơn: nhiều tin nhắn đến cùng lúc, chỉ mã mới nhất còn hiệu lực, và không ai biết yêu cầu nào tạo ra tin nào.
Xem quá trình giao hàng như một chuỗi các điểm kiểm tra. Tìm điểm kiểm tra cuối cùng chắc chắn đã thành công, sau đó kiểm tra điểm tiếp theo.
Đầu tiên, ghi lại bằng chứng
Trước khi yêu cầu một tin nhắn khác, ghi lại:
- địa chỉ người nhận chính xác;
- thời gian bạn nhấn nút gửi;
- tên người gửi hoặc dịch vụ;
- trang có báo cáo thành công hay không;
- đây là yêu cầu đầu tiên hay là lần gửi lại;
- thời gian hết hạn dự kiến, nếu có hiển thị.
Giữ trang người gửi mở. Một lỗi đánh máy được phát hiện hai phút sau sẽ dễ sửa hơn khi biểu mẫu gốc vẫn còn giá trị đã nhập.
Kiểm tra địa chỉ, không phải trí nhớ của bạn
So sánh địa chỉ đã nhập với địa chỉ hiển thị bởi GPTMail. Kiểm tra phần địa chỉ cục bộ, mọi dấu chấm hoặc chữ số, và phần hậu tố miền. Đặc biệt chú ý khi có nhiều tab hộp thư mở hoặc bạn vừa thay đổi miền được chọn.
Sau đó xác nhận miền đang hoạt động trên trang miền. Một địa chỉ có thể hợp lệ về mặt cú pháp trong khi miền của nó đã bị vô hiệu hoá hoặc không còn được định tuyến tới GPTMail.
Nếu website từ chối địa chỉ trước khi gửi, thì chưa có vấn đề giao hàng. Tạo một địa chỉ hỗ trợ khác và gửi lại.
Xác nhận người gửi thực sự đã bắt đầu giao hàng
Một tin nhắn thành công trên website đôi khi chỉ có nghĩa là một công việc nền đã được tạo. Người gửi có thể vẫn đang xếp hàng, giới hạn tốc độ, hoặc thử lại email.
Chờ vài phút trước khi gửi lại. Nếu dịch vụ cung cấp nhật ký hoạt động, kiểm tra xem nó có ghi lại yêu cầu xác thực không. Đối với sản phẩm bạn vận hành, kiểm tra hàng đợi ứng dụng và sự kiện của nhà cung cấp mail thay vì chỉ nhìn vào hộp thư đến.
Làm mới một lần, sau đó tìm tin nhắn đúng
Sử dụng làm mới thủ công và sắp xếp theo thời gian đến. Tìm kiếm người gửi và tiêu đề dự kiến, không chỉ tên dịch vụ trong bản xem trước. Mail tự động và marketing có thể đến từ các phụ miền khác nhau.
Nếu có nhiều mã đến, dùng yêu cầu mới nhất. Nhiều hệ thống vô hiệu hoá các mã cũ ngay khi một mã thay thế được phát hành.
Tách vấn đề người gửi khỏi vấn đề miền
Gửi một tin nhắn thử ngắn dạng plain‑text tới cùng địa chỉ từ một nhà cung cấp không liên quan.
- Nếu tin thử đến, miền nhận hoạt động và người gửi gốc bị trễ, lọc địa chỉ, hoặc thất bại trước khi chuyển giao.
- Nếu không tin nào đến, kiểm tra trạng thái miền và cấu hình MX.
- Nếu tin từ một nhà cung cấp đến nhưng nhà cung cấp khác luôn không đến, thu thập người gửi, thời gian, và bất kỳ chi tiết bounce nào trước khi báo cáo.
Đối với miền tùy chỉnh, tham khảo Cài Đặt MX Miền Tùy Chỉnh Không Đoán. Không thay đổi DNS một cách ngẫu nhiên trong khi thử nghiệm trực tiếp; mỗi thay đổi tạo ra một cửa sổ lan truyền mới.
Hiểu các lỗi DNS phổ biến
Một truy vấn MX có thể tạm thời thất bại vì bộ giải quyết thời gian chờ, máy chủ tên có thẩm quyền không đồng ý, xác thực DNSSEC thất bại, hoặc bản ghi chưa lan truyền. “Không phát hiện bản ghi” là kết quả của một truy vấn tại một thời điểm cụ thể, không phải bằng chứng rằng bản ghi không tồn tại.
Truy vấn phản hồi DNS có thẩm quyền và so sánh mục tiêu thực tế với mục tiêu hiển thị bởi GPTMail. Nếu chúng khớp, chờ và thử lại. Nếu không khớp, sửa bản ghi có thẩm quyền.
Khi tin nhắn đến nhưng mã không hợp lệ
Giao hàng và xác thực là hai hệ thống riêng biệt. Một mã có thể không hợp lệ vì:
- một mã mới hơn đã thay thế nó;
- mã đã hết hạn trong quá trình truyền;
- nó thuộc phiên duyệt web hoặc tài khoản khác;
- có khoảng trắng được sao chép cùng mã;
- trang đích đang dùng môi trường khác;
- đồng hồ hoặc trạng thái của người gửi sai.
Yêu cầu một mã mới, chờ tin nhắn cụ thể đó, và dùng nó một lần. Nếu vẫn không hợp lệ, báo cáo thời gian yêu cầu và thời gian tin nhắn cùng nhau.
Báo cáo hỗ trợ ngắn gọn
Báo cáo hữu ích bao gồm địa chỉ người nhận, địa chỉ người gửi, tiêu đề, dấu thời gian UTC, liệu một người gửi thứ hai có tới hộp thư không, và lỗi chính xác hiển thị bởi người gửi. Loại bỏ mã xác thực và liên kết riêng tư trước khi chia sẻ log công khai.
“Không có email” khó điều tra. “Yêu cầu tin nhắn lúc 14:03 UTC; nhà cung cấp thứ hai đến lúc 14:05; người gửi dự kiến không tạo tin nhắn hoặc bounce tới 14:15” xác định phía thất bại.
Biết khi nào nên dừng chờ
Nếu tài khoản quan trọng và dịch vụ cung cấp phương thức xác thực khác, hãy dùng nó. Nếu đăng ký ít rủi ro, tạo một địa chỉ hỗ trợ mới và bắt đầu lại. Đừng để hộp thư tạm thời là con đường phục hồi duy nhất cho tài khoản bạn dự định giữ.
Hướng dẫn quyết định rộng hơn nằm ở Email Tạm Thời, Sử Dụng Hiệu Quả.