Khả năng gửi email
Khắc phục SPF PermError: Gộp hai chính sách TXT cho email công ty
Khi hai chính sách SPF TXT gây PermError, hãy xác định mọi nguồn gửi đang dùng, gộp quyền gửi vào một chính sách và kiểm tra DNS cùng thư thực tế.
Vì sao hai chính sách SPF TXT gây lỗi?
Nếu thư bị một số nơi từ chối sau khi kết nối công cụ gửi mới, hãy kiểm tra cùng một tên DNS có hai giá trị bắt đầu bằng v=spf1 không. RFC 7208 quy định trả về permerror khi chọn được nhiều chính sách SPF; các TXT phục vụ mục đích khác vẫn có thể tồn tại. PermError không đồng nghĩa mọi thư đều bị từ chối, vì vậy vẫn phải kiểm tra kết quả gửi thực tế.
Tìm tên miền được kiểm tra và nơi quản lý DNS
Đọc tên miền MAIL FROM được dùng để kiểm tra SPF trong thư trả lại hoặc kết quả xác thực; nó có thể khác From hiển thị. Tại dịch vụ quản lý nameserver có thẩm quyền, tra TXT của đúng tên đó. Phân biệt tên miền gốc và tên miền con, đếm giá trị v=spf1, rồi lưu cấu hình và kết quả thử trước khi sửa.
Quảng cáo
Kiểm kê nguồn gửi trước khi xóa
Ngoài hộp thư công ty, công cụ báo giá, thông báo đơn hàng và bản tin có thể gửi bằng cùng tên miền. Xóa bừa một chính sách có thể làm dịch vụ đang dùng mất xác thực. Ghi từng đường gửi, người phụ trách, lần dùng cuối, tên miền gửi và SPF hiện được nhà cung cấp hướng dẫn, rồi đối chiếu lịch sử gửi thật.
Gộp nguồn gửi được phép vào một chính sách
Đừng nối nguyên hai chuỗi SPF hoàn chỉnh. Chỉ dùng v=spf1 một lần ở đầu, rà soát include hoặc ip4 cần giữ và đặt một điều kiện kết thúc như ~all hoặc -all ở cuối. Ví dụ v=spf1 include:_spf.google.com include:sender.example ~all chỉ minh họa cấu trúc; sender.example không phải giá trị của nhà cung cấp thật. Hãy thay bằng hướng dẫn chính xác và đừng trộn chính sách của tên miền con riêng với tên miền gốc.
Kiểm tra cả giới hạn tra cứu DNS
Một bản ghi vẫn có thể lỗi nếu quá nhiều mục include, a, mx và mục gây tra cứu khác. RFC 7208 giới hạn số mục đó ở mức mười trong quá trình đánh giá. Hãy bỏ nguồn gửi không dùng trước, rồi dựa vào tài liệu nhà cung cấp và lịch sử thật để giữ phần còn lại. Ghim IP hoặc làm phẳng tùy tiện có thể bỏ lỡ thay đổi máy chủ của nhà cung cấp.
Kiểm tra DNS công khai và gửi thư thực tế riêng
Lưu thành công trong giao diện DNS chưa phải xong. Hãy tra lại DNS có thẩm quyền để chắc đúng tên chỉ có một SPF. Sau khi thay đổi có hiệu lực, gửi thư thử từ từng đường, gồm hộp thư nhân viên và thông báo giao dịch, tới hộp thư ngoài rồi đọc kết quả SPF. SPF đạt không bảo đảm tên miền From khớp hay DKIM, DMARC đạt. Hướng dẫn Gmail 550 và công cụ kiểm tra email tên miền có thể giúp bước tiếp theo, nhưng cấu hình thật phải đối chiếu tài liệu hiện hành của nhà cung cấp.
Mấu chốt là quản lý nguồn gửi, không chỉ gộp dòng
Chỉ kết thúc xử lý khi đúng tên chỉ có một SPF, mọi nguồn gửi đang dùng đều được phép và từng đường gửi thử đều đạt. Khi đổi dịch vụ, hãy cập nhật chính sách hiện có cùng danh sách phụ trách thay vì thêm một dòng SPF mới. Tài liệu liên quan gồm hướng dẫn lỗi xác thực Gmail 550, công cụ chẩn đoán email tên miền và quy tắc chọn bản ghi RFC 7208.
Quảng cáo
Bắt đầu với OfficialMail
Bắt đầu vận hành với một hộp thư chính thức.
Dùng hộp thư chính làm địa chỉ chính thức của công ty và xem các giá trị kết nối tên miền ngay trong hộp thư.