Cisco Cloud Email Security SPF, DKIM and DMARC setup, step by step

For Cisco Secure Email Cloud Gateway, authorize the customer-specific SPF allocation supplied by Cisco, configure an AsyncOS DKIM signing key and matching domain profile, publish its public TXT record, and enable signing on the intended outbound mail-flow policy. Accept the change only after an external receiver reports a passing, aligned branded DKIM signature and dmarc=pass. Cisco Cloud Gateway SPF guidance, AsyncOS email authentication

This guide covers the Cloud Gateway/AsyncOS outbound route, often associated with iphmx.com. It does not turn a Cisco Email Threat Defense API deployment into an SMTP gateway, nor apply Cisco RES/CRES encryption-service SPF instructions to all Cisco mail. The procedural reference is AsyncOS 16. Confirm your actual version and supported menus before implementation.

No customer gateway, DNS change or delivered-message test was accessed or performed.

On this page

• Prerequisites and route inventory
• Configure the allocation-specific SPF policy
• Create and enable DKIM signing
• Handle DNS names and delegation correctly
• Establish DMARC alignment
• Run DNS and message acceptance checks
• Troubleshoot without weakening authentication
• Rotate or recover safely
• Frequently asked questions

Prerequisites and route inventory

Have an authorized Cloud Gateway administrator, authoritative DNS access, your Cisco service/activation information, a configuration backup and an approved recovery plan. Cisco recommends reviewing the impact of production changes with the responsible Cisco service team rather than treating its lab examples as a ready-made production configuration. Cloud Gateway configuration guidance

Record every route to be covered: staff mail, applications, service accounts, delegated senders and any system-generated messages. For each, capture the originating platform, outbound connector, gateway listener/policy, recipient-facing egress, visible From, SMTP MAIL FROM and intended DKIM d=. Note downstream services that add signatures, disclaimers or rewrite links.

Do not change mailbox MX merely to add outbound SPF or DKIM. MX routing, an outbound smart host and authentication records solve different tasks. If an upstream Microsoft 365 tenant also signs mail, preserve its working configuration and use our Microsoft 365 authentication guide for that separate hop.

For a load-balanced cloud allocation, Cisco supplies outbound NAT/VIP information and the allocation's SPF mechanism during activation. The full suffix can be customer- and region-specific. Neither a public example allocation nor an inbound MX address proves the correct recipient-facing sending IP. Cisco load-balancer FAQ

Configure the allocation-specific SPF policy

Cisco documents this mechanism shape, not a universal include:

exists:%{i}.spf.ALLOCATION.iphmx.com

ALLOCATION is a placeholder. Copy the complete actual mechanism, including any regional suffix, from your service information or supported account instructions. Keep %{i} intact: it expands to the connecting sender's IP during SPF evaluation. The receiver checks for an A record at the expanded name; Cisco maintains that allocation namespace. You do not create those per-IP records in iphmx.com. Understanding the CES SPF record

A positive existence answer is an authorization signal, not the IP to which mail should be routed. Do not copy a returned loopback address into ip4: or use the expanded name as an SMTP destination. Avoid replacing the macro with a static list of current gateway IPs that nobody will maintain.

Publish SPF as TXT at the domain actually used in SMTP MAIL FROM, usually observable as the delivered Return-Path. If that owner already has SPF, insert the approved mechanism into the existing policy before its terminal all, preserving other legitimate senders and the existing final qualifier. Do not add a second SPF policy, paste a complete sample over the original, prepend - to the exists mechanism or substitute include:res.cisco.com. Cisco's merge instruction

There must be one applicable v=spf1 policy per owner. SPF permits at most ten evaluated DNS-dependent mechanisms/modifiers, including nested include and redirect paths. exists, a, mx and ptr consume this budget too; ip4, ip6 and all do not. Check the full evaluated path, not simply visible includes or DNS-packet counts. A policy that exceeds the limit yields permerror, not a partially valid allowlist. RFC 7208, sections 3.2 and 4.6.4

If the existing SPF policy uses redirect=, reconcile its authorizations and terminal behavior with the DNS owner before changing it. Any all mechanism makes redirect ignored regardless of their order. Do not append all automatically: preserve the redirected senders and approved policy semantics through a reviewed design. SPF all and redirect processing.

If envelope mail remains under a provider-controlled domain, its SPF pass may be unaligned. Adding an authorization at your visible From domain cannot change the identity the receiver checks. Record that condition explicitly and establish aligned DKIM rather than guessing a supported Return-Path rewrite.

Create and enable DKIM signing

Prepare a key and a domain profile

In the documented 16.5 GUI:

1. Open Mail Policies → Signing Keys → Add Key. Name and generate the signing key, then submit and commit.
2. Open Mail Policies → Signing Profiles → Add Profile. Choose DKIM, enter the intended signing domain and a unique selector, and associate the key. If outbound signing is already enabled, initially restrict Profile Users to a deliberately unused address in that domain, so this unfinished profile cannot sign production mail.
3. Review header/body canonicalization and signing coverage. Prefer whole-message protection; do not reduce signed body length merely to hide downstream modifications. Submit and commit this safely restricted new profile before returning to the profile list to use Generate. Keep it restricted until its public key is published and tested.
4. Use Generate in the profile's DNS Text Record column and publish the exact generated public TXT record.
5. Use Test Profile after public DNS resolves. Only after success assign the intended Profile Users, then enable DomainKeys/DKIM Signing on the intended outgoing RELAYED mail-flow policy and submit/commit.

The exact labels and policy must match your deployed version and route. Inbound DKIM verification is not outbound signing. Versioned DKIM configuration workflow

For new RSA keys, use 2048 bits where supported. Do not follow old prose describing 768-bit keys as secure. RFC 8301 prohibits signing with RSA keys below 1024 bits, recommends at least 2048 bits and disallows rsa-sha1; use rsa-sha256. Keep the private key on the authorized signing system, never in DNS, screenshots or a support worksheet. Current DKIM algorithm/key guidance

Make profile selection match the visible sender

Check DKIM Global Settings → Use From Header for DKIM Signing. Otherwise, a present Sender header normally drives profile matching. An unmatched sender can leave mail unsigned. Signing occurs after the gateway's own processing, but a later relay can still alter the message. In clusters, key and profile operations are linked, so confirm the configuration scope before editing either. AsyncOS signing behavior and global settings

This is particularly important for “send on behalf of” applications. Build separate acceptance cases with and without a Sender header, rather than assuming the successful staff-message profile also covers every application. Require the resulting signature's d= to align with the actual visible From, regardless of which header selected the profile.

If your approved scope includes gateway-generated notifications, ordinary RELAYED mail signing is not enough. Separately review Mail Policies → Signing Profiles → DKIM Global Settings → Edit Settings → DKIM Signing of System Generated Messages. The documented switch covers Spam Quarantine notifications, content-filter notifications, configuration messages and support requests. Obtain the gateway owner's approval for that additional scope before changing it, then submit and commit an approved change. Do not turn it on solely because staff email now signs. Test each actually used notification path with controlled recipients and the same intended-signature, unchanged-From and trusted DMARC checks below. System-generated signing controls

Bounce and delay messages are a separate optional scope. The documented control is Hard Bounce and Delay Warning Messages → Use Domain Key Signing for Bounce and Delay Messages on the bounce profile associated with the public listener. It requires the signing setup and matching bounce return address/profile users; it is not the system-generated-message switch above. Cisco recommends avoiding return-address changes on Cloud appliances. Coordinate any required change with the responsible service team instead of changing addresses to force a match, and validate only approved bounce/delay paths without generating uncontrolled bounce traffic. Bounce and delay signing

Do not enable an unfinished new profile on live traffic while its public key is unavailable. For an existing signer, stage a separate selector and constrain activation until publication is verified. An ordinary key addition should not become a wholesale key import: the versioned guide warns that importing keys replaces existing keys. Preserve unrelated signers.

Handle DNS names and delegation correctly

The DKIM owner follows this relationship:

SELECTOR._domainkey.SIGNING_DOMAIN

Use the selected profile's actual domain and selector. For a fictional owner outbound2026._domainkey.example.com, an editor that appends example.com expects outbound2026._domainkey; an FQDN-based editor expects the complete owner. Confirm the published name, not just the entry form.

For an illustrative issued owner outbound2026._domainkey.news.example.com, a suffix-appending editor for example.com uses outbound2026._domainkey.news; one for a separately delegated news.example.com zone uses outbound2026._domainkey. If _domainkey.news.example.com itself is delegated, use relative outbound2026 in that zone. A full-name field takes the complete issued owner. Replace the placeholder with the actual account selector, preserve existing NS delegations and active selectors, and publish with the actual authority rather than adding an inactive parent-zone copy. DNS zone boundaries.

The generated public key belongs in one logical TXT record. Long TXT values may be represented as adjacent quoted strings; DNS clients concatenate them. Do not split one key into competing TXT records, insert spaces inside its encoded p= value or create a new unrelated key to make a DNS checker turn green. DKIM public-key publication

If the owner lies beneath an existing NS delegation, edit the authoritative child zone or coordinate with its operator. If an established managed-DKIM setup uses a CNAME at the selector, do not add TXT beside it or erase it blindly. Confirm ownership, preserve other services and follow the approved delegation architecture. CNAMEs must remain DNS-only aliases, not proxied or flattened web records. DNS aliases and delegation

These alias controls apply only to an established managed-DKIM CNAME architecture, not to the direct TXT key generated by the native AsyncOS procedure. Where the issued authentication or return-path records require literal CNAME answers, use DNS-only aliases returning the exact targets, without an HTTP proxy or flattening hiding them. Turn the relevant per-record Flatten control off when available and ensure applicable zone settings preserve those aliases. Cloudflare documents that flatten-all cannot be overridden per record, apex CNAMEs are flattened by default, and same-zone targets are flattened regardless of that setting. These are conditional DNS-host behaviors, not assumed controls in every panel. If mandatory apex/same-zone behavior or a shared setting prevents the required answer, stop and coordinate a supported configuration with the DNS owner and sender. Do not blindly change the whole zone or remove an existing delegation. CNAME verification, flattening controls and limits.

Establish DMARC alignment

DMARC evaluates the visible From domain against a passing aligned SPF identity or a passing aligned DKIM identity. Under relaxed alignment, the organizational domain must match; strict alignment requires exact equality. A signature for example.com does not strictly align with From billing.example.com, although it can align under relaxed rules. Reply-To, display name and a successful relay login do not establish alignment. RFC 9989, identifier alignment

Keep any established DMARC policy and relevant parent policy intact. Adding Cisco is not a reason to downgrade p=reject to p=none. Where no effective policy exists, an approved monitoring policy at _dmarc.<from-domain> can precede enforcement, but inventory every legitimate sender first and assign someone to review the reports. Current RFC 9989 replaces RFC 7489; do not use pct as a new percentage-rollout control.

Only if no direct or applicable inherited DMARC policy exists, and the domain owner approves a monitoring plan after reviewing legitimate senders, a first TXT policy for fictional From domain example.com may be v=DMARC1; p=none at full owner _dmarc.example.com. The minimal value requests no reports; provision an approved reporting destination and review process before adding rua. Preserve established enforcement and authorized reports.

For a first policy at full owner _dmarc.example.com, a relative-name field in zone example.com takes _dmarc. For a deliberately approved child policy at _dmarc.news.example.com, use _dmarc.news in the parent zone or _dmarc in a separately delegated news.example.com zone. A full-name field takes the complete owner. These examples do not authorize overriding an inherited policy.

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 the policy domain is excepted; a different hostname alone does not make it external. Obtain the reporting operator's exact authorization instructions when required. This protocol check is separate from the domain owner's approval to share report data; agree access, retention and privacy. RFC 9990 section 4.

Reports contain operational metadata: restrict access and retain them deliberately. Do not add failure reporting without a separate privacy decision.

Run DNS and message acceptance checks

These commands are templates for the administrator, not completed tests. Replace all uppercase placeholders. Discover the authoritative zone for each owner separately, including delegated children:

dig +trace ENVELOPE_DOMAIN TXT
dig @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 CNAME SELECTOR._domainkey.SIGNING_DOMAIN
dig +short TXT _dmarc.FROM_DOMAIN

Expect one valid SPF policy with the issued allocation mechanism and a DKIM public key matching the chosen profile. If a CNAME exists, query the exact target for TXT and trace its authority if necessary. Compare authoritative and recursive-resolver answers to distinguish publication defects from cached data. A DNS lookup alone does not run the full SPF algorithm or verify a DKIM signature.

For SPF macro diagnosis, use a standards-aware SPF evaluator with the observed recipient-facing IP and envelope identity. If checking an expanded IPv4 query manually, replace %{i} with that actual IPv4 address and retain the complete issued suffix. An A response establishes that the exists mechanism matches; it does not prove the full policy is valid, alignment passes or delivery succeeds. Cisco macro explanation

Send an authorized message through each in-scope gateway route to a controlled external recipient. Correlate its timestamp/message identifier with gateway tracking, then record:

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. Receiver-result provenance

A DNS Test Profile success is insufficient. Likewise, DMARC passing through SPF alone does not commission this DKIM configuration. Test representative header/body modifications and delegated-sender cases, not just an uncomplicated staff message.

Troubleshoot without weakening authentication

A receiving-system reject or quarantine can also involve reputation or content. Preserve the exact SMTP response and receiving trace; do not claim that authentication success guarantees the inbox.

Rotate or recover safely

Treat rotation as a separate reviewed change. Create a different selector, publish its matching public key before using it, verify DNS, switch only the intended signing scope and prove a fresh received message passes. Keep the previous public selector available for queued or delayed messages. Cisco's dedicated ESA rotation guidance recommends at least one week before removing the old TXT record; confirm the supported cloud procedure and your own maximum mail-retention/queue window before cleanup. Cisco key-rotation guidance

If a change causes failures, use the captured configuration to restore the known-good signing profile and matching DNS, or pause the new route while investigating. Do not use “clear all,” replace every key through an import, change the cloud appliance's return addresses casually or delete unrelated selectors. Verify the rollback with the same external-message evidence, keeping the old and new keys clearly identified.