This guide covers MailMarshal/SEG 8.0 and later on-premises signing, not the separate Cloud product. A DNS key without an enabled signing rule does not authenticate outgoing mail. Inventory local domains, processing nodes and any downstream gateway that modifies signed content before selecting the change window.
Configure the domain and signing rule
In the Management Console, open the local domain properties and its DKIM tab. Add a unique selector, generate the key, save it and copy the complete DNS Record output. The current guide describes 2048-bit generation by default. Publish its TXT record at the indicated selector name; check the actual answer for whitespace damage or truncation. Enable the key only after DNS is available. Then enable a Content Analysis rule with Apply DKIM Signature. Scope that rule to intended outbound traffic, not arbitrary inbound messages. MailMarshal configuration reference
Check both the DNS used by MailMarshal and public resolution. The current guide describes an additional public query from the Array Manager, using Google DNS 8.8.8.8 by default; confirm the configured server and product version rather than assuming the delivery resolver is the only check. Split DNS can otherwise make an externally valid record fail local validation. For key replication errors, the vendor identifies the Windows CNG Key Isolation service on the Array Manager and processing servers. Investigate that dependency before replacing a working public key. Follow your change process for restarts; this guide does not authorize service disruption.
Verify DNS and a real receiving result
Before changing outbound gateway rules, export the existing DNS values, record the approved diff and name the rollback owner. Confirm whether the DNS editor expects a relative label or a fully qualified name; doubling the domain suffix creates a record that no intended verifier will find. Query the actual owner name after saving, including any CNAME target, rather than relying on the editor's success banner.
SPF must remain one policy at the relevant domain and stay within the DNS-querying-term limits in RFC 7208. Adding an include does not itself establish alignment. Under RFC 9989, DMARC passes when at least one successful SPF or DKIM result aligns with the visible From domain under the applicable mode. Do not require both mechanisms to align as a condition imposed by the standard, and do not mistake a provider-domain pass for an aligned customer-domain pass.
Send a message that actually traverses the selected Content Analysis rule to a mailbox you control. Save the receiving system's trusted authentication results, visible From, envelope identity, DKIM d= and s= values, timestamp and provider status. A DNS lookup only shows the available key; RFC 6376 verification also evaluates the signature over the received message. Use non-sensitive content and avoid exposing full customer messages to public checkers.
Use a bounded acceptance and rollback decision
An illustrative acceptance case is a message from alerts@example.com with a valid signature using d=example.com. That exact domain match supports DKIM alignment in either mode. A valid signature using only d=vendor.example.net does not align with example.com; without aligned SPF, that sample fails the DMARC acceptance test. These are reasoning examples, not observed Trustwave MailMarshal results.
If the test fails, separate missing DNS, wrong selector, inactive provider configuration, unexpected routing and message modification before making another change. Retest the same workflow after each approved correction. Do not weaken the whole domain's DMARC policy to hide a single sender problem. Where rollback is needed, restore the approved prior routing or sender configuration and retain key records while queued signed messages still need them. Keep the test evidence and unresolved exceptions with the domain inventory. No tenant access, DNS change or real sending was performed in preparing this guide.
Distinguish key availability from rule selection
Written case MM-01 assumes selector gateway1 is enabled for example.org and its public key is available, but the affected outbound flow does not match the Content Analysis rule containing Apply DKIM Signature. Its intended From is alerts@example.org; receiver results and emitted signatures are unknown. The rule owner should inspect routing and conditions before replacing a key or restarting services. If replication logs show a separate fault, investigate that documented dependency through an approved change, not by treating every unsigned message as replication failure. No gateway, Windows service, key or mail flow was changed.
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.