Provider documentation checked on 8 November 2026. Account-generated values, entitlements and current support remain deployment prerequisites.
Scope and provider-specific configuration
References: RFC 7208 §3.2, RFC 6376 §3.7.
The Symantec Email Security.cloud workflow is documented by Broadcom and uses ClientNet. Treat it as an outbound relay and signing configuration, not simply a TXT-record exercise. Existing upstream DKIM signatures can be invalidated by message transformations on the relay.
Broadcom requires administrators with View Config and Edit Config roles for all services, registered domains and registered outbound IP addresses. For hosted providers, SPF checks must pass. Open Dashboard, Platform, DKIM Signing. Locate the registered domain, choose Add New and supply an alphanumeric selector using a-z and 0-9. At least one selector is required before enabling DKIM. Choose an available key length supported by DNS, save, and keep the dialog open to copy the generated Host Name and TXT value.
Publish the exact public TXT record at the DNS host. Return to the selected domain and selector, run Test, and only after a successful lookup use the DKIM Enable slider. This ordering matters: copying a key into a local worksheet does not make it discoverable, and a selector created in ClientNet is not the same as an enabled signer. The article gives a propagation allowance of up to 72 hours; direct DNS evidence is more useful for locating a wrong owner or malformed key.
For SPF, Broadcom documents include:spf.messagelabs.com and recommends keeping its authorization even where routine outbound mail takes another route, because customer-to-customer paths can still traverse the service. Add the include to one reviewed SPF policy rather than replacing other legitimate senders. An SPF fail result is not itself a command that every receiver must discard mail; receiver handling and DMARC alignment are distinct.
Broadcom warns that subject tagging, disclaimers and Click-time URL Protection can break a third-party DKIM signature when they alter signed material. Its recommended approach is Email Security.cloud signing. Test the actual policy path with representative transformations enabled. During offboarding, do not remove authorization merely because the main outbound connector has moved; confirm residual service routing and domain removal first. Broadcom’s migration guidance calls for updating inbound routes before changing MX, then coordinating removal after the DNS transition. It warns that removing domains deletes their reports and logs. Export the evidence required by your retention policy before an authorized removal; do not treat domain deletion as a harmless routing reset.
The decision that matters
Validate signing after relay transformations and keep authorization until the service’s actual routing dependency ends. Illustrative diagnosis: an upstream signature verifies before a disclaimer is appended but fails afterward. Adding SPF authorization cannot repair that signed-body mismatch; inspect the downstream signer and its actual alignment. This is a proposed comparison, not an executed experiment.
Verify the published records and the real sending path
References: RFC 7208 §3.3, RFC 9989 §4.4, RFC 6376 §6.
Record the change owner, sending product, domain, approved maintenance window and prior DNS answers before editing. Obtain the current record values from the named account or documented provider workflow. Separate values supplied by the provider from choices your organization controls, such as DMARC policy and reporting recipients. Existing mailbox MX, unrelated verification TXT records and active DKIM selectors are not cleanup candidates merely because a new service is being added.
Query the authoritative name servers for each exact owner and record type after publication. Record the query time, responding server and complete answer. Compare TXT strings as one logical value where the DNS response splits them into character strings. Check CNAME targets as well as the starting alias. Then compare a recursive-resolver answer to identify caching differences. A successful provider validation is useful evidence of configuration, but it does not establish what an actual recipient received.
Send only an authorized test to a controlled recipient using the intended product route. Retain the raw message and the trusted receiving system's Authentication-Results. Record the visible From domain, SMTP MAIL FROM or observed Return-Path domain, every DKIM d= and s= value, SPF and DKIM outcomes, and the receiver's DMARC result. A passing SPF or DKIM check supports DMARC only when its authenticated domain aligns with the visible From domain under the applicable policy. Reply-To and a branded display name are not alignment identities. RFC 7208, RFC 6376 and RFC 9989 provide the protocol basis for these distinctions.
Acceptance worksheet, recovery and evidence limits
This is an original acceptance worksheet, not a report of live testing. Mark each gate pending until evidence exists: account scope confirmed; previous DNS captured; exact new owner/type/value published; provider verification complete; intended route exercised; received identities recorded; aligned authentication confirmed; other senders unaffected. Assign a person and evidence file to every gate. A red gate blocks rollout even when the provider dashboard is green.
If a test fails, first distinguish missing publication, stale cached data, inactive provider configuration, wrong outbound route and nonaligned authentication. Correct the smallest demonstrated defect and test again. Do not weaken DMARC or delete other senders' records simply to make one test pass. If a change harms existing mail, use the approved recovery plan and the captured pre-change configuration, coordinating any provider-side sender change as well as DNS. Retain old keys while queued messages or an approved overlap still require them.
No customer tenant, authoritative before/after change or real received message was available for this manuscript. The retained sources support the documentary workflow; they do not satisfy the commissioned live-evidence gate. Independent checker review and human SME approval remain pending. Do not describe this guide as field-validated or publish it as having passed those gates.