Hướng dẫn xử lý lỗi không nhận được email từ website
Khoanh vùng lỗi form, lưu dữ liệu, SMTP và hộp thư nhận; kiểm tra đúng MailAccount, thông số ghi đè và kết quả gửi trên website.
Bài này giúp xử lý vấn đề gì?
Khi người dùng nói “website không gửi email”, cần xác định lỗi xảy ra trước khi gửi, ở kết nối SMTP hay ở hộp thư nhận. Mục tiêu là tìm đúng bước thất bại để sửa đúng cấu hình, tránh thay nhiều tham số cùng lúc hoặc gửi lặp dữ liệu liên hệ.
Trước khi kiểm tra, ghi địa chỉ trang, loại form, thời điểm thao tác và thông báo chính xác. Không cung cấp mật khẩu hoặc toàn bộ cấu hình chứa bí mật trong ảnh/chữ gửi cho người hỗ trợ.
Giao diện form ngoài website
Form chưa chấp nhận yêu cầu
Nếu form báo thiếu trường, sai mã xác nhận hoặc dữ liệu không hợp lệ, sửa nội dung theo thông báo trước. Khi luồng cũ dùng CAPTCHA và mã sai, nó không thực hiện gửi thư. Mã xác nhận có thể đổi sau lần sai; đọc mã mới trước khi thử lại.
Với form liên hệ động, thông báo biểu mẫu đã hết hạn hoặc đã gửi liên quan đến mã chống gửi lặp. Tải lại trang để có form mới rồi gửi một yêu cầu hợp lệ. Không giải quyết lỗi này bằng cách đổi mật khẩu SMTP.
Form báo đã nhận yêu cầu
Kiểm tra loại form. Khi UseContactAttributes bật trong ContactDynamic, hệ thống lưu liên hệ và báo đã nhận yêu cầu; nhánh này không gọi đoạn gửi SMTP của luồng cũ. Không có thư trong trường hợp này có thể là do chức năng thông báo chưa được triển khai cho luồng đang dùng, không phải sự cố nhà cung cấp email.
Form báo không gửi được mail thông báo
Ghi nội dung lỗi và thời điểm, sau đó kiểm tra cấu hình gửi. Nếu có tùy chọn lưu khách, dữ liệu khách vẫn có thể được xử lý riêng sau lỗi gửi; cần đối chiếu trước khi gửi lại để tránh dữ liệu trùng.
Giao diện CMS: kiểm tra đúng người nhận và luồng gửi
Mở đúng module của trang đang kiểm tra. Trong ContactDynamic cũ, MailAccount là người nhận. Trống trường này thì bước gửi bị bỏ qua. Kiểm tra địa chỉ đầy đủ và đúng người phụ trách, không nhầm thành địa chỉ người gửi hoặc mật khẩu.
Đối với các chức năng khác, tên tham số giống nhau chưa đủ để kết luận vai trò giống nhau. Xác định module và hướng dẫn của chức năng đó, đặc biệt khi website có cả liên hệ, đăng ký tư vấn và giỏ hàng.
Giao diện cấu hình SMTP và các nhóm lỗi
Sai máy chủ, cổng hoặc bảo mật
Đối chiếu MailServer, MailPort và MailEnableSSL với thông tin dịch vụ thư đang sử dụng. Tên máy chủ SMTP khác địa chỉ đăng nhập webmail. Cổng và cơ chế bảo mật phải phù hợp với dịch vụ và thư viện gửi thư trên máy chủ.
Nếu có lỗi kết nối hoặc hết thời gian chờ, người vận hành máy chủ cần kiểm tra kết nối từ chính máy chạy website. Máy tính cá nhân vào webmail được không chứng minh máy chủ website gửi SMTP được.
Sai tài khoản hoặc mật khẩu thực tế
Trong nhánh ContactDynamic cũ, tài khoản đăng nhập và From lấy từ cấu hình chung. Chỉ khi MailServer và MailPassword riêng cùng có giá trị, chương trình mới thay máy chủ, cổng, SSL và mật khẩu; tài khoản và From vẫn là cấu hình chung.
Vì vậy, một bộ gồm máy chủ của hộp thư A, mật khẩu của B và tài khoản chung C rất dễ bị từ chối. Nhờ quản trị kiểm tra bộ thông số thực sự chạy thay vì chỉ nhìn trường MailAccount là địa chỉ nhận.
Nếu dùng Google với mật khẩu ứng dụng, đổi mật khẩu tài khoản Google có thể làm mật khẩu ứng dụng cũ bị thu hồi. Tạo lại theo chính sách của tài khoản khi được hỗ trợ và cập nhật đúng nơi lưu bí mật. Xem quy định mật khẩu ứng dụng của Google; không tìm cách bật cơ chế đăng nhập kém an toàn đã cũ.
Hệ thống báo gửi nhưng hộp thư chưa thấy
Kiểm tra Thư rác, mục lọc/quy tắc thư và địa chỉ nhận. Đối chiếu người gửi và tiêu đề để tìm đúng thông báo thử. Nếu cần, người quản trị email kiểm tra nhật ký giao nhận và phản hồi từ máy chủ nhận. Phản hồi thành công ở bước gửi không bảo đảm thư luôn nằm trong Inbox ngay lập tức.
Không xóa cache trình duyệt hoặc đổi địa chỉ cửa hàng để xử lý lỗi xác thực SMTP; hai dữ liệu đó không quyết định tài khoản đăng nhập máy chủ thư.
Giao diện dữ liệu liên hệ hoặc khách hàng
Tìm yêu cầu theo thời điểm và thông tin thử đã gửi. Nếu đã lưu, giữ lại bản ghi để đối chiếu, không gửi lại hàng chục lần. Với form động, kết quả lưu là bước cần kiểm tra chính. Với form cũ bật SaveCustomer, lưu khách và gửi mail có thể có kết quả khác nhau.
Nếu không có bản ghi và form cũng báo lỗi lưu, xử lý lỗi dữ liệu hoặc lưu trữ theo thông báo trước; sửa thư nhận không làm một yêu cầu chưa được chấp nhận trở thành hợp lệ.
Quy trình thử lại có kiểm soát
- Chọn một nguyên nhân có bằng chứng, ghi lại cấu hình cũ cần khôi phục và sửa đúng phần đó.
- Lưu cấu hình của đúng module hoặc nhờ kỹ thuật cập nhật cấu hình chung nếu cần.
- Gửi một yêu cầu thử mới có dấu hiệu nhận diện riêng và ghi thời gian.
- Đối chiếu thông báo form, bản ghi và hộp thư; đánh giá từng bước riêng.
- Khi đã thành công, xác nhận lại người nhận và bàn giao cách theo dõi cho nhân viên phụ trách.
Nếu cần hỗ trợ, cung cấp URL, tên module, luồng form, thời điểm, thông báo lỗi và kết quả có/không lưu dữ liệu. Các thông tin này giúp khoanh vùng nhanh hơn việc chỉ báo “mail không chạy”. Không cần gửi mật khẩu để mô tả vấn đề.
