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

DKIM "No Key for Signature": Cách Sửa Selector và Xoay Vòng Khóa (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.

“No key for signature” có nghĩa là máy chủ nhận đã truy vấn bản ghi DNS mà chữ ký DKIM của bạn trỏ đến — selector._domainkey.yourdomain — và không tìm thấy khóa: chưa bao giờ được xuất bản, hoặc đã bị xóa trong lúc xoay vòng. Hãy xuất bản selector mà người ký của bạn thực sự dùng. Chỉ 10,092,481 tên miền — 3.87% — 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.

Cách sửa là một bản ghi DNS, tìm trong một header. Đọc các thẻ s= và d= từ header DKIM-Signature thực để biết selector nào thư của bạn được ký, xuất bản (hoặc sửa) bản ghi đó chính xác, và ưu tiên ủy quyền CNAME để nhà cung cấp xoay vòng khóa cho bạn. Sau đó xoay vòng theo hướng dẫn bên dưới — lỗi này thường có nghĩa là ai đó đã xóa selector cũ quá sớm.

”dkim no key for signature” có nghĩa là gì?

Mỗi chữ ký DKIM mang hai thẻ cho máy chủ nhận biết nơi lấy khóa công khai: d= (tên miền ký) và s= (selector). Máy chủ nhận truy vấn một tên DNS được xây dựng từ chúng — s._domainkey.d — để lấy khóa. “No key for signature” có nghĩa là truy vấn đó trả về rỗng: chữ ký tồn tại, nhưng khóa mà nó đặt tên không có.

Từ này xuất hiện trong header Authentication-Results và báo cáo DMARC tổng hợp — cách diễn đạt chính xác thay đổi theo máy chủ nhận, nhưng hai biến thể quan trọng:

Chuỗi kết quả (đoạn, quan sát rộng rãi)	Điều gì thực sự xảy ra	Tạm thời?
`dkim=temperror (no key for signature)`	Truy vấn DNS thất bại hoặc hết thời gian — máy chủ nhận không nhận được câu trả lời	Có — thử lại thường qua; chỉ điều tra nếu kéo dài
`dkim=permerror (no key for signature)`	Truy vấn DNS thành công và câu trả lời là “không có bản ghi đó” — selector thực sự vắng mặt	Không — bản ghi bị thiếu cho đến khi bạn xuất bản nó

Một temperror đơn lẻ là thời tiết DNS. Một permerror — hoặc temperror lặp lại qua nhiều ngày và máy chủ nhận — có nghĩa là bản ghi mà chữ ký trỏ đến không có trong vùng của bạn. Đó là hướng dẫn này.

Hậu quả: chữ ký không thể xác minh được tính như không có DKIM, vì vậy DMARC dự phòng vào SPF một mình — và SPF hỏng dưới chuyển tiếp. Nếu chữ ký có mặt nhưng không hợp lệ thay vì bị thiếu (hash nội dung, khóa bị làm hỏng), đó là lỗi khác — xem “DKIM signature not valid”.

Làm thế nào để tìm selector nào thư của tôi được ký với?

Đừng đoán từ tài liệu của nhà cung cấp — đọc từ thư thực:

Gửi một thư từ hệ thống bị ảnh hưởng đến hộp thư bạn kiểm soát (địa chỉ Gmail hoạt động tốt).
Mở nguồn thô (“Show original” trong Gmail, “View message source” trong Outlook).
Tìm header DKIM-Signature: và đọc hai thẻ: s= là selector, d= là tên miền ký. Ví dụ minh họa: DKIM-Signature: v=1; a=rsa-sha256; d=yourdomain.com; s=mail2026; ...
Bản ghi mà máy chủ nhận truy vấn là s._domainkey.d — ở đây, mail2026._domainkey.yourdomain.com. Tự kiểm tra: dig TXT mail2026._domainkey.yourdomain.com +short. Câu trả lời rỗng = lỗi là thực với mọi máy chủ nhận.
Lặp lại cho mỗi hệ thống gửi. Một thư có thể mang nhiều chữ ký DKIM — nhà cung cấp hộp thư, công cụ newsletter, helpdesk — mỗi cái có cặp s=/d= và bản ghi riêng. Sửa cái đang lỗi, và ghi chú d= của nó: chỉ chữ ký có d= khớp với tên miền From của bạn mới giúp ích DMARC.

Tại sao bản ghi selector bị thiếu?

Bốn nguyên nhân chiếm gần như tất cả lỗi này — kiểm tra theo thứ tự này:

Chưa bao giờ được xuất bản. Người ký được bật (hoặc mặc định bật) với một selector mà không ai thêm vào DNS. Phổ biến với các công cụ và cổng mới ký bất ngờ.
Bị xóa giữa chừng xoay vòng. Ai đó đã “dọn dẹp” selector cũ trong khi thư được ký với nó vẫn đang trong quá trình chuyển tiếp, xếp hàng để thử lại, hoặc chờ chuyển tiếp. Thư đó đã được ký với s=old; xóa old._domainkey sẽ hồi tố làm hỏng tất cả những thư đó.
Bảng điều khiển DNS làm hỏng CNAME target. Nhiều nhà cung cấp ủy quyền qua CNAME (s1._domainkey.yourdomain.com → s1.domainkey.u123.esp.com), và nhiều bảng điều khiển DNS lặng lẽ thêm vùng của bạn vào target — lưu s1.domainkey.u123.esp.com.yourdomain.com, không phân giải được gì. Xác minh target: dig CNAME s1._domainkey.yourdomain.com +short. Cùng bẫy đó cắn trong quá trình di chuyển công cụ — xem DKIM lỗi sau khi chuyển đổi công cụ email.
Nhà cung cấp xoay vòng, vùng của bạn thì không. Khóa nhà cung cấp được dán làm bản ghi TXT tĩnh (thay vì CNAME của họ) bị bỏ lại bởi việc xoay vòng theo lịch trình của họ — người ký chuyển sang selector bạn chưa bao giờ xuất bản. 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ách sửa “no key for signature”?

Chạy quét miễn phí tại defaults.exposed trước khi chạm vào DNS. Nó đọc bản ghi DKIM, SPF và DMARC 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 selector có phân giải không và CNAME target có bị làm hỏng không.
Xuất bản selector mà người ký thực sự dùng — giá trị s= từ header, không phải cái trong sổ tay cũ. Lấy bản ghi từ bảng điều khiển admin của nhà cung cấp (cài đặt DKIM Google Workspace · cài đặt DKIM Microsoft 365) và thêm vào chính xác tại s._domainkey.yourdomain.com.
Ưu tiên ủy quyền CNAME hơn dán TXT key. Nếu nhà cung cấp cung cấp CNAME DKIM, hãy dùng chúng: khóa sống trong vùng của họ, vì vậy họ xoay vòng nó mà không cần bạn chạm vào DNS nữa — nguyên nhân 4 trở nên không thể. Các nền tảng newsletter hầu như đều hoạt động theo cách này; xem email Mailchimp/Brevo/Klaviyo lỗi DMARC.
Xác minh từ bên ngoài bảng điều khiển. dig TXT s._domainkey.yourdomain.com +short (hoặc dig CNAME … cho selector được ủy quyền) từ máy bên ngoài mạng. Bảng điều khiển hiển thị bản ghi không chứng minh gì nếu vùng phục vụ thứ khác.
Quét lại và gửi lại thư kiểm tra. Authentication-Results bây giờ nên đọc dkim=pass. Sau đó xử lý mọi thứ khác mà quét gắn cờ trên trang sửa DKIM — chữ ký vượt qua không căn chỉnh với tên miền From vẫn thất bại DMARC.

Làm thế nào để xoay vòng khóa DKIM không gây ra lỗi này?

Xoay vòng là nơi các cài đặt đang hoạt động bị hỏng. Quy tắc ngăn chặn điều đó: selector chỉ bị xóa sau khi thư cuối cùng được ký với nó đã được xử lý — không bao giờ tại thời điểm chuyển đổi. Thư đã ký sống lâu hơn bạn nghĩ: hàng đợi thử lại chạy hàng ngày, và thư được chuyển tiếp được xác minh lại mỗi khi chúng di chuyển.

Bước	Hành động	Cổng trước bước tiếp theo
1. Thêm	Xuất bản selector mới (`s2._domainkey…`) cạnh cái cũ	`dig` xác nhận nó phân giải từ bên ngoài
2. Chuyển đổi	Chỉ người ký vào selector mới	Thư kiểm tra hiển thị `s=s2` và `dkim=pass`
3. Chờ	Giữ nguyên selector cũ trong khi lưu lượng đang bay, xếp hàng và được chuyển tiếp được xử lý	≥ 7 ngày; xem báo cáo DMARC tổng hợp cho đến khi selector cũ ngừng xuất hiện
4. Ngừng	Xóa khóa cũ — hoặc tốt hơn, xuất bản lại với thẻ `p=` rỗng: “đã ngừng”, không phải “chưa bao giờ tồn tại”	Không bao giờ bắt đầu điều này tại thời điểm chuyển đổi — xóa sớm là nguyên nhân #1 của “no key for signature”

Với ủy quyền CNAME, nhà cung cấp chạy chính xác hướng dẫn này trong vùng của riêng họ và bạn không bao giờ thấy nó — đây là lập luận mạnh nhất cho ủy quyền.

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

“No key for signature” là temperror hay permerror? Cả hai chuỗi đều tồn tại: temperror là tra cứu DNS thất bại hoặc hết thời gian — tạm thời, thường biến mất khi thử lại — trong khi permerror có nghĩa là DNS trả lời “không có bản ghi đó”. Một temperror lặp lại qua nhiều máy chủ nhận thường cũng là bản ghi thực sự bị thiếu. Kiểm tra với dig và tin vào câu trả lời, không phải nhãn.

Lỗi này có nghĩa là ai đó đang giả mạo tên miền của tôi không? Không — kẻ giả mạo sẽ không ký với selector của bạn. Nó có nghĩa là thư của chính bạn mang chữ ký mà máy chủ nhận không thể xác minh, vì vậy nó được tính như không có chữ ký và DMARC chỉ dựa vào SPF. Xác thực đầy đủ và căn chỉnh hiếm: chỉ 10,092,481 trong 261,086,232 tên miền (3.87%) hoàn thành bộ ba SPF+DKIM+DMARC trong khảo sát Defaults.Exposed (dữ liệu tính đến 2026-06-29).

Có thể xóa selector cũ ngay khi selector mới hoạt động không? Không ngay lập tức. Thư được ký với nó vẫn đang trong hàng đợi thử lại và đường dẫn chuyển tiếp; xóa khóa sẽ hồi tố làm hỏng chúng. Giữ bản ghi cũ ít nhất một tuần, xem báo cáo DMARC cho đến khi selector cũ ngừng xuất hiện, sau đó ngừng nó — lý tưởng nhất là với p= rỗng thay vì xóa.

Công cụ kiểm tra của nhà cung cấp nói DKIM đã được cấu hình, nhưng máy chủ nhận vẫn báo không có khóa. Tại sao? Hầu như luôn là bẫy CNAME-target: bảng điều khiển DNS đã thêm vùng của bạn vào target (…esp.com.yourdomain.com), nên bản ghi tồn tại nhưng trỏ đến không đâu. dig CNAME selector._domainkey.yourdomain.com +short hiển thị target được lưu nguyên văn — so sánh từng ký tự với những gì nhà cung cấp yêu cầu.

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

Nếu bạn đang sửa điều này cho khách hàng hoặc nhà tuyển dụng, hãy đóng vòng lặp với bằng chứng. Chạy lại quét miễn phí khi selector đã phân giải và chuyển tiếp báo cáo được chấm điểm cho chủ doanh nghiệp: có ngày tháng, ngôn ngữ đơn giản, DKIM giờ đang xác minh. Đâ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 — bằng chứng về biện pháp kiểm soát đang hoạt động, không chỉ là ticket đã đóng.

Kiểm tra DKIM miễn phí

Xem selector của bạn 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 → · “DKIM signature not valid” → · 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.