Scope and prerequisites
Identify Creator’s active outgoing channel before changing DNS. The super admin manages channels; domain authentication requires a paid plan.
Configure the documented route
- Step 1. For built-in delivery, verify the sender address. Open Operations, Email Management, Outgoing Email Channels and Manage Domains on Built-in Email.
- Step 2. Validate the domain, copy its SPF and DKIM instructions, publish the records and validate again. Completion requires Authentication Status Completed and Status Active.
- Step 3. Before switching to ZeptoMail, verify the domains there separately and test every required sender.
- Step 4. Only one channel is active. Deleting an active, deletable external channel configuration activates built-in delivery. Built-in Email and ZeptoMail cannot be deleted; ZeptoMail must be disassociated instead. Check the applicable recovery operation and fallback before changing anything.
Product-specific risks
Authentication must follow the delivery channel, not just the application name. Build a test inventory of workflow notifications, scheduled messages and user-triggered actions, with the sender chosen by each. If an action succeeds in Creator but no mail arrives, separate application execution from SMTP acceptance and recipient delivery. Channel migrations also change operational dependencies such as credentials and quotas; give their owner a clear rollback decision without recording secrets in the evidence ticket.
Prove the route at the receiving end
Use an approved external mailbox and save the complete raw message with its timestamp and message identifier. No live tenant test is claimed in this guide. The following is an acceptance worksheet to complete during implementation, not a record of observed results.
- Evidence field: Visible From; What to record: Actual address and domain; Acceptance question: Is this the intended sender identity?
- Evidence field: Envelope; What to record: Return-Path and receiver-reported SPF domain; Acceptance question: Which domain did SPF actually authenticate?
- Evidence field: SPF; What to record: Trusted receiver result and evaluated identity; Acceptance question: Did it pass, and does that identity align?
- Evidence field: DKIM; What to record: Every d= domain, s= selector and receiver result; Acceptance question: Does at least one passing signature align?
- Evidence field: DMARC; What to record: Receiver result and applicable policy; Acceptance question: Does an aligned passing path exist?
- Evidence field: Route; What to record: Product, account and message type; Acceptance question: Did the test use the production path?
DMARC needs at least one aligned, passing SPF or DKIM path. A passing signature from an unrelated service domain is not enough. Strict alignment requires exact domain equality; relaxed alignment uses the applicable organizational-domain relationship. Check the domain's actual alignment settings before declaring success. A subdomain is not an automatic strict match. SPF uses the SMTP identity, not the display name or Reply-To. Consult the alignment glossary when recording the decision.
Use Authentication-Results from the receiving system you trust, not a header supplied by an arbitrary sender. Capture all signatures rather than stopping at the first failure. For forwarded mail, compare a direct test with a forwarded copy: forwarding may change SPF evaluation or alter signed content. Do not diagnose those effects by adding the forwarder's address to your provider authorization.
Diagnose failures without widening access
Compare authoritative DNS with the exact configured record names first, then check recursive visibility and service validation. A wrong name, truncated key or conflicting CNAME is not fixed by waiting for caches. Keep only one SPF policy at an owner and check the ten DNS-lookup-term limit across evaluated includes and redirects before merging another sender. DKIM selectors belong to individual signing configurations; do not overwrite another application's record to force a validation result.
If authentication passes but delivery is poor, inspect the recipient response, reputation, content and sending permissions separately. DMARC pass does not promise acceptance or inbox placement. If neither path aligns, stop expansion and correct the actual sender configuration. Do not weaken the whole domain's DMARC policy to hide a single product failure.
Handover and recovery
Save the approved DNS diff, public lookup results, service status and redacted received-message worksheet with a named owner. Keep credentials and private keys out of tickets. On failure, pause the affected sending job or use a previously tested route under the service owner's control. Restore only the changed records that belong to this integration; keep public keys needed by in-flight messages. Retest after rollback, key rotation, domain migration or a change in outbound relay. Close the change only when the product owner and mail administrator can explain the observed identity chain.
Confirm the provider boundary
The current page also documents Microsoft 365, personal Outlook, Gmail and Custom SMTP channels. This article covers built-in authentication and channel-change acceptance, not complete credential provisioning for those services. Use their current authorized account setup, sender aliases and security controls separately. Creating a configuration does not activate it. Built-in Verification Status Completed after address verification differs from Authentication Status Completed and Status Active after DNS validation.
Work through a fictional diagnostic case
Fictional written case only: CR-01 assumes deleting an active Custom SMTP channel configuration causes a paid Creator account to use notifications@mailer.zohocreatormail.com instead of intended alerts@shop.example. Authentication results are unknown. The super admin must check the active fallback, built-in domain authentication and required workflows before resuming them. A previously passing external-channel sample cannot close the changed route. No tenant, DNS, server command or message was exercised for this case.
Plan fallback before changing the active channel
The documented built-in shared From identities are notifications@mailer.zohocreatormail.com for paid users and notifications@trial.zohocreatormail.com for trials when custom authentication is absent. ZeptoMail domains must be verified again there; the integration creates a Creator Default mail agent and changes sending to a credit-based system. Dissociation restores plan-based daily limits and removes access to the integration’s tracking, bounce and log features; re-verification is required. Revoking an active channel’s authorization stops delivery until reauthorized, whereas deleting an active, deletable external channel configuration activates built-in delivery. Built-in Email and ZeptoMail cannot be deleted. ZeptoMail uses disassociation instead; do not treat that operation as channel deletion. Choose the intended recovery action explicitly and capture all required senders before changing anything.
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.