For an already-provisioned EntrustedMail outbound encryption-gateway domain, the public CareDesk instructions specify include:spf.entrustedmail.net for SPF and a DKIM CNAME from select-em1._domainkey to select-em1._domainkey.entrustedmail.net. Confirm that these instructions apply to your deployed domain, merge the SPF authorization without losing existing senders, and publish the alias at the correct full signing-domain owner. Use EntrustedMail's implementation assistance when signing status is uncertain, then verify a message that actually traversed the gateway.
This is not a DNS-only onboarding guide. It does not configure a new Microsoft 365 or Google Workspace connector, nor does it describe EntrustedMail's separate multi-sender authentication-management offering. The gateway signs and delivers messages only on its configured route. A public alias or a green DNS check cannot prove that your domain has been provisioned or that your delivered message has aligned DKIM.
The official DKIM article was modified March 25, 2020; the SPF article on May 31, 2021. Their age makes current domain-specific confirmation important. No account, DNS, gateway or message tests were performed for this guide.
Confirm the product and deployed domain first
Identify the EntrustedMail outbound encryption gateway already assigned to your organization, the approved sender domain and the mail-flow rule or equivalent route that sends messages through it. Use your existing deployment records and provider confirmation. Do not assume a subscription to authentication management provisions the encryption gateway or makes this shared CNAME applicable to every external sending platform.
EntrustedMail's Access Portal release notes describe Customer Administrators requesting new domains through a service request and receiving notification when deployment is complete and ready to accept mail. If your domain has not reached that state, complete the provider's approved deployment process first. Adding DNS alone is not a substitute.
The Microsoft 365 gateway guide, depends on assigned welcome-message smart hosts, a private token, TLS requirements, connector validation and an enabled mail-flow rule. Those are consequential routing and security settings outside this article. Do not copy another customer's values, disable TLS or change connectors merely to repair a DNS warning.
Before making an authorized change, inventory existing SPF policies, DKIM selectors and delegations, direct/inherited DMARC policies, approved reporting recipients and the current gateway route. Preserve a recoverable record of the existing configuration. DNS access must cover the authoritative zone, not just a parent-zone editor that happens to be available.
1. Confirm DKIM implementation with EntrustedMail
The DKIM article explicitly offers implementation help through a support ticket. The portal release notes document New Service Request, entering the issue and submitting it. Use the current equivalent support route if the historical interface has changed; no universal self-service DKIM toggle is established by the public documentation.
Ask EntrustedMail to confirm:
- That the exact domain is provisioned for the existing outbound gateway.
- That the documented
select-em1alias applies to that domain today. - The complete owner, type, target and expected signing
d=ands=values. - Whether provider-side DKIM implementation is already complete or requires assistance, and how completion will be confirmed.
- Which approved encrypted and unencrypted outbound paths should be tested.
Share only necessary configuration information and sanitized evidence through the approved support channel. Never send passwords, gateway tokens or private keys in a public diagnostic.
The official wording distinguishes having implemented DKIM from merely publishing an alias. Preserve that distinction: obtain confirmation of the required provider-side state before treating the domain as ready. Do not infer activation solely from the DNS Health Check screenshot's statement that EntrustedMail signs outbound messages.
2. Update the single SPF policy at the correct owner
The gateway's documented authorization component is:
include:spf.entrustedmail.net
SPF evaluates the actual SMTP MAIL FROM domain, or HELO in the relevant empty-envelope case. It does not automatically evaluate the visible From domain. Reconcile the current gateway instructions with the actual envelope identity and confirm that you control the evaluated owner before editing it. Do not invent a return-path subdomain or attempt to replace a provider-owned SPF policy.
Read the existing TXT records. Add the gateway mechanism to the one existing v=spf1 policy while preserving all legitimate senders, intended mechanism order and the approved terminal qualifier. Do not publish a second complete SPF policy. The official article's old Microsoft include is an example of another sender, not a current Microsoft recipe to copy. See why multiple SPF records fail.
Check the complete evaluated SPF chain against the maximum ten DNS-dependent terms, including nested processing. Ten visible includes is not the limit's meaning. Preserve any deliberate redirect policy: an all mechanism makes redirect ignored. If you use all, an authorization placed after it will not be reached. Do not change qualifiers or flatten records casually, and do not promise a specific delivery decision from ~all or -all. RFC 7208 governs these rules.
For apex evaluated domain example.com, the full owner is example.com, normally relative @ in that zone. For evaluated domain mail.example.com, use relative mail in the parent example.com zone or @ in a separately delegated mail.example.com zone. Check the editor's suffix behavior so the public owner is correct.
3. Publish the supported DKIM CNAME
Once EntrustedMail confirms applicability, its published gateway record is:
Type: CNAME
Relative owner at the signing-domain zone: select-em1._domainkey
Target: select-em1._domainkey.entrustedmail.net
TTL: 3600, or the provider's default
The source publishes this actual shared gateway target, unlike account-specific examples that must never be reused. It still must apply to your deployed domain. Follow a current provider-issued replacement packet if your domain uses a different supported setup; resolve conflicting instructions with Support before changing an active selector.
For signing domain example.com, the full owner is select-em1._domainkey.example.com, relative select-em1._domainkey in the example.com zone. For signing domain mail.example.com, the full owner is select-em1._domainkey.mail.example.com:
- In parent zone
example.com, enter relativeselect-em1._domainkey.mail. - In delegated child zone
mail.example.com, enter relativeselect-em1._domainkey. - In a delegated
_domainkey.mail.example.comzone, enter relativeselect-em1.
Determine actual authoritative DNS before editing. Preserve NS delegation and other services' selectors. A suffix-appending interface may require only the relative label, not the full owner. The target is the provider's complete hostname; do not append your own domain to it.
At the CNAME owner, do not coexist with TXT, A, AAAA, MX or another CNAME. Inspect and resolve a conflict with its owner before replacing data; never delete a working public key simply because a tutorial names the same selector. Do not paste the CNAME target into an SPF policy or convert it to a TXT record.
Keep the alias DNS-only rather than HTTP-proxied. Where flattening suppresses the required literal CNAME answer, turn off the applicable per-record flattening setting when available and check relevant whole-zone, apex and same-zone behavior. Make only the approved record-specific change, not a blanket global disable. If mandatory DNS-host behavior cannot preserve the required CNAME, stop and coordinate a supported arrangement. Do not remove shared delegation as a workaround.
DKIM uses a public key to verify a signature produced with a private key; it is not message encryption. EntrustedMail's encryption processing and DKIM authentication serve different purposes. See RFC 6376.
4. Use DNS Health Check without mistaking it for activation
The Access Portal DNS Health Check guide, says that clicking DNS Health Check shows the records the service cannot validate. Use that information to identify a missing or incorrect SPF/DKIM record after publication. Its warning is diagnostic, not proof that the service has or has not signed a particular message.
Also compare actual authoritative and recursive DNS answers. Replace placeholders in these read-only examples:
dig @AUTHORITATIVE_NS ACTUAL_SPF_OWNER TXT
dig @RECURSIVE_RESOLVER ACTUAL_SPF_OWNER TXT
dig @AUTHORITATIVE_NS ACTUAL_DKIM_OWNER CNAME
dig @RECURSIVE_RESOLVER ACTUAL_DKIM_OWNER CNAME
dig @RECURSIVE_RESOLVER select-em1._domainkey.entrustedmail.net TXT
Verify the exact full owner and complete CNAME target, not merely any nonempty response. Confirm that the alias resolves to the applicable public DKIM key and that the complete SPF policy matches the approved policy. Follow delegated authority and allow for TTL/cache effects. For a provider-issued alternative, use its actual target instead of the public example above.
If provider-side implementation is pending, supply requested public-DNS evidence and obtain completion confirmation through Support. A passing DNS check is not an instruction to create a new connector, change encryption policy or move incoming mail.
What about the ZixVPM MX warning?
The official health guide limits ZixVPM MX to customers using Zix Encryption. It directs encrypted inbound messages to a gateway able to decrypt them. It is not a universal DKIM prerequisite and must not be added for non-Zix customers.
If that separately scoped route applies, request the exact record syntax and destination from EntrustedMail. Before any routing change, obtain the routing owner's approval for the full owner and complete numeric-priority/target MX set and its inbound destination. Compare the entire set at authoritative and recursive resolvers with that approved plan; stop on extra, missing or different tuples. Do not accept any nonempty MX answer as success, and do not replace the root mailbox MX set from a child routing example. No Zix routing change is performed by this guide.
5. Test the delivered gateway message
With appropriate authorization, send a nonsensitive message through the actual existing EntrustedMail outbound route to a valid controlled external recipient. Confirm from trusted service diagnostics that it traversed the configured gateway rather than bypassing it. Exercise relevant approved encryption-triggered and other gateway paths without exposing real confidential content or altering encryption policy.
Inspect the message after gateway processing at the actual receiving service. Use Authentication-Results produced inside that service's known processing boundary, with its documented treatment of externally supplied result fields: removal or ignoring of untrusted fields must distinguish them from its own evaluation. A familiar authserv-id, topmost header or string saying pass is not proof. Ignore attacker-inserted fields; if provenance cannot be established, use the receiver's authenticated trace or administrator diagnostics. See RFC 8601.
Acceptance requires the intended EntrustedMail gateway signature to pass. Reconcile its observed d= and s= with the provider-confirmed domain and selector, confirm alignment with the unchanged intended visible From under the current DMARC policy, and require trusted receiver dmarc=pass. An upstream mailbox signature passing, DMARC succeeding through SPF alone or a rewritten provider From does not prove the intended branded gateway signer works.
Record the actual envelope domain and SPF result separately. Under relaxed alignment, relevant Organizational Domains must match; under strict alignment, the domains must match exactly. Apply the actual adkim and aspf policy. Do not promise strict SPF alignment from a guessed child Return-Path or infer runtime d= from the shared CNAME target. See RFC 9989.
DMARC and reporting: preserve existing policy
Read the direct policy and any applicable inherited policy before adding a record. Preserve existing enforcement and authorized reporting destinations. Only when no applicable policy exists, the owner approves and an appropriate monitoring plan exists, consider an initial TXT monitoring policy such as the illustrative v=DMARC1; p=none. Never downgrade working protection, duplicate DMARC or use monitoring as a substitute for authentication.
For visible From domain example.com, the TXT owner is _dmarc.example.com, relative _dmarc in that zone. For mail.example.com, use _dmarc.mail.example.com, relative _dmarc.mail in parent example.com or _dmarc in delegated mail.example.com. Verify the resulting full owner in suffix-appending editors.
If adding reports, obtain the owner's data-sharing/privacy approval. A report destination whose Organizational Domain differs from the Organizational Domain of the domain where the policy was discovered requires the report-generating receiver to check DNS authorization. A destination within that same Organizational Domain is excepted; a different hostname alone is not sufficient to classify it as external. See RFC 9990 section 4. That protocol check does not replace the owner's permission or authorize copying an unrelated report address.
Troubleshooting
The portal reports DKIM not enabled. Check its exact DNS Health Check details, full alias owner, conflicts, target, delegation and cache state. Ask Support to confirm the domain's signing implementation. Do not infer the whole runtime state from the warning's title.
DNS validates but there is no gateway signature. Confirm that the message followed the provisioned gateway route and that signing is configured for that exact domain. Public DNS alone cannot configure the signer. Keep connector changes separate and approved.
The original mailbox signature fails after processing. Gateway processing can change the delivered message. Evaluate the intended gateway signature and alignment after processing; an earlier signature's failure neither proves nor disproves the final route's success. Preserve the actual evidence for Support rather than disabling security features.
SPF fails although DKIM gives DMARC pass. At the observed envelope identity, fail or softfail indicates that the connecting sender is not authorized by the evaluated policy; inspect route and preserved authorizations. temperror indicates transient evaluation/DNS availability trouble. permerror indicates a permanent problem such as syntax, duplicate SPF policies or exceeded lookup budget. none means no applicable SPF policy was found. Diagnose these independently of DKIM success.
A different sender works but this one fails. Compare domain provisioning, actual From, envelope, signature and routing rules. One authorized domain or mailbox does not establish coverage for all domains in the tenant.
Official references and scope limits
- DKIM record for EntrustedMail: published alias and implementation assistance.
- Include EntrustedMail in your SPF record: native gateway authorization.
- Access Portal DNS Health Check Warning: validation diagnostics and conditional Zix applicability.
- Access Portal release notes, April 20, 2020: service requests and domain deployment confirmation.
- Microsoft 365 gateway configuration: separate routing prerequisites, not a DNS-only activation shortcut.
The source dates above are not a claim of new provider publication in 2026. Use the current provider-confirmed domain configuration where historical instructions and your deployed service differ.