A provider can truthfully report that its mail passes DKIM while signing with a domain unrelated to your visible From address. If the goal is to authenticate your organization's author domain for DMARC, ask for a supported aligned DKIM identity and define how it will be verified. A generic request to enable DKIM is too ambiguous.
Begin with a controlled message from the actual service and route. Preserve its raw received form and the trusted receiver result. This gives the provider a concrete identity mismatch to investigate without assuming the product offers custom-domain signing on every plan or transport.
State the identities separately
Record the visible From domain, envelope sender identity, SPF result, each DKIM d domain, selector and verification result. Put alignment in a separate field. RFC 9989 §4.4 treats authentication success and identifier alignment as different requirements; an unrelated passing DKIM domain does not become aligned because it belongs to the sending provider.
Strict DKIM alignment requires an exact domain match under RFC 9989 §3.2.10. Relaxed alignment compares organizational domains under RFC 9989 §4.10.2. Ask which d domain the provider can actually emit, then compare it with your intended From domain and policy. Do not request a particular DNS value before the provider confirms the supported identity and account configuration.
Show the misleading pass clearly
Illustrative identity worksheet:
- Provider identity only: From=brand.example; d=provider.example; assumed DKIM pass; not aligned, assuming these are unrelated Organizational Domains.
- Customer identity: From=brand.example; d=brand.example; assumed DKIM pass; exact domain match.
Assume the results shown for the purpose of this example. They are not received-message test evidence. In the first case, DMARC may still pass through aligned SPF, so do not claim an overall DMARC failure without checking the envelope identity and SPF result. The worksheet isolates the DKIM property being requested.
Send a precise technical request
Ask the provider whether the named product, account plan and sending route support a customer-controlled signing domain aligned with the intended From address. Include API, SMTP, campaign or transactional route details as applicable. Ask whether the behavior differs for aliases, subdomains and delegated users.
Request the exact selector names, DNS record types and values, activation step and verification procedure. Ask who controls the private keys, how rotation is performed and what happens to verification records after offboarding. If a CNAME is required, confirm its target and scope rather than replacing it with a guessed TXT record.
Share a redacted identity worksheet or controlled test message instead of a customer message containing unnecessary personal content. A provider support request does not need a private signing key or mailbox password. Keep sensitive credentials out of ordinary tickets.
Agree acceptance criteria before changing DNS
A useful acceptance test requires a new message from the actual production-equivalent route, a passing intended DKIM signature at a trusted receiver and alignment under the relevant policy. Test important message formats and routes separately. Merely publishing DNS records or seeing a verified badge is incomplete evidence.
If the provider adds its own signature as well, inspect both. Multiple signatures are allowed under RFC 6376 §4.2, and a passing aligned signature supplies the DKIM path under RFC 9989 §4.4.1. Record the selector and d domain actually observed rather than relying on the first signature a header tool displays.
Handle unsupported capability honestly
If custom aligned DKIM is unavailable, ask for the supported alternatives and their constraints. A passing aligned SPF path may satisfy DMARC for an applicable direct route, but it does not create aligned DKIM or guarantee resilience through forwarding; RFC 7208 §10.3 discusses SPF mediator limitations. A different supported sending identity or service may be necessary for the organization's requirements.
Close the request with the agreed identity, route, DNS ownership, key custodian and received-message evidence. If a capability remains unsupported, record it explicitly. The result should be a verifiable sending design rather than a promise that any DKIM pass proves your brand identity.
Record the next decision
Prepare these fields before contacting support: product and route; intended From; observed d/s and trusted result; required alignment mode; capability question; requested generated DNS instructions; key custodian; rotation and exit questions; and acceptance criteria. Redact unnecessary personal data. This is a technical-request checklist, not a sent ticket, an approved DNS change or proof of configured service.