Source review dated 8 November 2026. Provider settings and acceptance exercises below are documentary guidance, not executed account, DNS or message tests.
Draw the routing path before editing DNS
mxHERO can change message content while processing mail, so the routing architecture determines which system performs final delivery and signing. Document the path for inbound and outbound traffic separately. Mark where an attachment or body is transformed, where a new signature is applied and which server connects to the final recipient. A provider name in the route is not enough to determine the required authentication changes. mxHERO routing architectures.
The first-party authentication guide distinguishes direct outbound delivery from relaying back through the mail platform. For direct delivery, it describes mxHERO SPF authorization and mxHERO DKIM signing; for a Google SMTP relay return path, it describes Google signing on final delivery. Confirm that the account matches the documented architecture before implementing either branch. mxHERO SPF DKIM and DMARC.
Preserve existing connectors, routing rules and sender permissions. Assign one owner for the mail platform and another for DNS if responsibilities differ. The routing guide distinguishes Email Flow rules from User Mailboxes rules operating on already-stored mail, which require no mail-flow rerouting. For routed mail, the domain Server remains required even on outbound-only deployments. Loopback exclusions must inspect X-mxHero-Server, not the removed X-mxHero-Transport-Agent header. Agree on the smallest controlled test group and the rollback route. Do not apply an inbound design to outbound mail or assume that every alias follows the primary domain's configuration.
Authorize the actual outbound delivery path
The mxHERO authentication guide specifies include:_spf.mxhero.com and warns against omitting _spf.. Merge the confirmed authorization into the existing policy rather than publishing a second SPF policy. Apply RFC7208 §4.6.4’s ten evaluated DNS-causing-term limit, including nested evaluation, to the complete dependency path and ensure that the policy being edited belongs to the identity the receiver actually evaluates. A dashboard check for an include does not prove the message has an aligned envelope identity. mxHERO SPF DKIM and DMARC.
Review every affected domain and alias in the approved routing plan. Do not broaden scope automatically to dormant domains. Compare actual direct-delivery results with the configured permissions, especially if some messages return through a different platform. Where the provider wording appears broader than the architecture requires, obtain clarification instead of removing or adding authorization by guesswork.
Activate the signing path after content changes
For direct outbound delivery, the guide describes creating DKIM in Organization and domains, publishing the displayed TXT record and verifying it before signing begins. Use the generated record for the selected domain or alias. Do not treat the initial selector convention as permission to invent a subsequent selector, and do not paste an example public key from another tenant. mxHERO SPF DKIM and DMARC.
A signature applied before mxHERO changes covered content can fail after transformation. The acceptance test must therefore contain the type of processing the organization intends to use. Compare a message that exercises the relevant rule with an ordinary message. Confirm that the final delivered copy carries a valid aligned signature, regardless of whether the signer is mxHERO or the final platform relay.
Only one unverified key may exist for a domain at a time, according to the current guide. Review rotation as a coordinated change rather than simply deleting a DNS record. Publish and verify the new key through the supported process, inspect a fresh message for the new selector, and retire obsolete DNS only with awareness of queued mail and cache behavior. Do not remove the active signing key as an informal test; the provider guide says removing a verified key stops signing.
Treat ARC trust as a security decision
The first-party guide documents mxHERO ARC sealing and a Microsoft 365 trusted-sealer configuration. ARC can convey prior authentication observations across an intermediary, but a valid chain is not an unconditional delivery guarantee and does not replace customer-domain signing for every recipient. Trust depends on the receiving system's policy and the intermediary's behavior. Confirm the exact inbound or loopback architecture before proposing a trust change. mxHERO SPF DKIM and DMARC.
Changes to trusted sealers, connectors and allow lists are security-sensitive operational decisions. This article does not execute them. Preserve existing trusted-sealer entries and obtain the appropriate administrator approval before changing trust. In particular, do not copy a command that replaces an entire list without first inspecting that list. Avoid broad spam-filter bypasses as a substitute for correct routing and authentication.
Compare direct and relay acceptance branches
The following text diagrams show the documented architecture choices, not observed tenant routes. Mark the enabled branch before applying DNS or connector changes. mxHERO routing architectures.
Direct branch: source platform → mxHERO transformation → mxHERO final delivery → controlled recipient.
Google relay branch: source platform → mxHERO transformation → Google SMTP relay and final signing → controlled recipient.
- Branch: Direct outbound; Expected final signing responsibility: mxHERO domain configuration verified before signing; Acceptance test: Process a harmless attachment; inspect final aligned signature and observed envelope
- Branch: Google SMTP relay return; Expected final signing responsibility: Google signing on final delivery in this documented architecture; Acceptance test: Confirm return through Google and inspect the signature after transformation
- Branch: Inbound or Microsoft 365 loopback; Expected final signing responsibility: Resolve the separate documented routing and trust design; Acceptance test: Do not apply either outbound branch by analogy
The first two expectations come from the provider's authentication guide. They are test expectations, not guarantees that this account is configured accordingly.
Copy this acceptance row once for ordinary mail, transformed mail, each affected alias and replies:
- Branch and rule exercised: ______; transformation observed: ______.
- From and envelope domains: ______; final connecting IP: ______.
- Upstream DKIM d=/s=/result: ______; final DKIM d=/s=/result: ______.
- Trusted receiver DMARC result and aligned path: ______.
- Connector or routing evidence and UTC times: ______; verdict and owner: ______.
Worked transformation failure
This is a fictional comparison, not a live header capture. An ordinary message from example.com passes DKIM with d=example.com. A second message takes the direct branch and has an attachment replaced, but the received copy contains only the upstream signature and that signature fails. The comparison points to post-signing modification and the absent final aligned signature. Check whether the transformed copy reached the intended mxHERO signing path and whether its generated key is verified. Do not infer that every DKIM failure is transformation-related. DKIM verification.
For the relay branch, investigate the return route and final Google signer instead of assuming an mxHERO selector must appear. If a provider-owned envelope passes SPF but does not align, a passing aligned DKIM signature can still satisfy DMARC. A passing ARC chain alone is not the same observation. DMARC specification.
Recover the selected branch without broadening trust
Preserve the exact connectors, routing conditions, affected aliases and DNS RRsets before the change. Name the operator who can stop the transformation rule for the controlled group. If the transformed test fails while ordinary mail works, revert the scoped processing/routing change first, then verify a fresh transformed or bypassed test as appropriate. Preserve unrelated SPF permissions and trusted-sealer entries. Check the actual SPF identity and full dependency path before changing authorization. SPF processing.
Retire an old public key only under the approved rotation plan, considering queued messages. Recovery is complete only after the selected route has been retested; a restored console setting is insufficient. No tenant, live DNS or message evidence was collected here. Visual inspection and human SME approval remain separate pending gates.