Defaults.Exposed › Cách khắc phục › Guides

SPF Ngừng Hoạt Động Sau Khi Chuyển Đổi Nhà Cung Cấp Email — Cách Sửa Sau Di Chuyển (2026)

Đã xuất bản 2026-07-08

Số liệu tính đến 2026-06-29 · phương pháp luận v7. Dữ liệu tổng hợp từ 261 triệu tên miền được chấm điểm. Xem cách chúng tôi chấm điểm.

SPF thường hỏng sau khi chuyển đổi nhà cung cấp email vì bản ghi của nhà cung cấp mới được thêm cạnh bản ghi cũ. Hai bản ghi v=spf1 là lỗi vĩnh viễn — SPF hoàn toàn vô hiệu. 1,013,416 tên miền — khoảng một trong 138 trong số những tên miền cố gắng SPF — đang ở trạng thái đó, theo dữ liệu khảo sát 261 triệu tên miền của Defaults.Exposed. Hãy hợp nhất chúng thành một.

Cách sửa mất khoảng mười phút: quét tên miền để xem chính xác di chuyển để lại gì, liệt kê mọi bản ghi SPF tại nameserver có thẩm quyền, hợp nhất chúng thành một bản ghi chỉ bao gồm nhà cung cấp mới của bạn, và xác minh lại với dig. Hướng dẫn này đi qua từng bước, cộng với kiểm tra DKIM và nameserver mà hầu hết các di chuyển bỏ quên.

Tại sao SPF hỏng ngay sau khi di chuyển?

Vì hướng dẫn cài đặt của nhà cung cấp mới nói “thêm bản ghi TXT này” — và bạn đã làm, cạnh bản ghi cũ. Đó là điều duy nhất mà chuẩn SPF không cho phép. RFC 7208 (§3.2, kết quả lỗi được quy định trong §4.5) cho phép đúng một bản ghi v=spf1 trên mỗi tên miền; máy chủ nhận tìm thấy hai hoặc nhiều hơn phải trả về PermError thay vì đoán cái nào có thẩm quyền. PermError có nghĩa là SPF vô hiệu: không phải bản ghi cũ, không phải bản ghi mới, không có SPF nào cả.

Và nó không dừng ở đó. DMARC coi PermError là lỗi trên chân SPF, vì vậy thư của bạn giờ hoàn toàn phụ thuộc vào DKIM. Nếu DKIM của nhà cung cấp mới cũng chưa được cài đặt — phổ biến giữa chừng di chuyển — bạn đang gửi không có xác thực đúng vào thời điểm bạn thay đổi hạ tầng, khi máy chủ nhận kiểm tra bạn kỹ nhất.

Đây là sao chép-dán vô hiệu bảo vệ khi bạn chuyển đổi nhà cung cấp, và nó không hiếm: 1,013,416 tên miền xuất bản hai hoặc nhiều bản ghi SPF ngay bây giờ — khoảng một trong 138 trong số dân số 139 triệu cố gắng SPF, theo dữ liệu khảo sát 261 triệu tên miền của Defaults.Exposed (dữ liệu tính đến 2026-06-29). Con số đầy đủ về bẫy hai bản ghi có báo cáo riêng; trang này là cách sửa thủ tục.

Di chuyển để lại gì phía sau?

Năm di vật gây ra hầu hết mọi lỗi SPF sau di chuyển. Kiểm tra theo thứ tự này:

Cách sửa? Danh sách kiểm tra di chuyển

1. Chạy quét miễn phí tại defaults.exposed trước. Nó đọc DNS thực của bạn và cho bạn biết bạn có nhiều bản ghi SPF, include bị thiếu, hoặc khoảng trống DKIM — chẩn đoán trước khi chạm vào bất cứ thứ gì.

2. Liệt kê mọi bản ghi SPF tại nameserver có thẩm quyền. dig +short NS yourdomain.com, rồi dig +short TXT yourdomain.com @<nameserver> với một trong số chúng. Đếm các chuỗi bắt đầu v=spf1. Số an toàn duy nhất là 1.

3. Hợp nhất thành một bản ghi. Một bản ghi, bắt đầu v=spf1, chứa include của nhà cung cấp mới và bất kỳ nguồn gửi nào khác bạn vẫn dùng (công cụ hóa đơn, CRM, nền tảng newsletter), một -all hoặc ~all cuối cùng. Ví dụ — Google Workspace cũ, Microsoft 365 mới, đang xả:

   Before:  "v=spf1 include:_spf.google.com ~all"
            "v=spf1 include:spf.protection.outlook.com -all"
   
   After:   "v=spf1 include:spf.protection.outlook.com include:_spf.google.com -all"
   Later:   "v=spf1 include:spf.protection.outlook.com -all"
   

   Các giá trị nhà cung cấp và quirk của bảng điều khiển DNS nằm trong các hướng dẫn cài đặt cho Google Workspace và Microsoft 365.

4. Xóa các bản ghi thừa. Hợp nhất mà không xóa không sửa được gì — PermError đến từ số lượng.

5. Chỉ giữ include của nhà cung cấp cũ trong khi hệ thống cũ vẫn còn gửi — báo cáo theo lịch trình, một kết nối CRM cũ, một hộp thư bị quên. Khi quá trình xả đã xong, hãy xóa nó: include cũ để lại hạ tầng cũ được phép gửi thay mặt bạn, và mỗi include tốn tra cứu DNS theo giới hạn cứng 10 của SPF — ít nhất 797,263 tên miền đã vô hiệu SPF bằng cách vượt quá giới hạn đó (khảo sát, 2026-06-29).

6. Cài đặt DKIM của nhà cung cấp mới — và chưa xóa selector cũ. Selector mới ký thư mới; selector cũ phải tiếp tục được xuất bản cho đến khi mọi thư được ký với chúng đã được chuyển và mọi forward đã ổn định. Hướng dẫn đầy đủ trong DKIM lỗi sau khi chuyển đổi công cụ email.

7. Nếu bạn cũng đã thay đổi nameserver, kiểm tra cả hai. Di chuyển DNS thường đi cùng với di chuyển email. Truy vấn trực tiếp bộ NS cũ và mới (dig TXT yourdomain.com @old-ns và @new-ns) — cho đến khi ủy quyền đăng ký hoàn toàn lan truyền, một số máy chủ nhận vẫn hỏi máy chủ cũ, vì vậy bản ghi đã sửa phải tồn tại tại bất kỳ bộ nào trả lời.

8. Chạy lại quét và xác nhận SPF hiển thị một bản ghi hợp lệ với kết quả pass.

SPF thực sự kiểm tra tên miền nào?

Máy chủ nhận đánh giá SPF theo tên miền Return-Path (RFC5321.MailFrom) — địa chỉ bounce — không phải header From mà người nhận thấy. Sau khi di chuyển, điều này quan trọng hai lần: nhà cung cấp mới của bạn có thể dùng tên miền bounce của chính họ cho đến khi bạn cấu hình cái tùy chỉnh, và SPF “vượt qua” trên tên miền không phải của bạn sẽ không căn chỉnh cho DMARC. Cách sửa cho điều đó là DKIM của nhà cung cấp mới, được ký với tên miền của bạn.

Di chuyển và đổi tên thương hiệu cùng một lúc?

Cũng thay đổi tên miền cùng với nhà cung cấp? Hãy coi chúng là hai công việc riêng biệt. Tên miền mới cần toàn bộ stack — SPF, DKIM, DMARC — từ ngày đầu tiên; dùng danh sách kiểm tra email cho tên miền mới. Tên miền cũ vẫn được xác thực miễn là chuyển tiếp hoặc lưu lượng trả lời chạy qua nó, và được khóa rõ ràng (không chỉ bị bỏ rơi) khi nó được đậu. Tên miền cũ với SPF cũ nửa vời, bị hỏng là mục tiêu giả mạo mang tên cũ của bạn.

Câu hỏi thường gặp

Có thể giữ hai bản ghi SPF trong khi di chuyển không? Không. Không có thời gian ân hạn trong chuẩn — hai bản ghi v=spf1 là PermError từ thời điểm bản ghi thứ hai tồn tại, và 1,013,416 tên miền đang ở trạng thái đó tính đến thời điểm khảo sát (2026-06-29). Mẫu an toàn cho di chuyển là một bản ghi mang includes của cả hai nhà cung cấp trong thời gian chồng lấp.

Tôi nên giữ include của nhà cung cấp cũ bao lâu? Cho đến khi không có gì gửi qua nhà cung cấp cũ — thường là độ dài của cửa sổ chồng lấp, từ vài ngày đến vài tuần. Xem Return-Path của bất cứ thứ gì vẫn đến qua hệ thống cũ; khi lưu lượng đó dừng, xóa include và kiểm tra lại số tra cứu.

Tại sao công cụ kiểm tra vẫn hiển thị bản ghi cũ sau khi tôi đã sửa? Bộ đệm DNS tôn trọng TTL của bản ghi, và nếu nameserver của bạn đã thay đổi, một số resolver vẫn truy vấn bộ cũ. Xác minh trực tiếp tại nameserver có thẩm quyền với dig TXT yourdomain.com @<ns> — nếu câu trả lời đúng ở đó, cách sửa đã hoàn thành và bộ đệm sẽ bắt kịp. Nếu sai ở một bộ NS, xem ‘SPF record not found’ — các nguyên nhân thực sự.

Tôi có cần thay đổi DMARC khi chuyển đổi nhà cung cấp không? Thường không phải bản thân bản ghi — nó đặt tên hộp thư báo cáo và chính sách của bạn, không phải nhà cung cấp. Nhưng kết quả DMARC của bạn phụ thuộc vào SPF và DKIM bạn vừa di chuyển: mong đợi sụt giảm trong báo cáo trong quá trình chuyển đổi, và xác nhận cả hai chân vượt qua trước khi thắt chặt chính sách. Bắt đầu tại sửa SPF nếu quét cho thấy chân SPF vẫn đang lỗi.

Gửi báo cáo cho chủ sở hữu

Nếu bạn đang thực hiện di chuyển này cho khách hàng, hãy kết thúc với bằng chứng. Chạy lại quét miễn phí khi quá trình hợp nhất đã hoạt động và chuyển tiếp báo cáo được chấm điểm cho chủ doanh nghiệp: SPF, DKIM và DMARC vượt qua trên nhà cung cấp mới, bằng ngôn ngữ đơn giản, có ngày tháng. Đây là tài liệu họ lưu cho đợt tái tục bảo hiểm mạng và bảng câu hỏi bảo mật nhà cung cấp tiếp theo — bằng chứng di chuyển để lại tên miền được xác thực tốt hơn so với khi bắt đầu.

Kiểm tra tên miền → · DKIM lỗi sau khi chuyển đổi công cụ email → · ‘SPF record not found’ — các nguyên nhân thực sự → · Cách chúng tôi chấm điểm → · Chỉ dữ liệu tổng hợp. Dữ liệu được lưu trữ và xử lý tại EU.