Exclaimer SPF, DKIM and DMARC setup, step by step

For Exclaimer Server-Side signatures, add your subscription's regional SPF include to each applicable sending domain's existing policy. Configure branded DKIM on the final Microsoft 365 or Google Workspace platform, not in Exclaimer. Exclaimer removes the existing DKIM signature when it applies a server-side signature and does not re-sign mail or add ARC seals. The final mail platform signs after processing. Exclaimer's current DKIM behavior

This guide covers that cloud server-side route. A client-side-only signature deployment does not justify the same Exclaimer routing changes. Nor does this configure an on-premises signature product or an unrelated outbound security gateway. No customer tenant, DNS or delivered mail was tested.

Identify the route before editing DNS

Write down the mail path, including any service that changes the message after the signature is inserted:

Microsoft 365 or Google Workspace
 -> Exclaimer Server-Side signature processing
 -> return to the mail platform
 -> any additional outbound gateway
 -> external recipient

Record the platform, Exclaimer subscription, subscription region, sending domains and mail-flow administrator. Identify which rules apply server-side signatures and which messages bypass them. A successful message that never receives the signature is not a useful acceptance test of this integration.

Save the existing SPF, DKIM and DMARC records and the approved routing configuration. Include aliases and subdomain senders in the inventory. An invoice application that sends directly through another provider remains a separate authentication task even if its From address belongs to the same company.

Add the correct regional Exclaimer SPF include

Exclaimer's documented mechanism is:

include:spf.REGION.exclaimer.net

REGION is a placeholder. An Exclaimer Admin can find the actual value at Your Subscriptions → Manage → Subscription details → Server. Use the subscription's location, not the sender's office or recipient's country. Current documented codes are au, ca, de, eu, uae, uk and us for Microsoft 365, and eu or us for Google Workspace. Exclaimer SPF setup and region tables

For illustration only, an existing Microsoft 365 policy for a confirmed UK Exclaimer subscription could change as follows:

Before: v=spf1 include:spf.protection.outlook.com -all
After: v=spf1 include:spf.protection.outlook.com include:spf.uk.exclaimer.net -all

Publish only the resulting SPF value, not the Before: or After: label. This example is not a replacement for a policy containing other legitimate senders. Keep the established terminal qualifier unless the domain owner separately approves changing it.

There must be one v=spf1 TXT record at each SPF owner. Merge the regional authorization before the terminal all, retain other active services, and check the full nested evaluation against SPF's ten DNS-lookup-causing-term limit. include, a, mx, ptr, exists and redirect can contribute; simply counting the visible includes is insufficient. Multiple unrelated verification TXT records are fine. SPF record and evaluation rules

If an existing SPF policy uses redirect=, preserve its intended authorizations and final semantics through a reviewed merge. Any all mechanism causes redirect to be ignored, so appending a canned policy or an all without reviewing that dependency can change which senders are authorized. SPF redirect semantics.

Do not add every Exclaimer region, use +all, or replace provider-managed permissions with an unmaintained IP list to clear an error. SPF authorization does not configure a connector, insert a signature or repair DKIM.

Which domain does SPF authenticate?

SPF checks the SMTP envelope MAIL FROM domain against the connecting server. It does not directly check the visible From, Reply-To or display name. Confirm the evaluated identity in the trusted receiver's smtp.mailfrom result. An empty reverse-path uses the HELO identity for SPF evaluation. SPF identities

Exclaimer requires the regional addition for server-side sender domains, but that instruction does not prove the final recipient evaluated those same identities. Distinguish authorization on the Exclaimer return leg from the final external result. No separate custom Return-Path control is established by the Exclaimer documentation used here; inspect the actual route rather than inventing a bounce subdomain.

Enable branded DKIM on the final mail platform

There is no Exclaimer customer DKIM key to generate for this documented service. An automatically applied signature also does not prove that your own From domain is the signing domain. Verify the final platform's custom-domain configuration and the delivered d= identity. Exclaimer's signing responsibility

For the broader mailbox-platform configuration, use the Microsoft 365 authentication guide or Google Workspace authentication guide, then verify the complete Exclaimer return route described here.

Microsoft 365

The custom domain or subdomain must already be added to Microsoft 365. In Microsoft Defender, open Email & collaboration → Policies & rules → Threat policies → Email authentication settings → DKIM, then select the exact domain.

For the documented new-domain state NoDKIMKeys, Microsoft instructs the administrator to try enabling the domain’s DKIM toggle. The expected Client error exposes the required CNAMEs; dismiss it, then open the domain now marked CnameMissing and copy the Publish CNAMEs values. This is the record-generation step, not evidence that signing is already active. Continue with DNS publication and the final enable-and-confirm step below. Microsoft’s new-domain sequence.

For a new configuration, obtain the two CNAME records shown in the domain's Publish CNAMEs section. Publish their exact tenant-generated targets at the specified selector1._domainkey and selector2._domainkey owners. Do not reconstruct targets from an old tutorial: Microsoft supports different target formats. After detection, enable Sign messages for this domain with DKIM signatures and confirm the signing status. An already-enabled domain should be inspected, not needlessly recreated. Microsoft custom-domain DKIM procedure

Google Workspace

Use an authorized administrator; Google's generation procedure specifies a super administrator. Newly enabled Gmail organizations may need 24–72 hours before key generation is available. Open Apps → Google Workspace → Gmail → Authenticate email, select the domain and generate a record. Prefer the offered 2048-bit key where the DNS host supports it.

Publish the complete generated TXT value at its displayed selector owner, then return and choose Start authentication. Confirm Authenticating email with DKIM. The default selector is google, but a different configured selector must be used when applicable. Publishing TXT alone is not the activation step. Google DKIM generation, publication and activation

Put records at the exact DNS owner

DNS labels in an editor are relative to the zone being edited. These examples explain placement; they are not generated tenant values:

If the editor expects a fully qualified name, enter that instead and confirm it does not append the zone twice. At a delegated child, edit the child zone's authoritative service, not a stale parent-zone copy. Check current nameservers before assuming the registrar hosts DNS.

For an issued signing domain such as news.example.com, a full owner SELECTOR._domainkey.news.example.com is SELECTOR._domainkey.news relative to the parent example.com zone, or SELECTOR._domainkey in a separately delegated news.example.com zone. If _domainkey.news.example.com itself is delegated, the relative owner there is SELECTOR. Replace the selector placeholder with the issued value, preserve the account’s exact type and public value, and publish at the actual authority without removing the NS delegation. This example explains name placement, not automatic product eligibility for a new domain. DKIM owner construction, relative DNS names.

A CNAME cannot coexist with a TXT or another ordinary record at the same owner. Resolve selector ownership before replacing anything. Preserve other services' selectors, existing MX records and verification tokens. Long DKIM TXT values may contain multiple quoted strings within one TXT record; do not split fragments into separate records or publish a private key. DNS alias restrictions and DKIM DNS representation

For authentication records that actually use CNAME, retain a literal CNAME answer to the issued target and use DNS-only rather than HTTP proxying. Turn the relevant per-record Flatten setting off where available, and ensure applicable whole-zone settings do not suppress the alias. On Cloudflare, flatten-all cannot be overridden per record; apex CNAMEs are flattened by default, and same-zone targets are flattened regardless of that setting. These are DNS-host behaviors, not assumed controls in the sending application. If mandatory behavior or shared settings cannot preserve the required CNAME answer, stop and coordinate a supported layout without breaking other services or removing shared NS delegations. Do not blindly disable features across the whole zone. Cloudflare verification guidance, flattening controls and limits.

Check public DNS separately from the account status

These commands are read-only patterns. Replace uppercase placeholders, use the actual selector and run only the lines relevant to your platform:

dig +short NS DNS_ZONE
dig @AUTHORITATIVE_NS TXT ENVELOPE_DOMAIN +noall +answer
dig +short TXT ENVELOPE_DOMAIN
dig +short CNAME selector1._domainkey.SIGNING_DOMAIN
dig +short CNAME selector2._domainkey.SIGNING_DOMAIN
dig +short TXT MICROSOFT_CNAME_TARGET
dig +short TXT GOOGLE_SELECTOR._domainkey.SIGNING_DOMAIN
dig +short TXT _dmarc.FROM_DOMAIN

Expect one SPF policy at the actual envelope owner, with the correct regional authorization wherever the documented route requires it. For Microsoft, compare both CNAME targets with the tenant and resolve each target's public key. For Google, compare the full TXT value with the selected domain's generated key. Repeat a selector query against its authoritative server if recursive answers disagree.

An empty answer warrants checking the owner and delegation; SERVFAIL warrants DNS-service or DNSSEC investigation. A correct authoritative answer with an old recursive answer suggests caching. A wrong authoritative answer will not repair itself by waiting. Retain resolver, UTC time and exact answers.

Accept the setup only after an external-message test

During an authorized implementation test, send a fresh message to a separate external mailbox you can inspect. Use each relevant From domain and route, including replies and any downstream gateway. Confirm that Exclaimer actually applied the intended server-side signature.

Save the received original and use the Authentication-Results added by the trusted receiving system, not a sender-inserted lookalike. Record the connecting IP, smtp.mailfrom, visible From, every DKIM d= and s=, and the DMARC result. Trust boundaries for Authentication-Results

Use receiver-controlled diagnostic output, or have the receiving administrator establish which fields were generated inside its known processing boundary and document how externally supplied Authentication-Results are removed or distinguished. A familiar authserv-id string or header position alone does not establish provenance. Ignore attacker-inserted or otherwise untrusted results, including a forged field naming the expected receiver. Operational receiving-boundary requirements.

The acceptance criteria for this DKIM setup are deliberately stricter than a generic DMARC pass:

• The intended branded DKIM signature must show dkim=pass and align with the visible From.
• SPF must be inspected independently. Resolve real fail, softfail, permerror, temperror or missing-policy results on a direct production route rather than hiding them behind passing DKIM.
• DMARC must pass using at least one aligned passing mechanism under the actual policy.
• The message must traverse the intended signature-processing path, with signing effective after the final content modification.

DMARC can pass through aligned SPF even when DKIM is absent or broken, but that does not complete a branded DKIM deployment. A passing DKIM signature from an unrelated tenant domain likewise does not prove branded alignment. Relaxed alignment permits matching organizational domains; strict alignment requires the domains to match exactly. DMARC alignment and evaluation

For example, From: person@example.com and a valid d=example.com have exact alignment. A valid d=tenant.onmicrosoft.com does not align with that From. These are explanatory examples, not observed customer results.

Preserve DMARC policy and reporting

Adding signatures is not a reason to weaken an existing p=quarantine or p=reject policy. Keep the applicable policy, alignment modes and report destinations. Check inherited parent policy before adding a new _dmarc record for a subdomain.

Only where no applicable policy exists and the domain owner approves monitoring, a starting pattern is:

Owner: _dmarc.example.com
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

Replace the example domain and mailbox with an approved, working report destination. p=none requests monitoring, not immunity from spam filtering. Authorize external report recipients where required. External reporting authorization Review aggregate reports across all legitimate senders before enforcement. Current DMARC is RFC 9989; new rollout guidance should not rely on the removed pct tag. DMARC policy and aggregate reporting

Compare the Organizational Domain of the aggregate-report URI host with the Organizational Domain of the domain where the DMARC policy was found, not automatically the visible From domain. If they differ, the report-generating receiver must check the destination’s DNS authorization. A destination in the same Organizational Domain as that policy domain is excepted, even when its hostname differs. This protocol check does not replace the domain owner’s separate approval to share report data with that recipient. RFC 9990 section 4.

Troubleshoot the specific failure

Do not rotate keys merely because a lookup is missing. First check record placement, type, target and delegation. If an external message still lacks DKIM after correct DNS and signing configuration, follow the provider's support route with minimally necessary, approved diagnostic headers. Avoid sharing passwords, private keys or unnecessary message content.

Keep a recoverable change record

Retain subscription-region evidence, DNS before/after values, final-platform signing status and received-message results by route. If the change disrupts mail, the mail-flow owner should restore the previously approved route or pause the affected sender, not delete arbitrary connectors or broaden relay permissions. Recheck after a key rotation, gateway change or signature-processing change.

This is a documentary setup guide. Account permissions, current tenant-generated values, public DNS answers and delivered-message acceptance remain implementation checks, not results claimed by this article.