Trellix SPF, DKIM and DMARC setup, step by step

For Trellix Email Security Cloud, formerly associated with FireEye Email Threat Prevention, use the outbound SPF include for your account's commercial or US Government environment and the dedicated custom DKIM policy workflow. A usable public key is only one prerequisite: the policy must apply to the intended outbound domain, and a received message must show the intended branded dkim=pass, alignment and dmarc=pass. This is not an appliance or portfolio-wide Trellix recipe. Outbound mail flow, custom DKIM policies.

On this page: Applicability · SPF · Custom DKIM · DNS checks · DMARC · Message checks · Rotation · Troubleshooting · FAQs

Confirm the cloud route and custom DKIM availability

Start with an already approved outbound Email Security Cloud route. Identify the tenant, service region, licensing, administrator, From domains, upstream mail server and downstream relay. Trellix's outbound guide specifies licensed Inline with Hygiene use, prior domain provisioning and outbound policy/routing prerequisites. It excludes mass outbound scanning and intra-organization mail from this route. Do not reroute newsletters or internal mail merely to obtain a signature. Supported outbound scope.

A Cloud product subscription alone does not establish that a particular message traverses this signer. API-only security scanning, inbound filtering and an Email Security appliance are separate deployment questions. Microsoft 365 or Gmail may be upstream systems, not necessarily the final signing hop.

Resolve the documentation inconsistency before using an unavailable control. The dedicated custom-DKIM page documents customer-generated policy keys and domain association. The separate Message analysis policies page still states that custom keys per domain are unsupported in its standard-signing discussion. This guide follows the dedicated policy workflow only when your tenant exposes it or Trellix confirms it. The standard Hygiene Settings DKIM checkbox is not evidence that branded custom signing is active. If the dedicated controls are missing, obtain tenant-specific confirmation rather than assume capability from this article. Standard signing discussion, dedicated custom policy.

Before changing authentication, save:

• Current domain and domain-group policy associations, including any inheritance or exceptions.
• Actual envelope/MAIL FROM domain, intended visible From domain and current DKIM identities.
• Both current selector records, their types, values, TTLs and key-management owners.
• The authoritative zone for each DNS owner, existing SPF and applicable DMARC policy.
• A recovery plan, approved test recipients and the responsible mail-policy and DNS administrators.

The existing outbound domain-identification token and envelope identity participate in policy selection. A missing token can cause rejection before message verification is possible. Have the route owner confirm the established integration; never publish that token in DNS or upload it with headers to a public analyzer. This guide does not generate, expose or replace it. Domain identification prerequisites.

Authorize the correct outbound environment with SPF

The current general outbound guide distinguishes these supported include mechanisms:

Use the account's actual environment, not a regional hostname guessed from its brand. The general guide provides separate examples for each. A separate Inline with Hygiene table lists the US Government policy domain correctly but repeats the commercial include in its example column; reconcile account instructions rather than copying that conflicting cell. General outbound SPF instructions, integration table.

SPF authenticates the SMTP MAIL FROM, not the displayed From or Reply-To. Determine which owner is evaluated on the actual outbound route. A parent-domain SPF policy does not automatically cover a subdomain. An SPF pass for a different organizational domain does not establish alignment for your visible From.

Keep one SPF TXT policy per owner. Merge the required mechanism while preserving approved senders and the existing final qualifier. Do not install Trellix's single-service example over a shared corporate policy. This fictional commercial-account merge illustrates the operation only; the reserved address is not a Trellix IP:

Before: v=spf1 ip4:192.0.2.45 -all
After: v=spf1 ip4:192.0.2.45 include:_spf.fireeyecloud.com -all

For a US Government account, use its documented mechanism instead; do not add both simply to avoid choosing. A policy using redirect= needs an evaluation-aware change, not a blind edit. See SPF merge guidance.

Evaluate the complete policy against the 10 DNS-lookup-causing-term limit, including nested evaluations. include, a, mx, ptr, exists and redirect consume that budget; ip4, ip6 and all do not. The rule is not “10 includes” or “10 packets.” Separate mx/ptr address-query bounds and the recommended two-void-lookup limit also matter. Do not flatten provider IPs manually as a quick fix: a static copy can become stale when infrastructure changes. SPF evaluation limits, stale flattened SPF.

Create and activate the custom DKIM policy

For a tenant exposing the supported controls:

1. In Configuration → Policies, create an Outbound DKIM Policy and name it.
2. Under DKIM Configuration → Manage, generate the key pair. Select 2048 bits unless a documented requirement dictates otherwise.
3. Publish the issued DNS instructions for both selectors. Commercial tenants can use managed CNAMEs; manual TXT uses copied public keys. US Government tenants must use TXT because hostname copying is unavailable.
4. Validate each key against the intended domain and require both to verify.
5. Select the domain or group, open Policies - Outbound → DKIM Configuration, choose the policy and finish with OK, then Save.

The primary key signs mail. Dedicated configuration procedure.

For the documented CNAME branch, retain the issued targets for trellix1._domainkey.YOUR_DOMAIN and trellix2._domainkey.YOUR_DOMAIN. Targets are account-generated under fireeyecloud.com; never derive them from the policy name or copy another tenant's values.

TXT publication has an explicit stop condition. The provider's TXT examples omit the underscore in _domainkey, unlike its CNAME examples. Obtain the exact fully qualified TXT owners and public values from current tenant output or Trellix support before publishing. A DKIM verifier queries the underscore-bearing namespace defined by the protocol; do not guess how an inconsistent example should be corrected for the account. DKIM namespace.

For each key, record the complete owner, type, public value/target, signing domain, policy and intended domain association. Public-key material alone is safe to publish; private keys and route-identification tokens are not. Do not paste public-key text into a CNAME or put both a CNAME and TXT record at the same owner.

If the policy covers a group, use a separate acceptance row for every intended From domain. One valid domain does not prove the expected association or signing identity for its neighbors. If these names already serve another sender, resolve the collision with the owners before changing records.

Verify DNS owners and both key paths

A full owner such as trellix1._domainkey.mail.example.com normally becomes trellix1._domainkey.mail inside the example.com zone, or trellix1._domainkey inside a separately delegated mail.example.com zone. Determine where the authoritative data lives before entering relative names. Avoid a duplicated suffix introduced by the DNS editor.

CNAME records must remain visible as aliases. Where applicable, set authentication CNAMEs to DNS only and disable per-record or all-CNAME flattening that conceals their targets. Check delegated nameservers rather than changing an inactive parent copy. Never remove an NS delegation or alter unrelated zone settings simply to satisfy a checker. CNAME verification and delegation.

These commands are for the reader to run after approval. Substitute the actual zone, authoritative server, envelope and issued owner names. DKIM_TARGET is copied from the observed/issued CNAME, not guessed. For TXT-only publication, omit the CNAME-target step and check the complete public TXT value at each owner.

ZONE='example.com'
AUTH_NS='ns1.dns-host.example'
MAIL_FROM_DOMAIN='example.com'
KEY_ONE='trellix1._domainkey.example.com'
KEY_TWO='trellix2._domainkey.example.com'
DKIM_TARGET='ACTUAL_GENERATED_TARGET.fireeyecloud.com'

dig +short NS "$ZONE"
dig @"$AUTH_NS" "$MAIL_FROM_DOMAIN" TXT +norecurse
dig @"$AUTH_NS" "$KEY_ONE" CNAME +norecurse
dig @"$AUTH_NS" "$KEY_TWO" CNAME +norecurse
dig "$DKIM_TARGET" TXT
dig @"$AUTH_NS" "$KEY_ONE" TXT +norecurse
dig @"$AUTH_NS" "$KEY_TWO" TXT +norecurse
dig "$KEY_ONE" TXT
dig "$KEY_TWO" TXT

Confirm the closest enclosing authority through the DNS administrator's zone/delegation evidence. An empty NS answer at an undelegated subdomain does not mean its records are absent. Query all authoritative servers if inconsistent, then compare a recursive resolver after applicable caches expire.

Acceptance requires the two exact aliases and usable public-key TXT data at their targets, or the two complete issued TXT keys for that branch. For each selector, distinguish a missing record, NXDOMAIN, SERVFAIL, a wrong target and an outdated cached key. Multiple quoted strings in one TXT record may form one long key; separate competing TXT key records are not equivalent. DKIM record representation.

Re-run the provider validation after DNS is correct. Two green verification states are DNS readiness, not proof that the right domain is using the policy. The received-message check below is a separate acceptance gate.

Check alignment without weakening DMARC

Compare the actual visible From with both the SPF-authenticated envelope domain and each passing DKIM d=. Relaxed alignment uses the applicable organizational-domain relationship; strict aspf=s or adkim=s requires an exact domain match for that mechanism. One aligned passing signature can supply DMARC even if another signature fails. Provider-domain authentication without alignment is insufficient. RFC 9989 alignment.

Preserve the policy already applying to the From domain. Query _dmarc.FROM_DOMAIN and investigate applicable organizational/parent policy if it has no direct record. Current RFC 9989 specifies DNS-tree-walk discovery, obsoletes RFC 7489 and removes pct. Do not introduce an old percentage-rollout template.

Add a first policy only after checking inheritance

When neither a direct nor an inherited policy applies, the policy owner may approve the following initial TXT record. It requests no DMARC-based change to message handling; it cannot guarantee delivery and is not a repair for the Trellix route.

Type: TXT
Full owner: _dmarc.example.com
Value: v=DMARC1; p=none

Use the actual From domain instead of the example. Enter its owner according to the authoritative zone:

An existing policy is an edit-and-review case, not permission to add another DMARC record or downgrade direct or inherited enforcement. Before stronger enforcement, inventory other senders and indirect routes. Section 7.4 of RFC 9989 requires valid DKIM for domains using p=reject, not an SPF-only dependency, and warns about mailing-list interoperability.

The bare policy does not request reports. For monitoring, append ; rua=mailto:YOUR_ACTUAL_AUTHORIZED_REPORT_ADDRESS only after substituting a real approved recipient. Confirm external-destination authorization before expecting that recipient to receive reports, and use the checks below. RFC 9990 section 4.

Use only an approved aggregate-report destination. For external rua reporting, verify the receiver's authorization record using the real policy domain and report destination. This fictional lookup illustrates the DNS owner for example.com reporting to reports@collector.example.net:

dig TXT example.com._report._dmarc.collector.example.net

The external reporting service owns that authorization, including any supported wildcard. Do not invent a mailbox or publish the authorization in the wrong zone. Limit report access and retention; do not enable message-specific failure reports without considering their data exposure. RFC 9990 external reporting.

Accept the intended signature, not just any DKIM pass

After account and DNS validation, arrange an approved harmless message through the exact established outbound route to a controlled external mailbox. Test each affected domain and routing exception separately. No test has been sent for this article.

Open the receiver's raw message. Record visible From, evaluated SMTP MAIL FROM, connecting IP, every DKIM d=/s= pair, timestamp and message reference. Identify the trusted receiving system's Authentication-Results using its documented authserv-id and routing trace. Do not trust an arbitrary header merely because it says pass; results outside the receiver's trust boundary may be forged. RFC 8601, trusted header interpretation.

Keep the evidence in a restricted location and redact the domain-identification token, recipient information and message content before sharing diagnostic extracts.

Trellix's standard signature and a custom signature can coexist. Enumerate all signatures rather than inspecting only the first. An SPF-only DMARC pass or a valid unaligned standard signature does not establish success of this custom-DKIM task. A failing upstream signature does not negate a different aligned passing signature, but the failure may still identify a route worth repairing.

For example, a fictional message from alerts@example.com has only a valid signature from an unrelated provider domain. That is not evidence of branded DKIM activation, even if SPF happens to make DMARC pass. Inspect policy selection and the intended custom signature before regenerating DNS keys. This is a diagnosis pattern, not captured Trellix output.

Rotate with a verified standby and a recovery plan

The policy's Regenerate Key and Rotate Keys controls are distinct. Rotation promotes the secondary selector; manual TXT publication requires corresponding DNS maintenance. Trellix recommends at least a week between further regeneration or rotation. Key maintenance.

Before a planned change, identify the currently signing selector and the standby. Confirm which key will change in the actual interface. Publish and validate any replacement public value before using its signer, and compare both authoritative and recursive answers. Do not rely solely on a short portal wait or delete both records as a reset.

Keep the old verification path available for already-signed queued messages for the organization's retention window, except where a compromised key requires prompt revocation. After switching, send a new approved message and verify the newly active selector, branded alignment and DMARC result. A rotation is incomplete if only the policy screen changed.

For regression recovery, the mail owner should restore the last known-good association or signing state and the specific changed public record where safe. Keep the rest of the domain's SPF, DKIM and DMARC configuration intact. Reversion still has cache effects, so recheck DNS and messages. Do not bypass scanning or weaken authentication as an unreviewed workaround.

Troubleshooting by failed layer

A direct-delivery success does not cover every forwarding chain. Changes to the connecting server can disrupt SPF, and content modifications can disrupt DKIM. Record those as separate cases. A DMARC pass also does not guarantee inbox placement or bypass other recipient controls.

Documentation review and testing boundary

This is a documentary setup and verification guide, not an account, DNS or delivery test. No policy was created, token generated, key rotated, DNS record modified, message sent or website published. Tenant capability, exact issued values, domain association and received authentication remain checks for your authorized administrators.