DKIM email authentication adds a digital signature that receiving systems can check against a public key in DNS. The signature covers selected parts of the message and identifies the signing domain. For your Shopify marketing email, verify that the expected domain is signing successfully and that the broader sender identity is aligned. A green setup screen is useful; a delivered test provides the next check.
Use your account's records
Follow the DKIM values supplied for your Sendvio configuration. A selector identifies which public key to look up, and the required DNS entry must match that setup. A record copied from another account cannot authenticate your own sending correctly.
Give DNS changes to the person responsible for the domain and preserve the old configuration before editing. Do not paste private keys, access tokens, or unrelated credentials into public DNS or a support screenshot. The required published record is different from a private signing secret.
Connect the selector, domain, and signature
The signing domain identifies the domain taking responsibility for the signature. The selector identifies which key record to retrieve for that domain. Together they let a receiver locate the public verification information. The selector is not the sender's password, and the published public key is not the private key used to sign messages.
Your setup may use a TXT value or a provider-specified DNS arrangement such as a CNAME. Follow the exact record type, hostname, and target supplied for the account. Do not convert one type into another because a different tutorial uses it. Also check whether the DNS interface automatically appends your domain to the hostname you enter.
A published key is only half of the setup. The sending system must use the corresponding signing configuration. This is why a record-presence check and a delivered-message test answer different questions: one confirms the lookup material exists; the other confirms that a real message was signed and verified as expected.
Inspect an actual test message
A configuration screen may confirm that a DNS record exists, but a delivered test shows what happened to the message. Inspect the authentication results and signing domain. If verification fails, check the record value, hostname, selector, and whether DNS changes have become visible.
Some forwarding or message-modification situations can affect authentication. Avoid diagnosing every isolated result as a broken campaign without understanding the path the message took. Test a direct delivery through the configuration customers will actually receive.
Read a failure as a sequence of questions
First check whether the direct test message contains the expected DKIM signature. If it does, note its signing domain and selector, then verify that the corresponding DNS record resolves correctly. If the record is recent, account for caching before repeatedly changing it.
Next, check whether the protected content changed after signing. Some forwarding paths or intermediaries can modify a message in ways that affect verification. Compare a direct delivery with the problematic path before concluding that the original campaign signing setup is broken. Keep the test message and sanitized headers available for the technical team.
If several signatures are present, a failed unrelated signature does not by itself tell you whether the relevant aligned signature passed. Ask for the complete authentication result rather than reacting to the first occurrence of the word “fail.”
Keep the broader identity consistent
DKIM is one part of the identity system. DMARC also considers alignment with the visible From domain, so a passing signature alone does not answer every question. Review the complete result with the domain administrator when something looks inconsistent.
Recheck after a domain change, service migration, or key rotation. Keep ownership and renewal responsibilities documented so authentication does not become an abandoned setup task. A valid signature helps verify origin and integrity; it does not make misleading content or an unpermissioned audience acceptable.
Coordinate key rotation with the service and DNS owner. Publish and verify the replacement as instructed, then confirm newly sent messages use the intended configuration. Retire old material according to the supported process, allowing for relevant delivery and caching considerations. Do not independently delete a selector merely because it looks old.
Finally, distinguish signature validity from the truth of the message. DKIM can help verify protected content and a signing identity; it cannot establish that a discount is accurate, a review is genuine, or a subscriber wants the email. Keep the technical evidence in the setup record and the editorial checks in the campaign review. Both are necessary, and neither replaces the other.