Provider documentation checked on 8 November 2026. Account-generated values, entitlements and current support remain deployment prerequisites.
Match documentation to the deployed service
The current documentation at docs.trendmicro.com labels this service TrendAI Email Security. This guide covers its outbound DKIM signing screen, not every Trend Micro gateway product. Confirm the managed domain and outbound route before using the procedure. Save the prior signing settings and DNS records. No service account or live message was inspected for this article.
Configure outbound signing
References: RFC 6376 §3.6.2.
Open Outbound Protection > Domain-based Authentication > DomainKeys Identified Mail (DKIM) Signing and add the managed sender domain. Enable signing, choose the SDID, retain the supplied selector and generate a key pair. Publish the generated TXT name and public value. The configured wait period starts after DNS discovery. The empty-envelope option attempts to derive the sender domain from header From. The separate header-sender option applies when both the envelope and header sender addresses belong to your account. Review those conditions against your traffic; they are not permission to sign arbitrary external From addresses. Complete the signing settings and add the configuration. Consult the current provider source below for advanced controls and long TXT-string handling.
Original exceptional-message test design
References: RFC 7208 §2.4, RFC 9989 §4.4.
Create separate cases for an ordinary outbound message, an automatic response with an empty envelope sender and a flow whose header From differs from its envelope domain. Do not manufacture a bounce to an uninvolved recipient. Use a controlled test environment or an authorized simulation with harmless recipients. Record which case was actually exercised; an unexecuted case stays unverified.
For every case, collect the actual From, envelope status, SDID represented by d=, selector and trusted receiver results. Empty-envelope mail requires special interpretation of the SPF identity; do not copy the ordinary-message conclusion into that row. A signer's ability to use a header identity does not establish that your selected account and domains meet the option's conditions.
Protect the signature through the route
References: RFC 6376 §3.4.5, RFC 6376 §5.4.
Review downstream components that can alter content after signing, including footers, attachment processing and encryption. An authentication failure after a later modification is not automatically a DNS problem. Compare the route and message transformations before regenerating keys. Keep the same harmless test content where practical so differences remain interpretable.
Inspect advanced settings with a security reviewer. DKIM’s body-length tag can leave part of a message outside the signature; the documented Unlimited setting signs the entire body. A successful test should not hide that configuration decision. Review header selection and oversigning as well: the provider can oversign all configured signed headers to bind an additional occurrence, reducing header-insertion ambiguity. Relaxed canonicalization tolerates specified whitespace and formatting changes, not arbitrary content edits. Validate the complete public key at the authoritative owner name, not merely a truncated dashboard preview. If publication uses multiple TXT strings, they must be parts of one logical key record rather than independent keys.
Acceptance requires route-specific evidence
A green key check and elapsed wait period do not establish a passing aligned signature at an external receiver. Require a received-message result for each enabled exceptional mode, or record that mode as untested and do not depend on it. Preserve the prior working route while resolving a new failure rather than broadly reducing the domain's DMARC protection.
Prove the identity at the receiver
References: RFC 9989 §4.4, RFC 9989 §5.3.5, RFC 7208 §4.6.4.
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.