Scope and prerequisites
Trellix is a portfolio, not one email route. This guide covers the Email Security Cloud custom DKIM policy documented by Trellix. It does not establish equivalent steps for an appliance or another product. Confirm outbound mail traverses this service, identify its domain policy owner and export existing signing records. Current tenant-specific outbound SPF instructions must be obtained separately; no universal SPF include is asserted here.
Configure the outbound DKIM policy
Under Configuration > Policies, create an Outbound DKIM Policy. Manage DKIM Configuration and generate keys. Publish the account-provided CNAME targets or public-key TXT data, then validate both primary and secondary keys. Associate the policy under the domain or domain group's outbound policies and save. Custom signing supplements Trellix's standard signature. US Government tenants lack hostname copying and use TXT publication. The source's TXT examples omit the underscore used in its CNAME examples; resolve the full TXT owner with tenant output or support before proceeding. See Custom DKIM policies below.
Original dual-signature acceptance design
Use an external test message to enumerate every signature, not just the first DKIM-Signature header. Record d=, s= and receiver result independently. A passing provider signature is insufficient if its signing domain does not align with your visible From. A failing unrelated signature does not negate another aligned passing signature. The receiver's DMARC result and its evaluated identities are the acceptance evidence.
For a fictional visible From alerts.example.org, imagine one signature from an unrelated service domain and another from alerts.example.org. Only the second could provide exact alignment. This is an invented reasoning specimen, not Trellix header output. The worksheet deliberately leaves actual selectors, domains and results empty.
Plan key maintenance before rotating
Document which selector is active, which is standby, who can regenerate it and whether DNS is delegated or manually managed. Manual TXT publication creates a separate DNS update dependency: after a replacement public key is published, verify it before using the corresponding signer. Do not expose private key material in a ticket or worksheet.
A useful failure test is a policy whose keys validate but which is not attached to the intended domain. Capture the association and a message from that exact domain to distinguish DNS readiness from policy application. Avoid treating a successful test from a neighboring domain as proof for the whole domain group. During recovery, restore the prior validated association or signing state with the mail owner; do not delete both keys as a diagnostic shortcut.
Prove the identity at the receiver
Use a controlled external mailbox and send through the production workflow, with harmless content and no customer data. Save the raw message, timestamp and the receiving system's Authentication-Results. Ignore authentication assertions inserted by an untrusted sender. Record the visible From domain, Return-Path or authenticated envelope identity, and every DKIM d= and s= pair. A display name or Reply-To address is not the DMARC identity.
SPF pass authorizes the connecting server for the evaluated envelope identity. DKIM pass validates a signature for its signing domain. DMARC needs a passing method whose domain aligns with the visible From: strict alignment requires the same domain; relaxed alignment permits the applicable organizational-domain relationship. A provider-owned signature can pass without authenticating your visible From. One passing aligned DKIM signature can satisfy DMARC even when another signature fails. These protocol rules come from RFC 7208, RFC 6376 and RFC 9989, listed below.
Check authoritative DNS before diagnosing caches. Ask an authoritative server for the exact name and type, then compare a recursive resolver after its cached lifetime. For DKIM, follow any CNAME to its public-key TXT response. Never publish a private key. Keep one SPF policy at each evaluated name and check the ten DNS-lookup-causing-term limit across nested includes. Do not replace a shared SPF policy with a provider example.
Recovery and acceptance
Pause the affected workflow if tests show a new regression. Compare the changed record with the saved version and undo only that change after checking other senders. Recheck DNS and resend after recovery; reverting a value does not flush every resolver immediately. Keep old DKIM verification records available while previously signed messages may still be in transit, unless a security incident requires revocation.
Accept the change only when DNS, application state and a real received message agree. Record the flow owner, evidence timestamp and next review trigger. Inbox placement alone is not proof of authentication, and successful authentication does not guarantee inbox placement. Do not tighten a shared domain's DMARC policy on the strength of one provider's test. Inventory the other legitimate sources first.
Locate the missing association before rotating keys
Written case TR-01 assumes both generated selectors show Verified for example.org, but the intended outbound domain has no association to the new custom DKIM policy. A received teaching specimen has From alerts@example.org and only an unrelated provider-domain signature; SPF and any other signatures remain unknown. The mail-policy owner should inspect the domain’s outbound association and its actual route, not regenerate both keys. No complete DMARC outcome follows from this partial specimen. The identifiers are illustrative and no tenant, key-generation action, policy change or message was used.
Preserve the enforcement boundary
RFC 9989 Section 7.4 requires valid DKIM, not SPF alone, for domains publishing p=reject, and warns about indirect-mail and mailing-list interoperability. A single successful direct-message test is not proof that every legitimate route is ready for stronger policy. Keep existing approved protection while diagnosing the actual gap; any policy change needs its own decision.