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

DKIM Lỗi Sau Khi Chuyển Đổi Công Cụ Email: Hướng Dẫn Di Chuyển CNAME và Selector (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.

DKIM hỏng sau khi chuyển đổi công cụ vì hai lý do cơ học: bảng điều khiển DNS của bạn đã làm hỏng CNAME target của công cụ mới — thường bằng cách thêm zone của chính bạn — hoặc selector của công cụ cũ đã bị xóa trước khi thư của nó được xử lý. Chỉ 3.87% tên miền — 10,092,481 — hoàn thành bộ ba SPF+DKIM+DMARC, theo dữ liệu khảo sát 261,086,232 tên miền được chấm điểm của Defaults.Exposed.

Thứ tự sửa: quét tên miền, sau đó kiểm tra target được lưu của mỗi CNAME mới bằng dig — target kết thúc bằng tên miền của chính bạn là bằng chứng rõ ràng. Sửa bản ghi tại nameserver có thẩm quyền, xác nhận công cụ mới ký và vượt qua trước khi định tuyến thư thực qua nó, và giữ selector của công cụ cũ được xuất bản cho đến khi lưu lượng của nó được xử lý.

Tại sao DKIM hỏng khi bạn chuyển đổi công cụ?

Không có gì về chính DKIM thay đổi — selector của bạn đã thay đổi. Công cụ cũ ký với selector của nó; công cụ mới ký với selector khác, thường được ủy quyền qua hai hoặc ba bản ghi CNAME được thêm trong quá trình onboarding. Bốn sai sót chiếm hầu hết mọi lỗi DKIM sau di chuyển:

1. Bảng điều khiển DNS của bạn đã thêm zone vào CNAME target. Nhiều bảng điều khiển coi bất kỳ hostname nào được dán là tương đối và lặng lẽ lưu target.provider.com.yourdomain.com thay vì target.provider.com. Bản ghi tồn tại, bảng điều khiển hiển thị tick xanh, và nó không phân giải được gì.
2. Nhầm lẫn trailing dot. Một số bảng điều khiển yêu cầu trailing dot (target.provider.com.) để có nghĩa là “tuyệt đối — ngừng thêm zone”; những cái khác từ chối dấu chấm là không hợp lệ và tự xử lý tính tuyệt đối. Cùng giá trị được dán là đúng trong một bảng điều khiển và bị làm hỏng trong bảng tiếp theo.
3. Selector của công cụ cũ bị xóa vào ngày chuyển đổi. Thư mà công cụ cũ đã ký nằm trong hàng đợi thử lại và đường dẫn chuyển tiếp trong nhiều ngày; xóa selector của nó — hoặc đóng tài khoản cũ, điều này xóa CNAME được ủy quyền — hồi tố làm hỏng thư đó.
4. Bạn xác minh tại sai nameserver. Nếu di chuyển bao gồm thay đổi nameserver, các bản ghi đã sửa có thể tồn tại tại một bộ NS trong khi máy chủ nhận vẫn truy vấn bộ kia.

Chỉ 51.84% trong 261 triệu tên miền trong khảo sát trình bày khóa DKIM có thể phát hiện tại thời điểm quét (dữ liệu tính đến 2026-06-29).

Cùng di chuyển thường để lại rác SPF — 1,013,416 tên miền, khoảng 1 trong 138 trong số những tên miền cố gắng SPF, chạy hai bản ghi v=spf1, dấu hiệu điển hình của việc chuyển đổi nhà cung cấp đã thêm bản ghi thay vì hợp nhất. Phần di chuyển đó có hướng dẫn riêng: SPF ngừng hoạt động sau khi bạn chuyển đổi nhà cung cấp email.

Làm thế nào để phát hiện bản ghi CNAME bị làm hỏng?

Đừng tin vào bảng điều khiển — hỏi DNS những gì nó thực sự lưu. Truy vấn CNAME target cho mỗi selector mà công cụ mới cung cấp. Ví dụ minh họa, mô phỏng selector được ủy quyền kiểu SendGrid (hình dạng target của nhà cung cấp sẽ khác nhau):

$ dig CNAME s1._domainkey.yourdomain.com +short
s1.domainkey.u1234567.wl123.sendgrid.net.yourdomain.com.

Nhà cung cấp yêu cầu s1.domainkey.u1234567.wl123.sendgrid.net — nhưng target được lưu kết thúc bằng .yourdomain.com. Bảng điều khiển đã thêm zone; tên đó không phân giải được gì, vì vậy máy chủ nhận không tìm thấy khóa. Phiên bản lành mạnh:

$ dig CNAME s1._domainkey.yourdomain.com +short
s1.domainkey.u1234567.wl123.sendgrid.net.

(Một trailing dot đơn trong đầu ra dig là bình thường — nó đánh dấu tên đầy đủ điều kiện.) Nếu target đúng, theo dõi nó một bước: dig TXT s1._domainkey.yourdomain.com +short nên trả về khóa của nhà cung cấp. Câu trả lời rỗng với CNAME đúng có nghĩa là vấn đề ở phía nhà cung cấp của ủy quyền — hoàn thành bước xác minh của họ, hoặc xem DKIM “no key for signature” để chẩn đoán cấp selector.

Sổ tay di chuyển: trước, trong, sau

Lỗi thường không phải ở bản ghi — mà ở thứ tự. Di chuyển DKIM gặp vấn đề tại thời điểm chuyển đổi vì xác minh xảy ra sau khi chuyển đổi, khi thư thực đã bắt đầu lỗi.

Hàng in đậm là nơi di chuyển được cứu hoặc mất: mọi kiểm tra trong đó có thể được thực hiện nhiều ngày trước khi chuyển đổi, không có rủi ro với thư thực. Cơ chế ngừng selector — bao gồm lý do tại sao xuất bản lại với p= rỗng tốt hơn xóa — được đề cập trong sổ tay xoay vòng; bảng này là về trình tự chuyển đổi công cụ.

Cách sửa DKIM sau khi chuyển đổi?

1. Chạy quét miễn phí tại defaults.exposed trước khi chạm vào DNS. Nó đọc bản ghi thực của bạn và hiển thị những gì máy chủ nhận thực sự thấy — bao gồm CNAME target bị thêm zone và selector không phân giải.
2. Liệt kê bản ghi DKIM mà công cụ mới yêu cầu. Từ bảng điều khiển admin của nó — đối với nhà cung cấp hộp thư, hướng dẫn cài đặt Google Workspace và Microsoft 365 cho thấy nơi; các công cụ newsletter và CRM liệt kê CNAME của họ trong xác thực tên miền (xem email Mailchimp/Brevo/Klaviyo lỗi DMARC).
3. Kiểm tra giá trị được lưu của mỗi bản ghi bằng dig CNAME <name> +short và so sánh từng ký tự với những gì công cụ yêu cầu. Target kết thúc bằng tên miền của chính bạn = bị thêm zone; nhập lại, và nếu bảng điều khiển tiếp tục thêm, hãy thêm trailing dot (hoặc xóa nó, nếu bảng điều khiển từ chối dấu chấm).
4. Xác minh tại nameserver có thẩm quyền. dig +short NS yourdomain.com, sau đó lặp lại kiểm tra CNAME @<nameserver đó>. Nếu di chuyển đã thay đổi nameserver, kiểm tra cả hai bộ — máy chủ nhận có thể vẫn truy vấn cái cũ cho đến khi ủy quyền lan truyền.
5. Chạy lại xác minh của công cụ và gửi thư kiểm tra. Header Authentication-Results nên hiển thị dkim=pass với d= bằng tên miền của bạn — vượt qua trên tên miền mặc định của công cụ không căn chỉnh cho DMARC.
6. Giữ selector của công cụ cũ được xuất bản cho đến khi thư của nó được xử lý, rồi ngừng chúng một cách có chủ ý. Sau đó quét lại, và xử lý mọi thứ khác được gắn cờ trên trang sửa DKIM.

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

Tôi có cần trailing dot trên DKIM CNAME không? Hoàn toàn phụ thuộc vào bảng điều khiển. Dấu chấm có nghĩa là “tên tuyệt đối — không thêm zone”; một số bảng điều khiển yêu cầu nó, một số tự thêm, một số từ chối. Kiểm tra duy nhất có ý nghĩa là đầu ra của dig CNAME <selector>._domainkey.yourdomain.com +short sau khi lưu: nếu target kết thúc bằng tên miền của chính bạn, bảng điều khiển đã thêm zone và bạn cần dấu chấm (hoặc định dạng nhập liệu khác).

Có thể xóa bản ghi DKIM của công cụ cũ vào ngày chuyển đổi không? Không. Thư mà công cụ cũ đã ký vẫn đang trong hàng đợi thử lại và đường dẫn chuyển tiếp, và xóa khóa nó trỏ đến hồi tố làm hỏng những thư đó. Giữ selector cũ hoạt động cho đến khi chúng ngừng xuất hiện trong báo cáo DMARC tổng hợp của bạn — một tuần hoặc hơn — và cũng đừng đóng tài khoản cũ trước thời điểm đó.

Bảng điều khiển DNS và công cụ mới đều nói “đã xác minh”, nhưng máy chủ nhận vẫn lỗi DKIM. Tại sao? Hai trường hợp phổ biến: công cụ xác minh với kiểm tra được cache trong khi nameserver có thẩm quyền phục vụ thứ khác (truy vấn trực tiếp với dig @<ns>), hoặc DKIM vượt qua nhưng trên tên miền ký mặc định của công cụ thay vì của bạn, vì vậy DMARC vẫn thất bại căn chỉnh. Quét phân biệt hai trường hợp.

Cả hai bản ghi DKIM của hai công cụ có thể cùng tồn tại trong thời gian chồng lấp không? Có — và chúng nên. DKIM không có quy tắc một bản ghi: mỗi selector là tên DNS riêng của nó, vì vậy bản ghi của cả hai công cụ sống cạnh nhau mà không có xung đột, điều này làm cho quy tắc giữ-selector-cũ-qua-thời-gian-xử-lý tự do tuân theo. (SPF thì ngược lại — hai bản ghi v=spf1 vô hiệu nó, đó là lý do hướng dẫn di chuyển SPF về việc hợp nhất.)

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 hoặc nhà tuyển dụng, hãy đóng nó với bằng chứng. Khi công cụ mới ký và căn chỉnh, chạy lại quét miễn phí và chuyển tiếp báo cáo được chấm điểm cho chủ doanh nghiệp: bằng chứng có ngày tháng, ngôn ngữ đơn giản rằng việc chuyển đổi để lại tên miền được xác thực đầy đủ. Đây là tài liệu họ cần 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 — nó biến “quá trình di chuyển đã hoàn thành” từ một tuyên bố thành một tài liệu.

Kiểm tra DKIM miễn phí

Xem selector của công cụ mới có phân giải không — và chính xác cần sửa gì — một cách riêng tư và chỉ chủ sở hữu mới thấy.

Kiểm tra tên miền → · SPF hỏng sau khi chuyển đổi nhà cung cấp → · Sửa DKIM → · Cài đặt DKIM trên Google Workspace → · Chỉ dữ liệu tổng hợp. Dữ liệu được lưu trữ và xử lý tại EU.