What DKIM proves
DKIM adds a signature that helps show a message was not altered after it was sent by an authorized service.
Why keys matter
Each sending service often has its own key. Knowing which keys belong to active services makes cleanup and troubleshooting easier.
Healthy routine
Document DKIM selectors, rotate keys when providers recommend it, and remove stale records after tools are retired.
Practical context
How to use this guidance
DKIM helps receivers verify that a message was signed by a service connected to the domain. Operationally, the work is key management, sender ownership, and cleanup.
A practical example
Imagine a team reviewing dkim without the jargon after a new software vendor starts sending customer-facing mail. The immediate question is not whether the setup uses the right acronym; it is whether the business can explain the sender, prove that it is authorized, and spot problems before customers or employees lose trust.
That review usually starts with what dkim proves. From there, the team should compare the intended workflow with real message samples, provider settings, and any reporting data that shows how receivers are treating the mail. This turns the topic from an abstract security idea into a manageable operating task.
Action checklist
- Track selectors for every active sending platform.
- Confirm each platform signs mail using the expected domain.
- Remove keys for retired services after mail migration is complete.
- Plan key rotation where the vendor supports it.
Common traps
- Keeping old selectors because nobody knows whether they are active.
- Assuming a vendor signs correctly without checking sample messages.
- Using one shared sender identity across unrelated tools.
Questions to ask internally
- Which selector belongs to which vendor?
- Can we prove current production mail is being signed?
- How are key changes tested before launch?
Evidence to gather
Good decisions are easier when the team works from evidence instead of memory. For this topic, collect enough detail to connect technical records with the business process they support.
- A recent sample message from each important sending path.
- The DNS records or provider settings connected to the sender.
- The business owner who can confirm whether the sender is still needed.
- Any recent support tickets, delivery problems, or suspicious-message reports.
- The decision log for changes made after the review.
Review rhythm
Review this area whenever a new email platform is launched, a domain or subdomain is added, a vendor is retired, or a suspicious message is reported. For stable environments, a quarterly review is usually enough to catch drift before it becomes an urgent delivery or impersonation problem.
Keep the review lightweight. The useful output is a short list of confirmed senders, open questions, owner names, and next actions. If that list is understandable to IT, finance, marketing, and leadership, the email security program is much easier to maintain.
What good looks like
Good DKIM hygiene means signed messages are predictable, stale keys are removed, and each active sender can be explained by someone in the business.
Where Lappu AI fits
Teams that want help turning these ideas into a working DMARC, DKIM, and SPF plan can review the email security work at Lappu AI.