How to Verify and Repair DKIM for Active Sending Tools

DKIM signs messages so receivers can verify that a domain took responsibility for the message. For deliverability work, the important question is not just whether DKIM exists, but whether each active sender signs with the right domain.

Before you change anything

• Do not assume one DKIM selector covers every tool.
• Do not delete old selectors until you know whether any sender still uses them.
• Confirm whether the provider uses TXT or CNAME selector records.

Step-by-step repair process

1. Collect a header from the sender. Find the DKIM-Signature line and note the d= signing domain and s= selector.
2. Find the provider’s DKIM setup screen. Google Workspace, Microsoft 365, CRMs, ESPs, and transactional tools each issue their own selector records.
3. Publish the selector record exactly. Add the TXT or CNAME record at the DNS host for the correct domain or subdomain.
4. Enable signing in the sender platform. Some platforms generate keys first, then require a separate “start authentication” or “enable DKIM” step.
5. Send a fresh test message. Check a new header after DNS propagation; old messages do not prove the new setup works.
6. Confirm DKIM alignment. The DKIM d= domain should align with the visible From domain for DMARC to pass through DKIM.

Common mistakes to avoid

• Publishing the DKIM record but forgetting to enable signing inside the platform.
• Testing only public DNS and never checking the actual DKIM-Signature header.
• Using a vendor default signing domain when the brand domain should be aligned.

Related repair guides

Reference points

These are technical reference points, not a substitute for checking your real message headers and sender inventory.

• DKIM standard
• Microsoft 365 DKIM guidance
• Google Workspace DKIM troubleshooting