Is this the same as the signature under my name?
No. Your typed name, logo, phone number, and disclaimer are visible content that someone can copy. DKIM is part of the message's technical headers. It works through a cryptographic signature, not a picture of your signature or a badge a customer clicks.
RFC 6376 describes a signing domain taking responsibility for a message. The signed domain can differ from the address a person sees in the From field. That distinction matters: a message can have a valid signature without that signature authenticating the business identity you expected. DMARC adds the alignment check.
Why does DKIM involve a public key?
The sending system keeps the private key used to sign messages. A public key is available through DNS so receiving systems can verify them. A selector identifies the appropriate key. Different sending services can use different selectors for the same business domain.
You should not need to email a private signing key to prove that DKIM works. Ask for the provider's setup state, the public record, and the authentication result from an agreed test message. For services that manage keys themselves, use their supported configuration process rather than inventing a separate key-management arrangement.
Why is finding a DNS record not enough?
A record can exist while the service is not using it to sign outgoing messages. Google separates publishing a key from turning on and verifying DKIM. Microsoft likewise distinguishes publishing its required DNS records from enabling signing for a custom domain. The evidence needs to cover the sending behavior, not just the DNS entry.
We recommend a small verification note for every scoped sender: the service name, sending domain, selected key identifier, test date, and observed result. The note should say whether the signature aligns with the visible domain for DMARC. It should also identify any sender that could not be tested.
Can a legitimate message fail the check?
Yes. Changes to signed message content can invalidate a signature. Forwarding that leaves the signed parts intact may preserve it; systems that alter those parts can create a different result. Treat the failure as something to investigate with the actual message path, not proof that the sender is malicious.
Before a website, signature service, or mail gateway changes, ask whether it modifies messages after they are signed. Keep one ordinary test case for that route. This turns a vague complaint that messages stopped arriving into a specific question an administrator can examine.
What should an owner ask for?
Ask for an explanation you could hand to your next administrator. You are buying clarity about the business's sending setup, not a long string of DNS characters. A useful answer includes the remaining limits, especially when a tool cannot sign using your domain.
- Which services sign using our domain?
- Was signing verified on a real test message from each service?
- Who manages key changes and provider notices?
- Which message routes still need investigation?