Zuora SPF, DKIM and DMARC setup, step by step

Zuora email authentication depends on the sending route. For tenant Advanced SMTP, create and verify a domain identity using the three generated DKIM CNAMEs. For Workflow's Amazon SES route, request the three custom-sender DKIM records from Zuora Support. The default tenant server uses a different SPF authorization, and external SMTP requires authentication at the chosen provider. Verify each route independently with a real message. Zuora email-deliverability configurations.

This guide covers Zuora Platform Events & Notifications and Workflow email, including customer billing notices. It does not assume that Zuora Revenue, Zephr or every Zuora-branded product shares these settings. No tenant, DNS zone or delivered email was tested.

Which Zuora email route are you configuring?

Start with the feature, tenant environment, intended From domain and selected delivery service. One successful test cannot cover all combinations.

These are route-specific mechanisms, not complete replacement SPF records. Tenant SMTP options and Workflow Email task.

A Workflow message showing via amazonses.com does not establish that tenant Advanced SMTP is configured. Zuora explicitly documents separate delivery paths. Record the path used by each invoice, payment or other notification category before opening a DNS change.

Configure tenant Advanced SMTP with branded DKIM

Meet the identity prerequisites

Advanced SMTP uses Zuora's Amazon SES account, so this route does not require opening your own AWS account. Zuora requires an eligible domain associated with an active user's work-email domain in the tenant; check its current identity rules before adding anything. Do not create dummy users just to bypass a failed eligibility check. Advanced SMTP configuration.

The tenant documentation limits this configuration to one domain identity and up to three email identities, and disallows a domain identity alongside an email identity for the same domain. Review existing identities before planning a replacement. A verified email address is not equivalent to a verified domain: Zuora says its SES signature alone uses amazonses.com, while a verified domain identity enables an additional signature for your own domain. Identity limitations and signing behavior.

Create, verify and select the domain identity

1. Open Extension Studio > Events & Notifications > Settings.
2. Under Email Settings, open Advanced SMTP > Edit.
3. Select Domain Identity as the new identity type, enter the eligible domain and save.
4. In the Identities table, use View under DKIM Status. Publish the three CNAMEs from that dialog.
5. Wait for both Verification Status and DKIM Status to show Success.
6. Select Select Advanced SMTP Server, then verify the From address used by the intended notification.

The separate TXT record shown through Verification Status > View is not required to verify this domain identity. Do not confuse that dialog with the three DKIM CNAMEs. Zuora allows up to 72 hours for verification. Domain verification steps.

A verified domain can permit addresses under that domain and its subdomains, but permission to send does not prove strict DKIM alignment. If From is billing.example.com and the signature uses d=example.com, evaluate the policy's alignment mode before accepting it.

Keep environment records separate

For tenant Advanced SMTP, Production and API Sandbox share identity verification. Developer and Central Sandbox require the other applicable record set. Zuora illustrates six CNAMEs when all four environments are covered: three for Production/API Sandbox and three for Developer/Central Sandbox. Retain the generated records and their environment ownership. Do not remove a selector solely because the current test did not use it. Advanced SMTP environment rules.

Configure Workflow's custom From domain

Workflow's SES sender is a separate configuration. The default workflow@zuora.com address is provider-verified; that does not authenticate your organization's From domain.

For a custom Workflow sender, request three DKIM CNAME records from Zuora Global Support and identify the exact domain or subdomain in the From address. Publish the supplied records and add the documented SES SPF authorization at that domain's SPF owner. Wait for verification before treating the custom sender as ready. Workflow custom From setup.

For example, noreply@billing.example.com requires the billing.example.com identity. Verifying that child does not verify example.com. Request separate verification if the root domain must also send.

The current Workflow documentation says the same three CNAMEs apply across Production, API Sandbox, Developer Sandbox and Central Sandbox. This differs from the tenant Advanced SMTP environment grouping above. Do not combine the two sets of instructions.

Before an authorized delivery test, check the task's Preview Email in Logs Without Sending option. A preview is not a sent message. Also distinguish a successfully completed Workflow task from acceptance by the destination mail server: later rejection can still occur. Workflow delivery behavior.

Understand SPF and optional custom MAIL FROM

SPF evaluates the SMTP envelope sender, generally reported as smtp.mailfrom by the receiving system. It does not evaluate the visible From address directly. Each domain used as an SPF identity needs its applicable policy; SPF does not inherit from a parent domain. SPF identities and evaluation.

For the SES-backed routes, Zuora documents:

include:amazonses.com

For the default tenant email server, the documented mechanism is:

a:zgateway.zuora.com

Merge only the mechanism needed by the selected route into the existing TXT SPF policy before its terminal all. Do not replace a shared policy with a vendor example or add mx just because it appears in one. Preserve other authorized senders and the existing reviewed qualifier. If a policy uses redirect, review its evaluation carefully before changing it. Zuora's route-specific SPF guidance.

Maintain one v=spf1 policy at each owner and check the complete evaluation against the ten DNS-lookup-causing-term limit, including nested includes. Duplicate SPF policies and excessive dependencies cause permanent errors, not additional authorization. SPF processing limits.

If the existing SPF policy uses redirect=, do not blindly append an all mechanism or a complete canned policy: any all mechanism makes redirect ignored. Preserve the redirect-authorized senders and approved final semantics through a reviewed policy design. SPF redirect semantics.

Why an SES SPF pass may not align

SES normally uses an amazonses.com subdomain as its default MAIL FROM domain. That identity can pass SPF while remaining unaligned with your business's visible From domain. Adding the SES include at your own domain does not force SES to use your domain in the envelope. For that default envelope, branded aligned DKIM is the practical DMARC path. Amazon SES SPF behavior.

Zuora's Workflow documentation also describes an optional custom MAIL FROM setup, separate from DKIM verification. Obtain the actual enabled configuration and required MX and SPF records for your tenant from the responsible service owner. Because this route uses Zuora-managed SES, do not assume you can edit its SES console or that an AWS-console procedure alone enables the feature in Zuora.

SES custom MAIL FROM uses a dedicated subdomain and requires its own MX and TXT SPF records. The MX target is region-dependent. Do not guess the region, use an example feedback hostname, or replace existing inbound mailbox MX records. Confirm what happens if the custom MX fails: SES can be configured to fall back to its default envelope or reject sending, with different alignment and delivery consequences. SES custom MAIL FROM requirements.

For this optional enabled route, separately obtain routing-owner approval of the complete MX design: exact full owner, numeric priority and target hostname, alongside the issued SPF record. Receiving the provider packet is not routing approval. Reconcile it with the authorized design before publication or activation, compare the complete approved MX set at authoritative and recursive DNS, and stop on missing, extra or mismatched records. Preserve existing mailbox routing and delegated authority.

The Workflow Return Path (Email) field for receiving replies or failure notifications is not, by itself, evidence that a branded SMTP MAIL FROM identity has been provisioned. Verify the actual envelope in a delivered message.

What about default-server and external SMTP notifications?

Zuora default tenant server

Check the tenant-profile email address under Administration Settings > Manage Tenant Profile and the actual delivered envelope identity. Zuora describes that profile address as the notification mail.from value. Apply the documented default-server SPF mechanism only to the intended route and validate the result. Default server configuration.

An aligned SPF pass can satisfy DMARC, but it does not demonstrate branded DKIM. The cited default-server instructions do not provide the domain-identity DKIM workflow described for Advanced SMTP. If your acceptance requirement includes branded aligned DKIM, select and verify an appropriate supported route rather than declaring an SPF-only default-server test sufficient.

External SMTP for tenant notifications

Authenticate the From domain in the chosen provider and obtain its generated DKIM and envelope-domain records. In Zuora, open Events & Notifications settings, then Email Settings > External SMTP > Edit. Use the provider's required server, port, authentication and encryption settings. The documented sequence is Test Connection And Save, then Select External SMTP Server. A saved connection is only one acceptance checkpoint. External SMTP configuration.

Ensure the sender is permitted by the provider's relay or send-as rules. Keep the connection encrypted according to the provider's requirements; do not copy an insecure default just because a checkbox is optional. Review credentials and OAuth consent with the account administrator.

External SMTP for Workflow

Workflow has its own Settings > Login & SMTP Credentials > External SMTP configuration. Its documentation supports basic authentication and OAuth, with an available OAuth credential selected when that mode is used. Enter the actual SMTP server name and remaining required fields, then update. The tenant notification settings do not configure this separate route. Workflow external SMTP.

If you choose an Amazon SES account that your organization controls as the external provider, use the Amazon SES authentication guide for that account's domain and MAIL FROM setup. Do not apply its console steps to Zuora's separate managed SES account.

In both external cases, use the delivery provider's current domain records, not Zuora's default-server authorization or an assumed SES include. Secrets and OAuth tokens never belong in public DNS or diagnostic screenshots.

Creating persistent credentials, registering an application, granting OAuth access or expanding relay permissions requires separate approval from the responsible account/security owner. DNS troubleshooting is not authorization for those changes; preserve scheduled billing communications and use an approved rollback plan.

Publish DKIM at the correct DNS owner

Use all three generated CNAMEs for the selected Zuora domain-verification process. generated-token below is a placeholder. Do not copy another tenant's selector or invent a target.

For a provisioned MAIL FROM name such as bounce.billing.example.com, the relative owner is bounce.billing in the parent zone or bounce in the delegated child zone. Publish only the service-issued records at that owner. An empty example name is not authorization to change a live domain's routing.

Zuora explicitly warns about DNS panels that append the domain automatically. Check the resulting full name instead of always adding or always removing the suffix. A delegated child must be edited at its authoritative DNS service. CNAME owners cannot also hold conflicting ordinary records; preserve unrelated keys and ask for a compatible selector where necessary. Keep authentication CNAMEs DNS-only, not HTTP-proxied. Zuora DNS name guidance.

Keep the required literal CNAME answer: turn relevant per-record Flatten off where available and ensure applicable whole-zone settings do not suppress the alias. On Cloudflare, apex CNAMEs are flattened by default and same-zone targets are flattened regardless of that setting; flatten-all cannot be overridden per record. If mandatory behavior or a shared setting prevents the required answer, stop and coordinate a supported configuration without breaking other services or removing NS delegation. These are DNS-host behaviors, not controls assumed in the sending provider. Cloudflare flattening controls and limits. At an existing delegated _domainkey.billing.example.com authority, the full issued owner generated-token._domainkey.billing.example.com maps to relative generated-token. Preserve that NS delegation and other selectors; this token is only an illustrative placeholder. Relative DNS names.

Apply DMARC without weakening established protection

DMARC compares the visible From domain with a passing SPF or DKIM domain. Relaxed alignment means the same organizational domain; strict alignment means an exact match. A pass for amazonses.com does not align with example.com, even though SES is the legitimate transport. One passing aligned method can satisfy DMARC, but validating branded DKIM specifically requires that intended signature to pass and align. DMARC alignment.

Keep any existing policy, reporting addresses and subdomain rules. If no applicable policy exists and the owner approves monitoring first, this is an illustrative starting record:

Owner: _dmarc.example.com
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

Replace the domain and provision the reporting mailbox. For _dmarc.example.com, enter relative owner _dmarc in the example.com zone when the editor appends the zone name. A deliberately separate billing.example.com policy belongs at _dmarc.billing.example.com, entered as _dmarc.billing in the parent zone or _dmarc in a delegated child zone. Check inherited policy before creating an override, and never add two DMARC policies at the same owner.

External reporting destinations may need authorization. Review aggregate reports for each Zuora route alongside all other legitimate senders before moving to stricter enforcement. Reports show observed authentication and policy outcomes, not whether invoices reached inboxes or customers made payments. DMARC aggregate reporting.

Compare the Organizational Domain of the aggregate report URI’s host with the Organizational Domain of the domain where the DMARC policy was found, not necessarily the visible From domain. If they differ, the report-generating receiver must check DNS authorization. A destination within the same Organizational Domain as that policy domain is excepted; a different hostname alone does not make it external. This protocol check is separate from the domain owner’s approval to share report data with that recipient. RFC 9990 section 4.

Validate DNS, product status and delivered messages

Public DNS acceptance

Replace the sample names and repeat the DKIM query for all three actual selectors. These commands are read-only.

dig +short NS example.com
dig +short NS billing.example.com
dig @ns1.dns-provider.example generated-token._domainkey.billing.example.com CNAME +noall +answer
dig +short TXT generated-token._domainkey.billing.example.com
dig +short TXT actual-envelope-domain.example
dig +short MX provisioned-mailfrom.example
dig +short TXT provisioned-mailfrom.example
dig +short TXT _dmarc.billing.example.com
dig +short TXT _dmarc.example.com

Use the actual authoritative nameserver. For each DKIM alias, require the exact issued target and a resolvable public key through it. Compare authoritative and public recursive answers after the previous TTL. Check the actual record type; an empty TXT answer does not alone prove an expected CNAME is missing.

For Advanced SMTP, require both status columns to show Success and the intended server selection to be active. For Workflow, require confirmation for the custom From identity in that Workflow route. For external SMTP, require domain authentication at the external provider plus the active connection. Check provisioned MAIL FROM MX/TXT records only if that optional feature is enabled.

Message acceptance must match the route

Send an authorized, harmless sample through the intended feature, environment and From domain. A preview, successful task status, or message from workflow@zuora.com is not a substitute for a delivered custom-domain notification.

Read the destination mail system's trusted Authentication-Results and retain a minimized record of:

• Feature, transport, environment, notification type and observation time.
• Visible From domain and the SPF-tested smtp.mailfrom identity.
• SPF result, including any error reason.
• Every relevant DKIM d= domain and s= selector, identifying the intended branded signature.
• Whether that branded signature passes and aligns under the applicable policy.
• DMARC result and any delivery rejection or deferral.

Use receiver-added results, not an arbitrary sender-supplied authentication header. Authentication-Results trust.

Establish which result fields were generated inside the receiving service’s known processing boundary and how it removes or distinguishes externally supplied Authentication-Results. Use its documented handling or ask the receiving administrator if the boundary is unclear. A familiar authserv-id string or header position alone is not proof; reject attacker-supplied or otherwise untrusted fields. Operational result-field trust.

For branded DKIM acceptance, require dkim=pass for the intended domain and alignment with From. An additional passing amazonses.com signature is not enough. An overall DMARC pass produced only by SPF does not prove the branded DKIM setup succeeded.

Match the intended active route-specific signer’s d= and s= to the selected Zuora identity or supported external-provider configuration. Require that signature to pass and align under effective adkim with the unchanged intended visible From, plus the trusted receiver’s dmarc=pass. A different aligned signer or rewritten provider From does not complete this branded setup. Diagnose the actual smtp.mailfrom result independently: fail or softfail calls for checking the connecting sender against the approved authorization; temperror is a transient evaluation failure, often DNS; permerror requires checking malformed or duplicate policies and the evaluated lookup budget. An aligned DKIM pass does not repair these SPF faults. Do not change an unrelated apex policy to fix a provider-controlled envelope domain. SPF result definitions.

An unaligned SPF pass can be expected on a provider-owned SES envelope while aligned DKIM passes DMARC. Document that arrangement. Actual SPF fail, softfail, neutral, none, temperror or permerror on direct delivery still needs investigation; do not dismiss an error just because DKIM passed. Use a direct-delivery sample before analyzing forwarding effects, and retest after corrections.

Troubleshoot by route, not by provider name alone

Zuora's identity verification and Workflow task guidance describe the corresponding states and limitations. Preserve only the diagnostic data needed; avoid sharing customer invoices or credentials in support material.