A provider can emit valid DKIM signatures without supporting your organization's signing domain. That limitation matters when the service's signature does not align with the domain customers see in From. Establish the exact limitation before changing DNS or replacing the service.
Confirm what the provider actually supports
Ask for current documentation covering the account tier, sending interface and domain type you use. A verified sender address, custom tracking domain or branded return path is not proof of custom DKIM support. Obtain a raw received message from the actual route and record every signature's d and s values and the trusted receiver's verification results.
RFC 6376 defines d as the signing domain and uses s with that domain to locate verification data. Publishing a key under your own domain cannot change d on a signature that the provider creates. A CNAME similarly needs a provider-supported signing configuration; a DNS alias alone does not instruct a service to sign for you.
Check whether another aligned path exists
With an applicable policy and no unresolved evaluation error, DMARC can pass through either a passing aligned SPF or DKIM result. Evaluate the service's actual MAIL FROM domain and SPF result separately. A supported custom return path may provide aligned SPF even when custom DKIM is unavailable. Verify the alignment mode and domain relationship; a provider-owned return path does not align simply because you pay for the account.
Illustrative case: mail uses From=notices@brand.example and passes DKIM with d=vendor.example. Its MAIL FROM domain is bounce.brand.example and SPF passes. Assuming the organizational-domain relationship qualifies, relaxed SPF alignment can satisfy DMARC. With strict SPF alignment, the subdomain is not an exact match. This is a synthetic decision example, not a claim about any vendor.
RFC 9989 sections 7.4 and 8 require domains publishing p=reject not to rely solely on SPF for a DMARC pass and to apply valid DKIM signatures. A direct-delivery SPF pass is therefore not a complete p=reject deployment design. Resolve the missing aligned-DKIM path before treating that service as ready for this policy.
Do not describe SPF as an identical replacement for aligned DKIM. Forwarding can change the connecting IP and disrupt SPF, while an intact aligned DKIM signature may survive. Evaluate the routes important to your users rather than relying on one direct-delivery test.
Compare supported alternatives
The practical choices are to retain the service with a documented aligned-SPF path where compatible with the domain’s policy and accepted limitations, move sending to a service that supports the required DKIM identity, or use a supported authorized relay that signs the final message. Each requires testing and an owner. A relay must preserve necessary application behavior and sign after content-changing processing; merely adding an unrelated signature does not solve alignment.
Changing the visible From domain is another product decision, not a hidden technical fix. It affects recognition and replies, and the replacement domain still needs valid authentication. Avoid weakening the whole organization's DMARC policy just to conceal one undocumented sending path.
Record the accepted limitation
Keep the provider's capability statement, received-message evidence, chosen alignment path, business owner and review trigger. Test transactional messages and forwarding scenarios relevant to the service. If a limitation remains, state the exposure and migration decision explicitly. Completion means a verified supported route or an owned exception, not a green DNS screenshot.
Use a filled decision record
Consider this explicitly fictional two-route matrix. Billing API A has From=brand.example, d=vendor.example, selector vendor1, MAIL FROM=bounce.brand.example, raw SPF pass and raw DKIM pass. Assume relaxed SPF alignment and the stated shared organizational domain: its successful path is aligned SPF only. Replacement relay B has From=brand.example, d=brand.example, selector relay2 and MAIL FROM=vendor.example, with both raw checks passing: its successful path is aligned DKIM only. Every capability and result here is assumed, not observed from a provider.
These field comparisons explain the assumed outcomes; no fixture execution or provider verification is claimed. Billing API A illustrates an SPF-only result, not an acceptable sole path for a p=reject deployment. Before deploying either design, obtain dated route-specific provider instructions, generated DNS values, raw received mail and a trusted receiver result. Compare intended and observed identities, test critical formats and relevant forwarding, and record the owner accepting any residual limitation. Those real-world acceptance fields remain pending.
Choose the supported next step
- Unknown capability: obtain current instructions for the exact account tier and sending route; do not guess DNS values.
- Only aligned SPF available: record direct-delivery limits and the current policy; do not use it as the sole DMARC path for p=reject.
- Supported signing relay available: verify application behavior, final content, aligned d= and key custody before migration.
- No suitable path: change provider or make an explicit product decision about From identity.
- Closure: save received-message evidence, remaining limitations, responsible owner and next review trigger.