Mailprotector CloudFilter does not add your domain's DKIM signature at its outbound relay. For Microsoft 365 mail routed through CloudFilter, configure branded DKIM in Microsoft 365, authorize the correct Mailprotector sending region in SPF, and ensure the relay does not alter the signed message. Then check a message after it has traversed the complete route.
This guide covers an existing, authorized Microsoft 365 → Mailprotector CloudFilter → external recipient deployment. It is not a Shield deployment guide, a CloudMail setup guide, a new connector migration, or an invitation to change incoming-mail routing. Other upstream email systems need their own signing instructions. An inbound-only Mailprotector filter does not justify adding an outbound SPF authorization.
No customer account, DNS change or test message was used to produce this guide.
On this page
- Confirm the route
- Configure SPF
- Configure upstream DKIM
- Preserve signed content
- Verify delivered mail
- Troubleshooting
Confirm the route and control owners
Before editing DNS, establish which Microsoft 365 domain appears in the visible From address, which envelope domain is actually evaluated for SPF, and which regional Mailprotector service carries outbound messages. Ask the responsible mail administrator to confirm the existing connector and routing configuration. Do not infer the sending region from the company's office location or its inbound MX record.
You need the authorized Microsoft 365 administrator, the authoritative DNS administrator and the owner of CloudFilter message policies. Use an account with the permissions necessary for the specific DKIM operation, not a blanket request for more privileges. The sending domain must already be successfully added to the Microsoft 365 tenant. If the domain or route is missing, resolve that separate onboarding task first.
Preserve existing Microsoft 365 authentication, legitimate direct-sending applications, policy protections and working DKIM selectors. This task must not silently replace staff-mail configuration with a gateway-only policy. Collect the current DNS answers and record who approves each change and how it can be reversed without breaking other senders.
Mailprotector SPF: choose the actual sending region
Mailprotector's outbound SPF instructions document these regional authorizations:
- United States:
include:spf.us.emailservice.io - Europe:
include:spf.eu.emailservice.io - Asia Pacific:
include:spf.ap.emailservice.io
Use only the region confirmed for your actual sending service. Do not add all three for convenience. These are include mechanisms, not three additional SPF policies. Integrate the applicable mechanism into the single existing policy at the envelope domain that the actual route uses, after checking its legitimate senders and lookup budget.
For example, an organization already authorizing Microsoft 365 must not erase that authorization merely because CloudFilter is being checked. Preserve every still-authorized route and the policy's intended final qualifier. If the service's observed envelope domain belongs to the provider rather than your organization, changing your root SPF record does not change that provider-owned identity or make it align.
The vendor page also discusses hosted solutions. That is not evidence that this CloudFilter/Microsoft 365 walkthrough configures every Mailprotector-hosted product. Stop if your service or envelope identity differs from the scope above; obtain the applicable product's instructions instead.
Mailprotector DKIM: sign upstream in Microsoft 365
The provider's DKIM limitation notice states: “DKIM signing at Mailprotector's relay is not possible at this time.” Publishing a newly invented Mailprotector selector cannot enable a signing feature that the relay does not provide.
Use the official CloudFilter/Microsoft 365 procedure, with Microsoft's current DKIM instructions for the actual tenant values and status labels:
- In Defender, open Email & collaboration → Policies & rules → Threat policies → Email authentication settings → DKIM. Select the intended custom domain.
- For a new domain showing Disabled and NoDKIMKeys, Microsoft's documented first enable attempt generates the CNAME requirements and a Client error. Acknowledge it; the status becomes CnameMissing. Open the domain details and copy both Publish CNAMEs entries.
- Publish the exact issued owner/target pairs. Do not construct a target from the tenant name: current and older Microsoft target formats differ. Preserve both selectors, even though only one signs at a time.
- After DNS is detected, enable Sign messages for this domain with DKIM signatures. Confirm Enabled and Signing DKIM signatures for this domain, with an updated Last checked date. DNS publication alone is not activation.
If signing is already working, do not disable it or generate replacements simply to follow a new-domain example. Compare the account's required records with DNS and investigate the actual failing route. A selector collision is an ownership problem to resolve, not permission to overwrite another system.
The Mailprotector example screenshot uses a particular tenant's targets. They are not values for your domain. Keep Microsoft-managed private keys private; this workflow needs only public CNAME information at your DNS host.
Publish DNS without breaking other services
Use the authoritative DNS zone, not necessarily the company that sold your domain. Save the current records before approved changes. Copy each issued record's type, full owner and destination exactly. These are public DNS values; you should never need to publish a DKIM private key.
Check what your DNS editor appends. For the illustrative full owner selector._domainkey.example.org, an editor for the example.org zone may require only selector._domainkey. In a separately delegated _domainkey.example.org zone, the relative name is selector. These are owner-format examples, not provider selectors or records to publish. A child-zone delegation changes where records must be entered; preserve NS delegations and coordinate with their owner rather than deleting them.
An issued CNAME owner cannot also contain TXT, A, AAAA, MX or another CNAME. If an owner is occupied, investigate dependencies and request a supported alternative where possible; do not overwrite another sender's record. A CNAME destination is a hostname, not a URL, and its trailing-dot treatment depends on the DNS editor. Check the resulting public owner and target instead of trusting the input form alone.
For Cloudflare, authentication aliases should be DNS only, not HTTP-proxied. Where literal CNAME answers are required, turn the applicable per-record Flatten option off when available and ensure whole-zone flattening does not conceal those aliases. Do not disable a global setting without assessing other records and obtaining authorization. Apex flattening is automatic; same-zone targets can be flattened regardless of that setting. If mandatory behavior prevents the required alias answer, stop and coordinate a supported configuration rather than inventing a switch or moving a selector. See Cloudflare proxy status and CNAME flattening controls.
Keep CloudFilter from invalidating the signature
A signature created before the relay can fail if the relay changes signed content. Mailprotector specifically identifies compliance footers and outbound policies that modify the subject or append text as risks in its CloudFilter guide.
Inventory the applicable rules, including exceptions that affect only some senders or recipients. The vendor suggests applying footer functionality upstream through Exchange tools. That is a design option to assess, not permission to disable a mandatory compliance or security control. Have the control owner approve an equivalent implementation that runs before signing, verify that it covers the required messages, and only then retire the conflicting downstream modification through the normal change process.
Do not bypass outbound scanning, delete policies or relax DMARC to hide a broken signature. If a mandatory downstream transformation cannot be moved safely, stop and work with the service owners on a supported design. A gateway verdict, a rewritten From address or an additional unaligned signature does not repair the original branded signature.
Test the variants that exercise those controls. A plain text message without a footer may pass while a message that triggers a subject tag fails. Keep the original controls and approval history available for diagnosis, but do not publish customer message content or security-rule details in an external support forum.
Understand SPF and preserve DMARC
SPF evaluates the SMTP envelope sender, commonly reported as smtp.mailfrom, not automatically the visible From address. A custom routing subdomain and a visible sender domain are different identities. Do not add an apex SPF include merely because the service uses a particular delivery backend. Use only the actual account-issued configuration and investigate the received message's evaluated identity.
If an authorized setup requires an SPF TXT policy, keep one v=spf1 policy at that exact owner, preserving legitimate existing authorizations and qualifiers. The SPF limit is ten evaluated DNS-dependent terms, including nested mechanisms, not simply ten includes. A redirect is ignored when an all mechanism is present. Do not blindly merge or replace a policy, and do not treat a qualifier as a guarantee of delivery or rejection. SPF specification.
DMARC passes when either SPF or DKIM passes and aligns with the visible From. Relaxed alignment uses an Organizational Domain match; strict alignment requires an exact domain match. A child envelope domain may align in relaxed mode but not strict mode. A passing provider-domain signature that does not align is not enough. For the new branded DKIM route, require the intended Microsoft 365 signature to pass and align, even if SPF could independently yield a DMARC pass. Read DKIM alignment and the visible From domain and the current DMARC specification.
Preserve existing direct and applicable inherited DMARC policies and approved reporting destinations. Authentication setup is not permission to downgrade quarantine or reject to none. Only if no applicable policy exists, the owner approves, and a monitoring plan is in place, an initial TXT policy can be v=DMARC1; p=none at _dmarc beneath the actual From domain. For example.org, that full owner is _dmarc.example.org; for news.example.org, it is _dmarc.news.example.org. Enter names relative to the actual authoritative zone and publish only one policy at an owner. This minimal example sends no aggregate reports by itself.
Choose any report recipient deliberately. Compare the reporting destination with the domain where the DMARC policy was found, including inherited policies. A different Organizational Domain requires the report-generating receiver to check DNS authorization; the same Organizational Domain as that policy domain is excepted. DNS authorization does not replace the owner's privacy and data-sharing approval. Do not copy a tutorial's reporting address. See RFC 9990, section 4.
Prove the actual messages authenticate
Provider verification checks DNS configuration. It is not proof that every message stream uses the intended signing domain. After configuration, an authorized administrator should test the actual application route with a controlled, valid recipient. This guide did not perform customer sends or change DNS.
Save the recipient's original message and use authentication results produced inside the actual receiving service's processing boundary. Consult that service's documented handling of externally supplied Authentication-Results, or obtain a receiving administrator's trace. A familiar authserv-id string or header position alone is not proof of authenticity. Ignore injected or otherwise untrusted result fields. Authentication-Results specification.
Record the visible From, envelope sender, intended DKIM signature's signing domain and selector, and the trusted receiver's SPF, DKIM and DMARC results. Acceptance requires the intended Microsoft 365 DKIM signature to pass and align with the intended From under the active alignment policy, plus a trusted receiver DMARC pass. A generic DMARC pass via SPF alone does not prove DKIM works. A rewritten provider From is not proof of brand-domain authentication.
Investigate SPF fail, temperror and permerror separately, even when aligned DKIM makes DMARC pass. Temporary errors suggest a transient lookup problem; permanent errors indicate a configuration/evaluation problem; neither should be silently marked passed. Test materially different sending paths separately. Authentication does not guarantee inbox placement, indexing or search rankings.
Troubleshooting this route
SPF fails only after CloudFilter
Compare the final connecting service and envelope domain with the actual SPF policy. Check the selected region, existing authorized mechanisms and nested lookup count. Do not add inbound MX hosts or guess regional IP ranges. A temporary lookup error and a permanent policy error need different investigation; neither is a clean pass.
Defender still shows CnameMissing
Check both full selector owners in authoritative DNS and a public resolver. Look for a doubled domain suffix, wrong zone, occupied owner, missing second selector, concealed CNAME or a target copied from a sample tenant. Compare with the current account packet, not a hand-built formula. Preserve a conflicting existing record until its owner and dependencies are resolved.
Microsoft 365 shows signing enabled, but the receiver reports DKIM fail
First confirm that the failed signature is the intended Microsoft 365 signature. Compare the signed domain and selector, then investigate body or signed-header changes along the relay path. A passing DNS lookup cannot rule out content modification. Use administrator-controlled traces and samples rather than turning off controls until something passes.
DKIM passes, but DMARC fails
A cryptographically valid signature may use a domain that does not align with the visible From. Check the actual signing domain and active alignment mode. Do not accept a tenant-domain or unrelated provider-domain signature as proof that the brand is authenticated. Configure the intended existing sending domain rather than changing the displayed brand merely to obtain a green result.
An internal test has no DKIM signature
Microsoft's verification instructions call for a recipient in another email system; messages within the same organization can omit the signature. Use a controlled external recipient through the full CloudFilter route. Do not treat an internal-only test as a failed public-DNS setup or as proof that external mail is safe.
Official sources and review limits
- Mailprotector: How DKIM Is Used for Email.
- Mailprotector: SPF Records for Outbound Email Relay; regional instructions checked during this review.
- Mailprotector: Configure DKIM with Microsoft 365 for CloudFilter.
- Microsoft: Set up DKIM to sign mail from your cloud domain.
This is a source-documented setup and diagnostic guide, not a report of a hands-on customer deployment. Shield setup is outside its scope. Configuration changes, receiving-message tests and publication still require the responsible team's implementation and verification.