For Adobe Commerce Cloud Pro Production or Staging using Adobe’s managed SendGrid service, request current domain-authentication records through Adobe Commerce Support. Publish the approved account-specific records, have Support confirm authentication for the correct environment, and test an actual store message for aligned branded DKIM and DMARC. Do not paste a generic Magento SPF record or follow a retail SendGrid dashboard tutorial for an account you do not control.
This guide covers the automated-security CNAME route for an existing Adobe-managed service. It does not configure Magento Open Source, self-hosted Commerce, a separately purchased SendGrid account, another SMTP provider, or marketing campaigns. Adobe’s documented managed domain-authentication feature is limited to Pro Production and Staging, not Starter or Pro integration environments. Adobe SendGrid service scope.
This is documentary guidance, not a record of customer-account access, DNS changes or delivered-message testing.
Confirm the sending environment before requesting records
Identify the Cloud project, Pro environment, store view, actual transactional workflow and intended From address. Production and Staging are separate verification targets: success in one does not certify the other. Check whether a custom SMTP extension or separately managed service owns the route before assuming Adobe’s managed integration is in use.
Ask the responsible Commerce administrator to confirm the current transport. Do not disable an extension, switch SMTP providers, enable a dormant environment or replay customer notifications merely to identify it. Such changes can release queued mail or change delivery for real orders.
Adobe retains access to the central SendGrid dashboard. Its customers do not get that dashboard through the managed integration. Account-side verification and activity-log investigation therefore belong with Adobe Support, not an invented customer console action. If you use your own provider instead, obtain that provider’s current authentication instructions and treat the transport migration as a separate approved project.
Prepare a precise support request
Request DKIM and SPF domain authentication for the exact owned sender domain and each applicable Pro environment. Include the project/environment identifiers needed by your authorized Support channel and clarify that this is Adobe-managed SendGrid, with automated security requested or already in use.
Ask for:
- The current complete DNS packet, including each record’s type, full owner and exact target or value.
- The purpose of every row: DKIM selector, envelope/bounce authentication, optional tracking, or another function.
- Confirmation of the domain’s association with the intended current SendGrid subaccount and environment.
- The verification state required after publication and who will confirm it.
Do not reuse an old ticket’s targets. Adobe’s current troubleshooting article warns that subaccount assignments can change. Request current values rather than assuming a historical working configuration is still valid. If a previous case is already checking the same current packet, continue that case instead of creating competing changes. Adobe’s current domain and environment troubleshooting.
A native authentication request needs public DNS information, not your mailbox password or DKIM private key. This guide does not ask you to send a private API key in an ordinary ticket, create a retail SendGrid account or purchase an upgrade.
Separate DKIM records from SPF, bounce and tracking records
For the automated-security model, the familiar pattern is two DKIM CNAMEs and a separate envelope-related CNAME. The actual names and targets must come from the current approved Support packet. Do not derive them from a tenant identifier, assume the selectors are unused, or copy the documentation’s sample account number.
Twilio’s record table identifies the two _domainkey aliases as DKIM and the em... alias as SPF-related. Its return-path explanation connects the envelope subdomain with bounce handling. Link branding is a separate feature. Some explanatory prose in the Adobe and Twilio pages labels these purposes inconsistently, so neither an em prefix nor a screenshot alone proves a record is a tracking instruction. Resolve unclear purposes with Support before applying the packet. Twilio’s record table and return-path explanation.
Before publication, compare every owner and destination with the domain owner’s approved routing plan. Approve the intended bounce/mail-service destination explicitly. If a packet contains web or tracking routing, obtain separate approval for those changes. Stop on an unexpected MX record, unapproved destination or collision with a working service. Do not omit required rows to force a partial setup, and do not activate unapproved routing just because it appears in a support response.
A packet using manual security, MX records and standalone TXT keys is outside this walkthrough. Ask Support to identify the supported configuration for that account rather than mixing it with the automated-security example.
Publish at the actual DNS authority
Export the existing zone and record who owns the change and recovery decision. Preserve staff-mail authorizations, inbound MX, website routes, NS delegations, other DKIM selectors and effective DMARC protection. The domain registrar and authoritative DNS operator may be different companies.
Copy the issued full owner and target, then translate only the owner format required by your DNS editor. For an illustrative full owner SELECTOR._domainkey.shop.example.com:
- In the parent
example.comzone with relative-name input, enterSELECTOR._domainkey.shop. - In a delegated
shop.example.comzone, enterSELECTOR._domainkey. - In a delegated
_domainkey.shop.example.comzone, enterSELECTOR. - In a full-name input field, use the complete issued owner.
These are naming examples, not Adobe-issued selectors. Apply the same authority check to an envelope owner such as BOUNCE.shop.example.com. Keep the sending subdomain exactly once; a duplicated suffix creates a different DNS name. DNS master-file name rules.
A CNAME destination is a hostname, not an HTTPS URL. An owner cannot hold a CNAME alongside ordinary TXT, A, AAAA or MX data. Do not overwrite an occupied name or delete an NS delegation. Ask Support and the DNS owner for a supported alternative when necessary. DNS aliases.
Cloudflare and literal CNAME answers
Where the issued authentication alias needs to remain a CNAME, keep it DNS only, not HTTP-proxied. Turn off its per-record Flatten option when available and ensure the applicable whole-zone setting does not suppress the CNAME answer. A DNS-only record can still be flattened.
Cloudflare flattens apex CNAMEs by default and can flatten same-zone targets regardless of the toggle. A per-record choice cannot override flattening for all CNAMEs. Do not change a shared zone setting blindly: coordinate with other service owners. If mandatory behavior prevents the required response, stop and obtain a supported configuration rather than deleting delegations or inventing a switch. Cloudflare flattening controls.
Is an additional root SPF include needed?
Not automatically. SPF evaluates the SMTP envelope MAIL FROM domain, which may differ from the visible From domain. The managed CNAME arrangement can delegate the envelope policy to SendGrid. Adding a generic include at your root does not change the envelope identity or repair DKIM.
If Support explicitly requires a separate SPF TXT change, first establish the exact evaluated owner and approved mechanism. Keep one v=spf1 policy there. Merge the authorized mechanism before the existing terminal all, retaining other legitimate senders and the intended qualifier. Never append a second complete SPF policy or place TXT alongside a CNAME.
Preserve redirect= semantics: an all mechanism makes a redirect ineffective. SPF does not inherit from a parent domain into child domains. Check the complete evaluated chain against the ten-term limit for include, a, mx, ptr, exists and redirect, including nested terms; additional MX and void-lookup limits also apply. ip4, ip6 and all do not consume that term budget. Do not flatten a managed include into a temporary list of IP addresses. SPF specification.
Verify publication, account association and the store sender
Query the exact issued owners at their authoritative DNS service and through a public resolver. These read-only examples use placeholders; replace them with the current packet’s full names:
dig CNAME DKIM_OWNER_FQDN +short
dig CNAME SECOND_DKIM_OWNER_FQDN +short
dig CNAME ENVELOPE_OWNER_FQDN +short
Each response must match the expected current target, not merely end in a familiar provider domain. An empty answer needs investigation: wrong authority, duplicated suffix, incorrect type, missing publication or CNAME flattening can all produce misleading results. Waiting cannot fix an entry in the wrong zone.
Return the public verification results through the authorized Support case and request confirmation that the correct domain is authenticated for that environment. This is an account-side confirmation, not an assumed new Adobe signing toggle. Publication alone does not prove the application uses the authenticated domain.
Inspect Stores > Configuration > General > Store Email Addresses and the relevant store scope. Ensure the actual sender uses the approved owned domain rather than a default placeholder or public mailbox domain. Do not change every sender indiscriminately: check the identity used by each intended transactional workflow. An address or display-name change does not itself create DKIM signing. Adobe’s store sender requirement.
Preserve DMARC while proving alignment
Keep the existing direct and applicable inherited DMARC policy and approved report recipients. An empty query at one _dmarc name does not establish that no inherited policy applies. Do not weaken quarantine or reject, add a child p=none override, or copy a deprecated pct rollout example to fix this integration.
Only if no applicable policy exists and the domain owner approves a monitored introduction may you publish an initial TXT policy such as v=DMARC1; p=none. For From example.com, the owner is _dmarc.example.com; for From shop.example.com, it is _dmarc.shop.example.com. The relative input is _dmarc.shop in the parent zone or _dmarc in a separately delegated shop.example.com zone. Publish at the real authority, preserving NS delegation. That minimal policy does not send reports. Current DMARC policy rules.
Any report destination requires deliberate owner approval. When its Organizational Domain differs from that of the domain where the DMARC policy was found, the reporting receiver must check DNS authorization. A destination within the same Organizational Domain as that policy domain is excepted. This DNS rule does not replace permission to share report data. RFC 9990 section 4.
DMARC passes with either aligned SPF or aligned DKIM. Relaxed alignment compares Organizational Domains; strict alignment requires an exact domain match under aspf or adkim. A child envelope domain can align relaxed but fail strict alignment. For this DKIM setup, require the intended managed-service signature itself to pass and align, even if SPF alone could satisfy DMARC.
Test the actual transactional route
Use an authorized, controlled external recipient and a safe test workflow. Do not create paid orders, trigger real refunds, expose password-reset links or replay customer messages as a casual test. Production and Staging need separate evidence; a successful retail SendGrid test does not certify Adobe’s managed subaccount.
Obtain the recipient’s original message and results produced inside that receiver’s actual processing boundary. Consult its documented handling of externally supplied Authentication-Results, or ask its administrator for a trace. A familiar authserv-id, header position or copied header is not proof of trust. Ignore injected external result fields. Authentication-Results trust boundaries.
Record the actual From, envelope MAIL FROM, intended DKIM d= domain and s= selector, plus trusted SPF, DKIM and DMARC results. Acceptance requires the intended brand From, passing aligned managed-service DKIM, and dmarc=pass, together with the confirmed account state and exact DNS. A rewritten provider From or unrelated passing signature does not prove your brand setup. For interpreting multiple signatures, see raw DKIM results versus aligned DKIM results.
Investigate SPF failures and errors separately even when DKIM passes. A temporary lookup failure is not the same as a permanent syntax, duplicate-policy or lookup-budget error. Keep controlled message evidence private; do not upload customer correspondence to public diagnostic sites.
Troubleshooting without unsafe shortcuts
Staging fails while Production works: ask Support to check Staging’s own domain/subaccount association. Do not copy Production’s targets blindly.
DNS is correct but DKIM is missing: compare actual From and transport with the authenticated domain, then ask Support to inspect the managed account. Do not rotate working selectors or change unrelated staff-mail keys.
DKIM fails despite a matching DNS key: investigate signed-header or body modification downstream and ensure the failed signature is the intended one. Preserve mandatory security/compliance controls; any redesign needs its owner’s approval.
An old working configuration stops working: obtain current Support-issued records and compare with the saved approved state. Do not restore stale subaccount values solely because they once passed.
A message is rejected for another reason: inspect the actual bounce or Support-provided activity evidence. Mailbox capacity, throttling and recipient policy are not repaired by weakening DMARC. A dmarc=fail header alone does not prove that it caused the rejection.
Some recipients never receive mail: have the responsible team investigate delivery and suppression evidence. Do not purge suppression lists or resubscribe recipients simply to produce a successful test.
If a change causes disruption, pause the affected workflow where operationally safe and coordinate recovery to the last approved configuration with the responsible administrator and Support. Retain old signing records until queued mail and rotation dependencies are accounted for.