Is this the same as the signature under my name?
No. A typed name, logo, phone number or disclaimer is copyable content. DKIM is a cryptographic signature in technical headers, not a picture or clickable badge.
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. Source
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.
Do not email a private signing key. Ask for the provider's setup state, public record and agreed test-message result. Use the provider's supported configuration process when it manages keys.
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. Source
For each scoped sender, record the service, domain, key identifier, test date, result and DMARC alignment. Identify untested senders.
Fictional example: key found, sender untested
Fictional note: “Invoice tool: public key found; message untested; signing and alignment unverified.” Next, test the sender—do not relabel the lookup as a pass. This is not a customer result.
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 your next administrator could use, including limits such as a tool that cannot sign with 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?