Provider documentation checked on 8 November 2026. Account-generated values, entitlements and current support remain deployment prerequisites.
Start with the actual mail path
Exclaimer server-side signatures modify email after submission. Authentication must therefore be evaluated across the route, not just at the first server. Draw the path from Microsoft 365 or Google Workspace through Exclaimer, back to the mail platform, and onward to the recipient. Include any downstream security gateway because a later content change can alter what the receiver verifies.
This guide covers the documented server-side route. Do not automatically apply its DNS changes to a client-side-only deployment that does not route mail through Exclaimer. Identify the subscription, platform, region, sending domains and mail-flow owner before making changes. Keep a record of the pre-change connectors and routing rules, without credentials.
Put DKIM responsibility in the right place
References: RFC 6376 §3.7.
Exclaimer's current DKIM guidance states that applying a server-side signature changes message content and removes the existing DKIM signature. Exclaimer does not sign or re-sign messages with customer DKIM keys, does not provide ARC sealing, and cannot be configured to sign on return connectors. The final Microsoft 365 or Google Workspace platform supplies DKIM after processing. This is not a missing Exclaimer selector to repair.
The operational consequence is to verify custom-domain signing on the final platform. Do not assume that any automatically applied signature aligns with your visible From. Obtain the actual provider-generated DNS values and verify the current custom-domain signing state through that platform's own documentation and administration interface. Exclaimer's general description of automatic signing is not evidence that your particular domain is enabled and aligned.
Do not install an arbitrary selector or reuse a key from a signature tutorial. If Google uses a configured selector other than a documentation example, query the selector actually present in the message. If Microsoft provides two CNAMEs, use the current tenant values. Missing or invalid DNS should be diagnosed before any key rotation; rotating keys without a reason can complicate an otherwise simple naming error.
Add the subscription's regional SPF permission
References: RFC 7208 §3.2, RFC 7208 §4.6.4.
For server-side deployments, Exclaimer directs administrators to add include:spf.<region code>.exclaimer.net for each sending domain. An Exclaimer Admin can find the region in the portal under Your Subscriptions, Manage, Subscription details, Server. Use that verified code, not the user's location or an example region. Preserve all other legitimate senders in one SPF policy.
Insert the authorization before the terminal all mechanism. Check full syntax and the ten-term limit for evaluated include, a, mx, ptr, exists and redirect terms, including nested SPF processing; the limit is not a raw DNS-packet count. Do not append a second SPF policy, remove Microsoft or Google permissions, or broaden the record to every region as a troubleshooting shortcut. A static-address alternative needs its own current-source review and maintenance owner; do not casually flatten a provider-managed permission into an old address list.
Query authoritative DNS to confirm the exact owner and value, then account for caching. Save the previous policy and the reviewed diff. SPF on the return leg and final recipient authentication are related but distinct observations. A policy change cannot make a broken DKIM body signature valid or create alignment for an unrelated signing domain.
Use a small external-message test matrix
References: RFC 9989 §4.4, RFC 9989 §5.3.5.
Test messages that receive the server-side signature and an approved control route where appropriate. Include each sender domain and any distinct downstream gateway route. Choose an external mailbox whose raw headers can be retained; an internal message is not equivalent proof of external signing behavior. Confirm that the intended signature was actually applied so that a bypassed route cannot accidentally pass acceptance.
Record the visible From domain, envelope domain, each DKIM d= and s=, trusted SPF/DKIM/DMARC results, and routing hops. Check whether signing occurred after Exclaimer's content modification. If another gateway subsequently changes the body, investigate that later step instead of asking Exclaimer for a nonexistent signing key. Preserve comparable messages and timestamps for the mail-flow team.
Synthetic example: mail from person@example.com returns from signature processing, and the final platform signs it with d=example.com. A valid signature has exact alignment. If the final platform signs only with an unrelated tenant or provider domain, the presence of DKIM pass alone does not establish aligned DKIM. Inspect aligned SPF as well before concluding whether DMARC passes. These are hypothetical identities, not observed behavior of a customer tenant.
Diagnose missing, invalid and unaligned signatures separately
References: RFC 6376 §6.
For dkim=none, first confirm the external route, final-platform configuration and whether the message used the expected sender domain. For dkim=fail, locate the selector key and inspect whether content changed after signing. For dkim=pass with DMARC failure, compare signing and envelope domains with the visible From under the actual alignment modes. These three states have different remedies.
Do not treat a vendor support article's suggested rotation as the first response to every lookup failure. Check the authoritative name, record type and target first. Escalate persistent route-specific failures with the minimum necessary headers through the organization's approved support channel, protecting personal content and internal metadata. This guide does not transmit a support ticket or authorize sharing sensitive mail.
Preserve a safe return path
Document how the mail-flow owner can restore the previously approved route if the change disrupts delivery. Do not simply delete connectors or broaden relay access; connector and transport changes must follow the platform's supported process and the organization's authorization controls. A signature feature should not become a reason to weaken the domain-wide DMARC policy.
Close the change only after the intended external route shows the expected signature treatment and aligned authentication. Retain the region evidence, DNS diff, final-platform configuration and received originals. Authentication does not guarantee inbox placement. No live tenant, DNS or delivered-message test was performed for this draft, and no human approval or publication is implied.