Quick answer: This guide covers Webex Connect’s domain-based email route, not Webex Meetings invitations. Obtain your domain-verification TXT and all three DKIM CNAME records from the Email app asset. For the Amazon SES route, default SPF authenticates an SES envelope domain; branded SPF alignment requires a supported custom MAIL FROM setup. Never add a guessed Webex include to your root-domain SPF.
This is documentary guidance, not evidence of live customer configuration or test delivery.
Choose the correct Webex sending route
Webex Connect assigns either domain-based email or custom SMTP at tenant onboarding. Its Email documentation explicitly excludes the Webex Contact Center integration workflow. Campaign, Meetings and legacy WebEx Mail are not interchangeable with this guide. Confirm the actual product and tenant route before touching DNS. Webex Connect Email
If your application submits through your own Microsoft 365, Google Workspace or other SMTP service, configure that sender rather than borrowing the domain-based route’s records. The EmailAuth Google Workspace guide provides background for that separate sending service, not a replacement for Webex onboarding.
Ask the tenant administrator to identify the intended From address, domain-based asset, region, underlying sender and owner of the sending domain. Confirm that this is an existing approved service. Do not create a new cloud account, change tenant routing or grant credentials simply to match instructions here.
Prepare a bounded change plan
Write down the exact records you intend to add, the authoritative DNS zone and the person approving the change. Export existing TXT, CNAME, MX, delegation and DMARC records first. Include their owners, types, values and TTLs, not just a screenshot of the top-level domain.
Keep three identities distinct:
| Identity | What it proves |
|---|---|
| Domain-verification token | The application can verify control of a named domain |
DKIM signing domain, shown as d= |
A signature can authenticate selected message headers and content |
| SMTP MAIL FROM domain | SPF evaluates which servers may send using this envelope identity |
The recipient-visible From is a fourth identity. DMARC connects it to passing SPF or DKIM through alignment. Verification of domain ownership alone does not establish signing, alignment or delivery. These distinctions follow SPF, Authentication-Results and DMARC.
Obtain the verification and DKIM records
In the authorized Webex Connect account, use Assets > Apps > Configure New App > Email for a new approved asset, or inspect the existing intended asset. Enter the domain without a web-address scheme. Generate Verification Records provides a TXT record; the documentation requires publication within 24 hours. Enable DKIM Settings to obtain three CNAMEs, then publish the exact issued records. Webex warns DNS changes can take up to 72 hours. Webex Connect Email
Before changing an existing asset, confirm when it was configured. Webex warns that assets configured before v5.6.3 (April 2022) can be disrupted by setup changes, including adding an email ID. Stop and consult Webex support for that legacy case; do not treat this as an instruction to enable inbound mail. Webex Connect Email
Do not copy tokens, names or targets from a public screenshot. Use the current account’s complete public record packet. A verification token is not an SPF policy; a DKIM CNAME is not an MX record. If the window expired, obtain a fresh supported handoff rather than guessing whether an old token remains valid.
Record issuance, DNS publication, provider verification and actual signing are separate checkpoints. After publication, inspect the intended asset’s current state and resolve any pending verification with the administrator or Webex support. Do not interpret merely displaying the three records as proof that the service is signing outgoing messages.
Put each record in the right DNS zone
These are illustrative owner mappings, not provider-issued values. Suppose the packet contains SELECTOR._domainkey.notify.example.com:
| Authoritative zone edited | Relative owner, if the editor appends that zone |
|---|---|
example.com |
SELECTOR._domainkey.notify |
Separately delegated notify.example.com |
SELECTOR._domainkey |
Separately delegated _domainkey.notify.example.com |
SELECTOR |
If the editor expects a fully qualified name, enter the complete issued owner instead. Check the resulting DNS name; do not create example.com.example.com accidentally. Preserve existing NS delegations and selectors. For a TXT token, copy its complete issued value without converting it into a DKIM public key or SPF string.
A CNAME owner cannot also hold conflicting TXT, A, AAAA, MX or another CNAME. Resolve collisions with the DNS administrator and sender before proceeding. Do not delete another service’s record or delegated namespace to make room.
For hosts offering HTTP proxying, use DNS-only publication. Preserve the required literal CNAME answer: turn the relevant per-record flattening control off where available and ensure applicable zone-wide rules do not suppress the issued aliases. Some hosts impose apex flattening or flatten same-zone targets even when a general control is off. If the host cannot preserve the required answer at the issued owner, stop and agree a supported alternative with the DNS host and Webex. Do not disable shared settings globally or invent a control the host lacks.
Decide whether custom MAIL FROM is needed
For Webex Connect with SES, the default envelope uses an amazonses.com subdomain. Custom MAIL FROM requires a child of the verified identity, not a domain already used to receive mail or ordinarily used in From. Webex documents both SPF TXT and bounce-handling MX at that envelope owner; its regional MX example is not universal. Confirm the actual region, generated values and activation with Webex. Webex Connect deliverability guidance
Do not replace your organization’s mailbox MX. Compare the proposed bounce destination with the approved routing plan, even when the vendor supplies it. If the envelope hostname already receives business mail or is shared, stop and choose a supported unused owner with the administrator.
The documented SES authorization is include:amazonses.com. For a new, dedicated, approved SES-only custom MAIL FROM owner, after confirming applicability and the provider packet, its example policy is:
v=spf1 include:amazonses.com -all
This is not a root-domain default. Publish at the exact confirmed envelope owner. In an editor for example.com, an illustrative envelope bounce.notify.example.com maps to bounce.notify; in a delegated notify.example.com zone it maps to bounce. MX priority and target are separate fields; obtain both from the approved packet rather than copying a region from this article. Webex Connect deliverability guidance
If SPF already exists at that owner, merge only approved authorizations into its single policy. Preserve legitimate mechanisms and qualifiers. Count the ten evaluated DNS-dependent terms including nested expansions, not just visible includes. An all mechanism makes redirect ineffective. Do not replace a complex policy without understanding its authorized senders. RFC 7208
For example, bounce.notify.example.com and From notify.example.com can align under relaxed SPF alignment when they share the same Organizational Domain. They do not match under strict SPF alignment. Do not weaken an existing strict policy to force this design through: obtain an approved configuration, or rely on an intended aligned DKIM signature where appropriate. An SES SPF pass alone is not branded SPF alignment.
Preserve or establish DMARC deliberately
Inspect the policy applicable to the actual From domain, including inherited policy. Preserve existing enforcement and authorized report recipients; never replace a working policy merely because a vendor example uses another value.
Only when there is no direct or applicable inherited policy, and the domain owner approves a monitoring plan, a first-policy example for From notify.example.com is:
Owner: _dmarc.notify.example.com
Type: TXT
Value: v=DMARC1; p=none
In example.com, its relative owner is _dmarc.notify; in a delegated notify.example.com zone, _dmarc. This example has no report destination and requests monitoring rather than enforcement. Arrange an approved way to review actual authentication results before progressing to enforcement. Never duplicate DMARC records or apply this example as a downgrade. RFC 9989
If aggregate reports are added, a destination in a different Organizational Domain from the policy domain requires the report-generating receiver to check DNS authorization. A destination in the same Organizational Domain is excepted. DNS authorization does not replace the domain owner’s privacy and data-sharing approval for the recipient. RFC 9990 section 4
Verify the intended sending path
Before a test, inspect the authoritative records and their resolution through ordinary recursive DNS. For CNAMEs, verify all issued aliases remain literal CNAME answers and resolve to their supplied targets. A successful DNS lookup is not an email test.
Use a controlled valid recipient and the intended application flow, not a different mailbox or unrelated Webex product. Avoid live customer campaigns, charges, appointment changes or business notifications as tests. Retain the approved From, asset and timestamp alongside the resulting message headers.
Inspect Authentication-Results generated inside the actual receiver’s known processing boundary, using that receiver’s documented treatment of externally supplied fields. A familiar authserv-id string or header position alone does not prove trust; ignore attacker-supplied results. RFC 8601
For a newly configured branded DKIM route, require the intended signature to pass with d= aligned to the intended From under the effective adkim setting, plus trusted dmarc=pass. For DKIM, relaxed alignment means the signing domain and From domain share the same Organizational Domain; strict alignment requires those domains to match exactly. An SPF-only DMARC pass does not prove DKIM works. A provider-rewritten From is not successful authentication of your original brand identity. Record SPF’s actual evaluated envelope domain separately.
Troubleshoot without weakening protection
| Finding | What to check next |
|---|---|
| Verification pending | Current token, publication window, authoritative zone, exact owner and TXT value |
| DKIM missing or failing | Intended asset, all issued CNAMEs, owner collisions, literal alias answers, sender-side completion and a fresh message |
spf=fail |
Actual envelope identity and authorized sending path; an aligned DKIM pass does not repair SPF |
spf=temperror |
Transient DNS or resolver failure; investigate and retest after recovery rather than broadening authorization |
spf=permerror |
Multiple policies, invalid syntax or excessive evaluated DNS-dependent terms at the envelope owner |
| SPF or DKIM passes but DMARC fails | Actual From, authenticated identities and effective strict/relaxed alignment |
| Everything authenticates but delivery fails | Recipient policy, content, reputation, limits and the actual bounce response |
Webex’s SPF status Configured denotes custom MAIL FROM; Default SPF Configured denotes the underlying service. Unable to Fetch Status is not a pass. Refresh missing status, then investigate the actual DNS and message evidence. Webex Connect Email
Webex documents authentication-related bounce information under webhook additionalInfo, including 7520-associated failures and receiver codes such as 5.7.26. Diagnose the complete sanitized receiver response, not the number alone. Do not disable DMARC or filtering as a shortcut. Webex Connect deliverability guidance
If a change causes problems, pause the affected flow with its owner and coordinate sender activation before removing DNS. Restore only the approved changes from the baseline; do not remove shared records. Allow for caches when assessing recovery. Authentication improves identity assurance but cannot guarantee inbox placement.