Symantec Email Security.cloud SPF, DKIM and DMARC setup, step by step

For Symantec Email Security.cloud, add include:spf.messagelabs.com to the applicable single SPF TXT policy, then configure outbound DKIM in ClientNet → Dashboard → Platform → DKIM Signing. Publish the generated selector TXT record, run Test, and enable signing only after the test succeeds. Finally, prove that a message sent through the actual cloud relay has a passing, aligned branded DKIM signature and a DMARC pass. Broadcom SPF instructions, ClientNet DKIM configuration

This guide is for the Email Security.cloud outbound relay, historically associated with MessageLabs. It is not a Symantec Messaging Gateway appliance guide or a setup recipe for every Broadcom security product.

These are documentary instructions and reader-run checks. No customer account, DNS change or test message was used to verify an implementation.

On this page

• Confirm prerequisites and the signing path
• Configure MessageLabs SPF safely
• Configure DKIM in ClientNet
• Publish the right DNS owner
• Preserve DMARC and verify alignment
• Commission DNS and the real message route
• Troubleshooting
• Safe rotation, recovery and offboarding
• Frequently asked questions

Confirm prerequisites and the signing path

Broadcom requires ClientNet administrators to have View Config and Edit Config for all services, with the domain and outbound IP addresses registered. For hosted providers, SPF checks must pass. Confirm these prerequisites in the actual tenant before diagnosing a missing signature as a DNS-key problem. Outbound DKIM requirements

Prepare an approved change record containing:

• The registered domain, the submitting system and the actual outbound connector through Email Security.cloud.
• Visible From, SMTP MAIL FROM/Return-Path and the intended DKIM signing domain.
• Current SPF, DMARC, MX and active DKIM records, including their TTLs and authoritative zone owners.
• Every transformation applied by the relay and any later service: subject tags, disclaimers, URL rewriting or additional relays.
• A DNS administrator, a ClientNet administrator, a controlled external test mailbox and a rollback owner.

A mail platform's existing DKIM signature may not survive changes made by an intermediary. Broadcom identifies subject tagging, disclaimers and Click-time URL Protection as potential causes and recommends Email Security.cloud signing. The practical objective is to have an aligned signature that survives the complete outbound path, including any changes after this relay. Third-party DKIM interactions

If Microsoft 365 is upstream, keep its authentication and connector configuration distinct. Our Microsoft 365 SPF and DKIM guide covers that platform; it does not replace ClientNet signing or authorize all possible relay paths.

Configure MessageLabs SPF safely

SPF checks the recipient-facing sender IP against the policy for the SMTP envelope domain. It does not automatically check the visible From domain. Establish that actual envelope domain before selecting the DNS owner to edit. SPF identity rules

Broadcom documents include:spf.messagelabs.com. It also recommends retaining service authorization for customers whose normal outbound mail uses another route, because mail to another service customer can still traverse Email Security.cloud. Service SPF reference

Apply the authorization with these safeguards:

1. Query TXT at the exact envelope-domain owner and save the current answer. Your registrar is not necessarily your authoritative DNS provider.
2. If an SPF policy already exists, add the include to that policy before its terminal all. Preserve other legitimate systems and unrelated TXT records.
3. If there is no SPF record, create a reviewed policy for all actual senders at that owner. A vendor-only example is unsuitable when other services also send there.
4. Keep the existing ~all or -all decision unless changing it is part of an approved domain-wide policy review. Do not add Microsoft 365 merely because an example includes it.
5. Validate the complete policy, publish it once and recheck authoritative DNS.

SPF allows one applicable v=spf1 policy at an owner. Its limit is ten evaluated DNS-dependent mechanisms/modifiers, including nested include and redirect paths, plus evaluated a, mx, ptr and exists. ip4, ip6 and all do not consume that budget. Counting only top-level includes is insufficient, and an exceeded budget yields permerror. RFC 7208 publication and evaluation limits

If an existing SPF policy uses redirect=, preserve its intended authorizations and final semantics through a reviewed merge. Any all mechanism causes redirect to be ignored, so appending a canned policy or an all without reviewing that dependency can change which senders are authorized. SPF redirect semantics.

Do not flatten the include into a manually copied IP snapshot without an approved maintenance mechanism. Also distinguish SPF fail from a guaranteed rejection: receivers apply their own handling and DMARC policy. Broadcom's “hard mode” explanation should not be read as a promise that every receiving system discards every SPF-failing message.

Configure DKIM in ClientNet

Open Dashboard → Platform → DKIM Signing, find the registered domain and select it. Use Add New for a selector containing only a-z and 0-9. Choose a supported key length, save, and keep the dialog open while copying the generated Host Name and TXT value. Publish those public values in DNS. Then return to the domain, select the intended selector and click Test. After success, close the dialog and use the DKIM Enable slider. At least one selector is required. ClientNet signing procedure

For a new RSA signing deployment, prefer 2048 bits or stronger when supported by both the service and DNS host. Current DKIM guidance requires at least 1024 bits and recommends at least 2048; do not select an obsolete small key to avoid handling long TXT values. Do not use rsa-sha1. RFC 8301

Creating a selector is not the same as enabling it. Keep the old active selector available during a staged replacement. Record the selected domain, selector and activation state together, so an administrator cannot accidentally test one key while intending to deploy another.

Broadcom allows up to 72 hours for DNS propagation. That is a troubleshooting allowance, not a requirement to wait 72 hours after every edit. If authoritative DNS already shows a wrong owner or missing key, correct that defect first; a longer wait will not fix it. DKIM verification and troubleshooting

Publish the right DNS owner

The generated key normally belongs beneath a selector-scoped name, not at the bare domain:

SELECTOR._domainkey.SIGNING_DOMAIN

This is a shape, not a value to publish. Use the exact ClientNet Host Name. For a fictional mail2026._domainkey.example.com owner, a DNS editor that appends example.com would take mail2026._domainkey; an FQDN-based editor would take the full name. Check for an accidental example.com.example.com suffix.

Use the authoritative zone for that name. An NS delegation of _domainkey.example.com means the delegated child zone, not an inactive parent-zone entry, controls its selectors. Coordinate with any existing hosted-DKIM operator; do not replace a delegation or another sender's selector just to satisfy this setup.

For an issued signing domain such as news.example.com, a full owner SELECTOR._domainkey.news.example.com is SELECTOR._domainkey.news relative to the parent example.com zone, or SELECTOR._domainkey in a separately delegated news.example.com zone. If _domainkey.news.example.com itself is delegated, the relative owner there is SELECTOR. Replace the selector placeholder with the issued value, preserve the account’s exact type and public value, and publish at the actual authority without removing the NS delegation. This example explains name placement, not automatic product eligibility for a new domain. DKIM owner construction, relative DNS names.

Preserve the exact logical TXT value. Long records can be split into adjacent quoted character strings within one TXT record. They are concatenated by DNS clients. Do not create separate keys from the pieces, insert spaces within the encoded p= data or publish a private key. A blank p= revokes a key. DKIM key syntax and storage

The documented ClientNet workflow issues TXT records. Do not invent CNAME targets. If an existing managed configuration already has a CNAME at that owner, resolve the conflict with its operator before changing it. A CNAME cannot coexist with a competing TXT at the same owner and must not be proxied or flattened into web-server A/AAAA records. DNS alias requirements

If Cloudflare hosts a required DKIM alias, check DNS only, turn that record's Flatten option off where available, and check the zone-wide CNAME flattening for all CNAME records setting. DNS-only by itself does not prevent flattening. Coordinate any shared zone-setting change with its DNS owner so other services are not disrupted, and preserve a valid child-zone or _domainkey NS delegation by publishing with its actual operator. Cloudflare CNAME verification troubleshooting, Cloudflare flattening settings

For this conditional existing-alias branch, retain the literal CNAME answer. Cloudflare flatten-all cannot be overridden per record; apex CNAMEs are flattened by default, and same-zone targets are flattened regardless of that setting. If mandatory behavior prevents the required alias, stop and coordinate a supported configuration without removing shared delegation or breaking other services. The native ClientNet issuance remains TXT. Cloudflare limits.

Preserve DMARC and verify alignment

Under current DMARC, a message passes if SPF passes and its authenticated envelope domain aligns, or DKIM passes and its d= domain aligns with the visible From. Relaxed alignment compares organizational domains; strict aspf=s or adkim=s requires exact equality. A provider signature can pass cryptographic verification while remaining unaligned. RFC 9989, alignment

For example, From alerts.example.com and DKIM d=example.com can align under relaxed rules but not strict DKIM alignment. Reply-To, display name and the application's SMTP login do not affect that comparison. With multiple signatures, identify which passing signature actually aligns instead of treating “DKIM passed somewhere” as sufficient.

Preserve the existing DMARC policy and any applicable parent policy. Do not weaken enforcement for this integration. If the domain has no effective policy, an approved monitoring-only policy at _dmarc.<from-domain> may be appropriate while all senders are inventoried. Assign a report reviewer and a plan for enforcement based on evidence. RFC 9989 supersedes RFC 7489; avoid obsolete pct rollout instructions.

Only when no direct or applicable inherited policy exists and the domain owner approves first-time monitoring, publish one TXT policy with v=DMARC1; p=none at the intended From domain’s DMARC owner. For example.com, the full owner is _dmarc.example.com, entered as _dmarc in that zone. For news.example.com, use full owner _dmarc.news.example.com: _dmarc.news relative to the parent zone, or _dmarc in the separately delegated child zone. Do not create a child monitoring exception to an existing protective policy. The minimal value requests no reports; append ; rua=mailto:APPROVED_REPORT_ADDRESS only after replacing the placeholder with a provisioned, approved destination. DMARC policy publication.

Configure only approved rua report recipients. For an external destination, follow its exact external-report authorization procedure and verify the necessary DNS. Review who can see the source IP/domain metadata and how long it is kept. Failure reports can expose more message data and should not be enabled casually. Aggregate reporting, RFC 9990

Compare the Organizational Domain of the aggregate-report URI host with the Organizational Domain of the domain where the DMARC policy was found, not automatically the visible From domain. If they differ, the report-generating receiver must check the destination’s DNS authorization. A destination in the same Organizational Domain as that policy domain is excepted, even when its hostname differs. This protocol check does not replace the domain owner’s separate approval to share report data with that recipient. RFC 9990 section 4.

Commission DNS and the real message route

Replace every uppercase placeholder below before running these reader-run checks. No output or successful result is implied:

dig +trace ENVELOPE_DOMAIN TXT
dig @SPF_AUTHORITATIVE_NS ENVELOPE_DOMAIN TXT +noall +answer
dig +trace SELECTOR._domainkey.SIGNING_DOMAIN TXT
dig @DKIM_AUTHORITATIVE_NS SELECTOR._domainkey.SIGNING_DOMAIN TXT +noall +answer
dig +short TXT _dmarc.FROM_DOMAIN

Identify each owner’s authoritative server independently. Confirm the SPF include is in one valid policy and the DKIM owner/value matches the selected ClientNet key. If a managed CNAME delegation is expected, query that alias and follow its exact target to a usable TXT key. Compare recursive-resolver answers with authoritative answers to detect stale caches. Neither a DNS answer nor ClientNet's Test proves a message was signed.

After Test and Enable, send an authorized message from the actual submitting application through the normal relay policy to a controlled external mailbox. Test both an ordinary message and a case that triggers representative subject/disclaimer/link modifications. For each case, retain the following evidence privately:

Use receiver-controlled diagnostics or have the receiving administrator establish which Authentication-Results field the destination generated and how externally supplied fields are removed or separated. A familiar authserv-id or a header's position alone cannot establish provenance. When that boundary is unclear, obtain the receiver's authenticated mail trace instead of accepting an upstream header as proof. RFC 8601 trust boundary

Do not close the change on DMARC pass alone. If SPF rescued DMARC while the intended branded DKIM signature failed or was missing, the DKIM setup remains incomplete. Conversely, an aligned DKIM pass can rescue DMARC while SPF has an error; that SPF error still needs separate diagnosis. Authentication acceptance does not guarantee inbox placement.

Troubleshooting

For an SPF fail or softfail with valid DNS, compare the recipient-facing egress IP and envelope domain with the policy. Confirm the message really traversed the service before expanding authorization. For a DKIM body-hash failure, additional SPF authorization cannot repair altered signed content.

Safe rotation, recovery and offboarding

For rotation, create a fresh selector, publish its key, Test it and switch the intended active selector only after verification. Retain the old public key until messages signed with it have cleared the applicable queue/cache window. If a new configuration breaks mail, restore the captured known-good selector/routing state and matching DNS under the approved change plan, then repeat the same message-level checks.

Offboarding requires more than moving the main outbound connector. Broadcom instructs customers to retain the service SPF authorization and valid DKIM selector until their domains are fully removed from Email Security.cloud. Customer-to-customer routing can continue through the service. Only if inbound mail is also being migrated, obtain the routing owner’s separate approval for the exact inbound destination and complete MX plan, including every full owner, numeric priority and target. Service-issued values alone do not authorize redirecting mail. Update the service's inbound routes before MX, allow the documented propagation/TTL transition, and coordinate domain removal. Export needed reports and logs before removal: Broadcom says removal deletes them. Service-cancellation and migration guidance

For that approved inbound migration only, query the full MX owner at the authoritative nameservers and through recursive resolvers. Before accepting the transition, compare the complete returned numeric-priority/target set with the routing owner’s approved plan; stop on any extra, missing or different tuple. A nonempty MX answer is not success. This optional routing transition is not part of the outbound-only authentication setup. Broadcom migration sequence.

Do not delete a domain as a troubleshooting reset. Keep address registration and residual routing current during any overlap. Confirm the replacement service's authentication, retained evidence and rollback readiness before removing old DNS authorization. Offboarding is a separate authorized change, not an automatic part of adding DKIM.