Define the outbound gateway scope
This guide uses the AsyncOS 16.0 General Deployment documentation for Cisco Secure Email Cloud Gateway, whose Email Authentication chapter is dated 3 October 2024. It is a version-bounded configuration and acceptance plan, not a claim about the latest release or an inspected tenant. The documented signing workflow creates a key, associates a domain profile, publishes DNS verification material and enables signing in the outbound policy. The described GUI path is Mail Policies, Mail Flow Policies, RELAYED, then DomainKeys/DKIM Signing, followed by submit and commit. Incoming verification is separate from outbound signing. A profile mismatch can leave a message unsigned. Cisco Email Authentication guide
That bounded workflow supplies an architectural starting point. It does not supply a tenant's selector, private key, outbound IP inventory or approved SPF authorization. The rest of this article is an original review method for connecting the documented workflow to protocol evidence. Before implementing it, the responsible administrator must confirm the actual gateway version, supported controls, change authority and message route. No gateway has been accessed and no key, policy or message has been created here.
Start with a route contract
Write down where the message originates and which system makes the final outward SMTP connection. Include any application relay, upstream mailbox system, gateway, downstream relay and recipient-facing egress. The purpose is to locate the point where signing and SPF authorization must be evaluated, not to collect every internal network address. Keep sensitive configuration in the organization's controlled change record rather than embedding it in a broadly shared article.
For each route, record the expected visible From domain, SMTP MAIL FROM domain and intended DKIM signing domain. These are different identities even when an organization deliberately makes them look similar. SPF evaluates the relevant SMTP identity and connecting address. DKIM verifies a signature associated with its signing domain. DMARC relates qualifying authenticated identifiers to the visible author domain. A gateway's presence in a route is not an authenticated identity in itself. RFC 7208, sections 2.3–2.4 RFC 6376, section 3.5 RFC 9989, section 4.4
The route contract should include exceptions: automated notices, delegated senders, applications with unusual headers and mail that bypasses the intended gateway. Do not accept a configuration based solely on one convenient staff message. Decide which distinct routes require evidence and which are explicitly outside the deployment. This produces a reviewable boundary rather than an unsupported statement that all corporate email is authenticated.
Separate key publication from signing acceptance
A DKIM deployment has at least two distinct responsibilities. The signer protects and uses the private key, while DNS makes the corresponding verification material discoverable. The signature supplies a selector and signing domain that identify the key location. Publishing a plausible-looking TXT value does not establish that the gateway possesses the matching key or signs the intended route. Conversely, enabling signing does not prove the public record is available to receivers. RFC 6376, sections 3.5 and 3.6.2.2
Use a change record that binds the approved signing domain, selector, public-key fingerprint or equivalent nonsecret identifier, DNS owner and intended policy to the same deployment. Never paste private keys into the worksheet. Obtain current cryptographic and key-management requirements from the supported implementation and organizational security policy instead of copying historical minimums from an older guide. This manuscript deliberately supplies no reusable key material or key-generation command.
Review the exact DNS owner independently of the editor display. A relative selector label may be expanded by a DNS interface, while a complete name may require different handling. Preserve the intended fully qualified name and logical TXT content before publication. Multiple strings within one TXT record are not the same thing as multiple competing resource records. A display split or quotation mark should be investigated in context rather than automatically treated as corruption. RFC 1035, sections 3.3.14 and 5.1
Review SPF at the real egress boundary
Do not invent a Cisco-wide SPF include based on the product name. The relevant authorization depends on the actual outbound infrastructure and envelope domain. The responsible operator should obtain current approved egress information, reconcile it with existing legitimate senders, and review the resulting complete policy. A hosted gateway, an upstream mailbox platform and an application can represent different authorization needs even when all are managed by the same team.
SPF must be published as TXT under the applicable domain. Multiple applicable SPF records produce an error rather than combining into a larger allowlist. The evaluation budget also applies to the recursively evaluated DNS-querying terms, not merely the number of include strings visible in the top-level policy. Review dependency behavior before adding another service and preserve a rollback plan that does not silently remove existing senders. RFC 7208, sections 3.1–3.3 and 4.6.4
A passing SPF result for a provider-controlled envelope domain is not necessarily aligned with the organization's visible From domain. Where a route relies on aligned DKIM, retain that choice explicitly. DMARC requires a qualifying aligned SPF or DKIM result, but a project or provider may impose additional prerequisites. Do not turn the protocol's alternative paths into permission to ignore the implementation's requirements. RFC 9989, section 4.4
Build an evidence sequence rather than a success screenshot
The proposed acceptance sequence has separate checkpoints for configuration intent, published DNS and actual received messages. First, confirm that the supported tenant configuration matches the approved route contract. Second, retain authorized DNS observations with owner name, type, logical value and observation time. Third, evaluate an approved message received outside the sending system, recording the relevant identifiers and authentication results without publishing private correspondence.
When evidence disagrees, diagnose the layer before changing policy. An unsigned message is a different problem from a signed message whose verification key cannot be found. A valid but unaligned signature differs from a signature invalidated by message modification. A DNS observation from an old cache differs from an incorrect authoritative record. These distinctions prevent a team from weakening DMARC to conceal an unresolved signing or routing issue. DKIM verification and DMARC alignment are related but separate assessments. RFC 6376, sections 3.5–3.6 RFC 9989, section 4.4
Fictional diagnosis: a route missing from the plan
In a fictional company, North Quay Parts, the messaging team prepares signing for ordinary correspondence. An accounts application still uses a different approved relay path. A reviewer sees a successful result for one staff message and proposes marking the entire domain complete. No actual company, test or outcome is represented by this scenario.
The review stops at the scope mismatch. The application route is added to the inventory, its envelope and author identities are documented, and its signing responsibility is assigned. The team does not guess that the application traverses the same gateway policy. It also avoids replacing SPF with a single-service example or changing DMARC merely to obtain a green indicator. Acceptance remains pending until each in-scope route has suitable authorized evidence.
Blank deployment acceptance worksheet
- Gateway product, version and applicable documentation date: ____.
- Configuration owner, DNS owner and release approver: ____.
- Message category and approved route through final egress: ____.
- Expected From, MAIL FROM and DKIM signing domains: ____.
- Supported policy/profile association and unresolved exceptions: ____.
- Selector and public verification record reference, excluding secrets: ____.
- Existing SPF senders, proposed authorization and dependency review: ____.
- Intended DNS owner, current authoritative evidence and observation time: ____.
- Actual approved received-message evidence and alignment assessment: ____.
- Rollback conditions, unresolved discrepancies and approval decision: ____.
The worksheet is unfilled and no operational step has been executed. Original implementation evidence, human review, current source applicability, production routes, visual/accessibility checks and owner release remain open. Authentication acceptance would still not guarantee delivery, message safety or the legitimacy of a business request. RFC 9989, section 2.4