Select the product and delivery service first
“Sent by Sitecore” is not a sufficient route description. The same organization may use Email Experience Manager with EXM Delivery Cloud, EXM with custom SMTP, or the separate Sitecore Send product. This draft covers those documented branches, using EXM 10.4 documentation for the versioned examples. Confirm the actual product and version before adopting any procedure. The broad catalogue scope remains on hold until that selection is accepted.
Record the campaign owner, sending domain, product, account or environment and delivery route. If a migration is underway, record the old and new routes separately. A validated domain in one product should not be assumed to be configured in another. The rollout should name exactly which workflows its evidence will cover.
Follow the EXM Delivery Cloud branch when it applies
The EXM 10.4 domain guide describes adding a controlled sender domain under Administrator, Email Delivery Service, Domains. Show details exposes the required DKIM information. It says Delivery Cloud uses a common envelope domain with provider-managed SPF, so it does not require a separate SPF setup for each visible sending domain.
Use only a domain the organization owns and is authorized to use. Obtain the exact issued public record and compare it with the authoritative zone. Do not substitute a selector from a different Sitecore instance. If verification shows a warning, preserve that status and investigate the published owner, type and value before proceeding.
The EXM guide also recommends gradual audience growth with opted-in, maintained lists. Plan reputation warm-up separately from DNS acceptance; no universal volume schedule is established by this guide.
Plan the change with the campaign owner. A domain showing as configured in the application is an intermediate observation; the final campaign must still carry the intended identity and produce an aligned result. Do not interpret provider-managed SPF as proof that the visible From domain aligns through SPF. The actual envelope and signature determine that answer.
Assign downstream ownership for custom SMTP
The EXM delivery comparison assigns authentication management for custom SMTP to the customer’s selected sending system. The Delivery Cloud domain workflow does not configure that relay’s keys, DNS or reputation controls. This is a responsibility boundary, not a claim that SMTP services cannot support DKIM.
Identify the relay operator and its current first-party instructions. Record which system applies the final signature, which envelope domain it uses and whether another gateway can modify the message afterward. If the organization operates the relay, assign an administrator who can verify those controls. If another provider operates it, obtain the correct account-specific records there.
Keep relay authentication, transport encryption and DMARC separate. A secure connection to a relay does not establish a customer-domain signature at the final receiver. Likewise, a successful SMTP submission only shows acceptance at that hop. Retest the complete path whenever a relay, gateway or downstream content modification changes.
Use the Sitecore Send sender workflow separately
Sitecore Send’s DNS guide directs users to More, Settings, Senders, with record information on the SPF and DKIM tabs and a Verify DNS records action. It describes combined SPF, DKIM and DMARC verification, including parent-domain checks and a 48-hour verified state. These are application verification behaviors.
Copy the values for the actual sender and domain, not values from the EXM domain screen. Review the existing DMARC policy before changing it to satisfy an application prompt. A domain may already have an approved reporting destination, enforcement setting and alignment mode. Preserve those decisions unless a separate authorized review changes them.
Treat the provider’s parent-domain verification rule carefully. It does not mean SMTP SPF automatically inherits an arbitrary parent record. A cached verified status also does not prove that a newly received message authenticates after an external DNS edit. Record both the application verification time and the later message observation.
Review the DNS changes as one controlled set
Prepare a change sheet containing the domain, owner, record type, public value, source account and responsible operator. Export the existing records and resolve selector conflicts before publication. If a DNS interface appends the domain automatically, confirm the resulting fully qualified owner. Keep private keys and relay credentials out of the sheet.
For any customer-managed SPF change, RFC 7208 supplies the evaluation rules and lookup limit. Preserve other authorized senders and review the full policy. Do not add a second policy or an unrelated provider include just because an older checklist expects a Sitecore SPF step.
For DKIM, retain every observed signing domain and selector. RFC 6376 explains those fields. Public DNS should correspond to the signature actually used, not merely to the selector an administrator expected. Multiple signatures require separate results rather than an undifferentiated “DKIM enabled” entry.
Test a real campaign route with harmless content
Use a controlled campaign or supported test workflow that exercises the actual delivery route. Record whether it matches production sending, because a preview or application notification may use another path. Avoid broad production sends while the identity is unverified. Keep the message identifier and send time so provider events and receiver evidence can be correlated.
Capture visible From, Reply-To, envelope domain, all DKIM identities and trusted receiver results. RFC 9989 defines the alignment requirement. Identify which passing mechanism aligns and why. An unrelated provider envelope can pass SPF while the customer identity depends on aligned DKIM.
Check a failure in the context of its branch. In Delivery Cloud, compare the configured domain and issued signing details. With custom SMTP, involve the downstream relay owner. In Sitecore Send, compare sender values and verification state with current DNS. Do not move between these procedures until the route itself has been established.
Use the product and route decision worksheet
The Sitecore product and delivery worksheet (create a separate review record with the fields described here) starts with a mandatory branch selection. It then records the domain source, verification state, downstream ownership and final campaign identities. Mark unused branches out of scope instead of treating every possible Sitecore feature as part of one deployment.
The acceptance record should connect four observations: the selected product, its active delivery route, the supporting DNS and the final receiver’s result. If one is missing, state the missing evidence and the owner responsible for it. A product badge cannot fill the received-message field.
Fictional diagnostic case involving a relay migration
Fictional written case only: SC-02 assumes the intended campaign From is news@museum.example. After a change from EXM Delivery Cloud to custom SMTP, the final message has passing d=relay.example, an unrelated domain; the envelope/SPF result and any other signatures are unknown. That one signature is not aligned, but the supplied facts do not establish a full DMARC verdict. The relay owner must document the supported customer-domain signing configuration and collect evidence from the actual campaign. Old Delivery Cloud verification cannot close the new route. No tenant, relay, DNS or message was tested.
Recover only the changed route
Keep the old approved route available during a planned migration where feasible, with explicit controls against duplicate sends. Coordinate rollback with campaign scheduling and queued messages. Do not delete old public keys until the owner confirms that remaining mail no longer depends on them. Preserve suppression and bounce-handling requirements when assessing a replacement delivery path.
Retest after product migration, relay changes, sender-domain additions and external DNS edits. This remains an unpublished documentary draft. Exact original product scope, account-issued records, live DNS and received-message evidence, visual review and human SME approval remain pending.
Separate a passing message from enforcement readiness
RFC 9989 Section 7.4 requires valid DKIM for a domain publishing p=reject and cautions about indirect-mail interoperability. A single aligned SPF result does not by itself justify a reject-policy rollout. Review all legitimate routes and policy ownership separately from this provider setup.