Choose the feature and transport first
Zuora's email-deliverability guide, updated June 29, 2026, separates Email notification from Workflow. For Email notification it describes Advanced SMTP, an external SMTP server and the Zuora default server. Workflow can use Amazon SES or an external SMTP server. These alternatives must not be combined into one universal setup procedure.
Begin with the organization, environment, message category and transport selected for that category. A billing notice and a Workflow-generated message may have different configuration owners even when their visible From addresses look alike. Identify whether the requested change concerns a new route, an existing custom domain or a migration between transports.
The public guidance establishes documented options, not the state of a particular tenant. Account eligibility, environment applicability and operational acceptance remain open. No tenant login, credential creation, support request, DNS edit or email transmission has been performed for this manuscript. Zuora deliverability configuration
Treat Advanced SMTP as its own domain-identity workflow
The guide describes Advanced SMTP as an Amazon SES-backed service using DKIM. Its separate domain-identity instructions, updated November 2, 2026, direct the administrator to select View in the DKIM Status column of the Identities table and publish the three CNAME records shown. These account-issued records are the configuration input; do not invent a selector or borrow another environment's values.
The same page distinguishes the TXT record visible through the Verification Status column: it says that TXT record is not required to verify the domain identity in this workflow. This is a useful example of why a visible DNS value should not automatically become a change request. Record which column and dialog supplied the proposed records.
For successful verification, the documented Verification Status and DKIM Status values move from Pending to Success. Keep both observations and their timestamps. A public-key dependency existing in DNS and a product reporting successful verification are related but different checkpoints. Verify a domain identity
Review name handling and unsuccessful verification safely
Zuora's domain-identity instructions explain that a name ending at _domainkey may need the domain appended, unless the DNS provider already adds it. The acceptance target is the complete intended name, not a universal instruction to always add or always remove the suffix. Compare the issued name with the actual editor's conventions before publication.
The guide describes verification taking up to 72 hours and provides retry or identity-recreation instructions for unresolved states. Treat these as product guidance, not a guarantee that an incorrect record will become valid by waiting. Recreating an identity in an active environment is a consequential configuration change that requires a dependency review and authorization; it should not be an automatic troubleshooting reflex.
First compare the three intended aliases, their targets, the authoritative zone and the current status. Preserve evidence of the discrepancy before changing anything. Do not remove a working identity simply because a message from another route failed. Verification outcomes and troubleshooting
Separate default-server, Workflow and external-server requirements
For the Zuora default email server, the deliverability guide provides an SPF example using mx and a:zgateway.zuora.com. It is an example for that transport, not a safe replacement for an organization's complete SPF policy. Preserve other authorized senders and identify the actual evaluated identity before proposing a policy change.
For Workflow's SES route, the guide describes workflow@zuora.com as its prevalidated default From address. Using an organization's own domain instead involves the documented SPF authorization and a request to Zuora Global Support for three DKIM CNAME records. Support-assisted values are not interchangeable with a guessed Advanced SMTP identity.
External SMTP has a different owner: the organization or chosen provider supplies the relevant server and authentication configuration. The guide also describes external SMTP options for Workflow, but this manuscript does not create credentials, register applications or configure OAuth. Those actions require their own authorization and current provider-specific instructions. Transport-specific sections
Interpret SPF and DMARC at message level
The Zuora guide names include:amazonses.com for its described SES-based configurations. That instruction still needs to be reconciled with the actual route and complete policy. An include is not an assurance that every message generated by Zuora uses the domain where it was published. SPF evaluates its specified SMTP identities, and multiple selected SPF records cause an error rather than combining automatically.
Review DNS-dependent evaluation terms and existing authorizations before accepting a merged policy. Then evaluate an authorized representative received message: record the visible author domain, signing domain and selector, relevant envelope identity, and trusted receiver results. DMARC needs a passing aligned authentication identity; a product's broad compliance description is not proof that a particular message aligns.
Authentication does not guarantee inbox placement, customer receipt of a billing notice, or legitimacy of payment instructions. Keep those business outcomes separate from the technical acceptance statement. RFC 7208, section 2.4; RFC 7208, section 3.2; RFC 7208, section 4.6.4; RFC 9989, section 4.4
Acceptance worksheet for a billing-platform handover
Use this original proposed worksheet separately for materially different notification and Workflow routes.
- Scope: tenant, environment, feature, message category and selected transport.
- Sender: intended author domain, default versus custom identity, and accountable business owner.
- Provider request: exact generated or support-issued records, their issuing interface and the account they belong to.
- DNS review: complete affected SPF policy, three-CNAME comparison where applicable and existing dependencies.
- Product status: the relevant status columns, values and timestamps rather than one generic ready label.
- Message acceptance: minimized authorized sample with author, envelope and signing identities plus trusted validation.
- Change control: approval, rollback owner and treatment of scheduled billing communications.
- Release: current-applicability, production, visual and owner-review gaps explicitly recorded.
This blank acceptance design is not an executed test and contains no billing data, credentials or customer messages.
Fictional diagnosis: evidence from the default Workflow sender
A fictional subscription business verifies an Advanced SMTP identity for its production notification route. A reviewer then receives a Workflow sample using the default provider sender and treats its passing authentication as proof that custom-domain billing notices are ready. The sample and the claimed route do not match.
The proposed correction is to map each feature and transport before gathering additional evidence. The team retains the successful domain-identity status but asks for a properly authorized sample from the intended notification category. It does not replace the shared SPF policy or delete an identity to force unrelated messages to look alike. The report keeps unresolved Workflow customization separate. This scenario is fictional and describes no real tenant activity or verified Zuora failure.