How to set up DMARC/DKIM/SPF for Exclaimer
Published 12 Aug 2026
Updated 20 Oct 2026
13 min read
Summarize with
Updated on 20 Oct 2026: We corrected Exclaimer SPF guidance, clarified DNS setup, and replaced percentage-based DMARC rollouts with policy stages.
Exclaimer does not publish DKIM or DMARC for your domain. Authorize its regional mail infrastructure in SPF when server-side signatures are enabled, keep DKIM signing at Microsoft 365 or Google Workspace, and publish DMARC on the visible From domain. Client-side-only deployments need no Exclaimer SPF change. Check the final recipient's authentication results rather than assuming that routing through Exclaimer always breaks SPF alignment. Exclaimer's DMARC guidance confirms that DMARC and DKIM need no Exclaimer-side record changes, while server-side SPF does.
The working chain is: Microsoft 365 or Google Workspace sends to Exclaimer, Exclaimer changes the message body by adding the signature, then the original platform receives the message back and applies the final DKIM signature before external delivery.
Connect your domain to Exclaimer
Exclaimer discovers sender domains through the connected Microsoft 365 tenant or Google Workspace organization. There is no separate DNS ownership record to add in Exclaimer for each sender domain, but the domain must already be verified in your mail platform. Connect the directory, enable synchronization, configure the signature method, and confirm that the domain's users appear before changing DNS.
- Open the subscription: Sign in to Exclaimer, launch the correct subscription, and select Connect in the sidebar.
- Connect the directory: Use a Microsoft 365 Global Administrator account or a licensed Google Workspace Super Admin account, then accept the requested permissions.
- Choose the signature path: Enable server-side signatures when Exclaimer must process mail in transit. Choose client-side only when signatures are inserted in Outlook or Gmail before sending.
- Complete synchronization: Wait for Syncing Complete, or open Settings, Sender Management and run a manual synchronization after adding a new domain or user.
- Confirm mail flow: For Microsoft 365 server-side use, open Settings, Mail Flow and confirm the connection succeeds. For Google Workspace, configure the outbound route and return SMTP relay using the host and IP values shown by Exclaimer. Restrict the return relay to those IPs and require TLS.
Exclaimer Connect screen for Microsoft 365 server-side signatures
A new Microsoft 365 domain needs no manual Exclaimer domain entry when it belongs to the connected tenant, directory synchronization has completed, and the standard send connector routes its messages. If synchronization or routing is limited to a test group, add the new users to that scope and rerun the connection wizard when required. A change to the users' primary SMTP domain should also be reported to Exclaimer account support because it can affect subscription accounting.
|
|
|
|
|---|---|---|---|
Microsoft 365 | Global Admin | Entra ID | Connector |
Google Workspace | Super Admin | Directory | SMTP route |
Where Exclaimer gets sender-domain data
Use the correct DNS record names
Add email authentication records at the authoritative DNS provider for your sending domain. For example.com, use the names below. Replace example.com with your own domain and copy DKIM values directly from the final sending platform.
|
|
|
|
|---|---|---|---|
SPF | TXT | example.com | Existing SPF value with the regional Exclaimer include added |
Microsoft 365 DKIM selector 1 | CNAME | selector1._domainkey.example.com | Exact selector1 target generated by Microsoft 365 |
Microsoft 365 DKIM selector 2 | CNAME | selector2._domainkey.example.com | Exact selector2 target generated by Microsoft 365 |
Google Workspace DKIM | TXT | google._domainkey.example.com | Generated DKIM public key; use your selected selector if different |
DMARC | TXT | _dmarc.example.com | DMARC policy and reporting address |
DNS names for a sending domain of example.com
If your DNS provider appends example.com automatically, enter @ for the root SPF record, _dmarc for DMARC, and only the selector._domainkey part for DKIM. Confirm the saved full name to avoid example.com.example.com. Microsoft 365 DKIM records are CNAME records, while Google Workspace publishes its key as TXT; do not substitute one record type for the other.
Set up SPF
Server-side Exclaimer signatures require the regional Exclaimer include in the one SPF TXT record for every sending domain. Client-side-only signatures do not route mail through Exclaimer, so they need no Exclaimer include. This authorizes Exclaimer's relay path. DMARC SPF alignment is a separate check of the envelope sender domain against the visible From domain; an SPF include alone does not establish it.
- Find the region: In the Exclaimer portal, select Manage beside the subscription and read Server under Subscription details.
- Choose the include: Use include:spf.<region>.exclaimer.net with the exact region shown. Microsoft 365 regions include au, ca, de, eu, uae, uk, and us. Google Workspace regional hosts and SPF includes are listed for de, eu, and us in Exclaimer's SMTP host list.
- Edit one record: Insert the Exclaimer include before the final all mechanism in the existing SPF TXT record. If no SPF record exists, create one that authorizes your mail platform and the correct Exclaimer region. Never publish a second SPF record.
- Count lookups: Keep SPF evaluation within the limit of ten DNS-lookup-causing terms, including nested includes. Exceeding it returns permerror. Remove stale senders before adding Exclaimer if the record is close to the limit.
- Preserve the qualifier: Keep the existing ~all or -all ending during this edit. Do not copy a generic example over a working record.
Exclaimer subscription region used to select the SPF include
For an Australian Microsoft 365 subscription, merge the Exclaimer include with the existing Microsoft include. The official SPF steps explain the regional include syntax. The SMTP host list lists the Microsoft 365 and Google Workspace regional values. These examples keep the mail platform and Exclaimer in one SPF record.
Microsoft 365 example for Exclaimer Australiadns
v=spf1 include:spf.protection.outlook.com include:spf.au.exclaimer.net -all
Google Workspace example for Exclaimer Europedns
v=spf1 include:_spf.google.com include:spf.eu.exclaimer.net -all
Enter each example as one continuous TXT value. After saving, confirm the authoritative name servers return the new value and allow cached answers to expire according to the previous TTL. Verify that only one SPF record exists and the lookup count stays within the limit. If you send from a subdomain, configure SPF for that exact envelope sender domain because SPF records are not inherited from a parent domain.
SPF checker
Find SPF syntax issues, lookup limits, and weak records.
?/16tests passed
Set up DKIM
Exclaimer removes the pre-existing DKIM signature when a server-side signature changes the message body. It does not sign the modified message or add ARC. The message returns to Microsoft 365 or Google Workspace, which must apply a fresh DKIM signature for your sending domain. Enable DKIM at that final sending platform, never in Exclaimer. Exclaimer's DKIM behavior documentation confirms this processing order.
Microsoft 365
- Get the targets: Open Email authentication settings, select the DKIM tab for the custom domain, and copy both generated CNAME targets.
- Publish selectors: Create selector1._domainkey and selector2._domainkey CNAME records with the exact tenant targets.
- Enable signing: Return to the DKIM settings and enable signing for the custom domain after both records resolve.
- Rotate safely: Leave both selectors published so Microsoft can rotate between them without an authentication gap.
Google Workspace
- Open Gmail settings: In the Admin console, open Apps, Google Workspace, Gmail, then Authenticate email.
- Generate the key: Select the sender domain, choose a 2048-bit key, and use the selector displayed by Google.
- Publish the TXT: Add the generated public key at the selector._domainkey host in authoritative DNS.
- Start authentication: Wait until the TXT record resolves, then select Start authentication for that domain.
Copy the generated Microsoft 365 CNAME targets exactly. Microsoft supports both older onmicrosoft.com targets and newer targets ending in dkim.mail.microsoft, so do not construct them from a generic example. The Microsoft 365 DKIM instructions explain the target formats, while the Google Workspace DKIM instructions cover generating and publishing the TXT key.
Send an external test after Exclaimer adds the signature. The final Authentication-Results header needs dkim=pass, and the DKIM d= domain must equal the visible From domain or share its organizational domain under relaxed DMARC alignment. With adkim=s, the domains must match exactly. Testing a message that bypassed Exclaimer does not prove the routed path works.
If SPF passes but its envelope sender domain does not satisfy DMARC alignment, a passing DKIM signature with the correct domain still gives DMARC a pass. An actual SPF authentication failure is a separate issue to investigate; do not dismiss it as normal Exclaimer behavior.
- Missing DKIM header: Confirm the message left through the final Microsoft 365 or Google Workspace outbound path after Exclaimer processing.
- Wrong signing domain: Enable DKIM on the exact custom domain used in From, not only on the tenant's default domain.
- Body hash failure: Check for another gateway that modifies the body after the final DKIM signature is applied.
- Internal-only test: Repeat the test to an external mailbox because internal delivery often omits final DKIM signing.
Set up DMARC
Publish DMARC at _dmarc.example.com for the domain in the visible From address. Start with p=none and collect aggregate reports before enforcing a policy. If the domain already uses p=quarantine or p=reject, keep that stronger policy and fix Exclaimer-related failures without lowering it.
Starting DMARC TXT valuedns
v=DMARC1; p=none; rua=mailto:dmarc@example.com
- Choose the mailbox: Replace dmarc@example.com with a monitored address that can receive XML aggregate reports. If using Suped, copy the reporting address provided for your domain.
- Generate the value: Use the DMARC record generator when you need reporting or subdomain tags without hand-editing the syntax.
- Publish one TXT: Create one TXT record at _dmarc. Multiple DMARC records prevent a valid policy from being selected.
- Retain relaxed mode: Use the default relaxed DKIM alignment unless a documented security requirement demands adkim=s.
- Read the reports: Review sending IPs, DKIM signing domains, and message counts, then compare those results with known Exclaimer-routed tests. Reports identify the system that connects to the receiver, so they do not necessarily identify Exclaimer as a separate source.
Check the actual TXT content. Lookup software often displays surrounding quotes, which are presentation syntax; do not add literal quote characters to the DMARC value. Check that external reporting authorization exists when reports go to a different domain. Exclaimer itself needs no DMARC value in its portal.
DMARC checker
Look up a domain's DMARC record and catch policy issues.
?/7tests passed
Verify and troubleshoot
Use an external mailbox and send through the exact Exclaimer signature path used in production. Confirm that the signature appears, then inspect Authentication-Results, Return-Path, DKIM-Signature, and the Received chain. Repeat the test for every From domain and both server-side and client-side routes when both are enabled.
- Check Exclaimer status: Open Settings, Mail Flow and confirm the Microsoft 365 or Google Workspace server-side connection is complete.
- Send outside the tenant: Send a plain message to an external recipient and verify that the intended Exclaimer signature was inserted.
- Read final results: Require dkim=pass with a domain that meets your DMARC alignment mode and dmarc=pass. Check SPF authentication separately against the reported smtp.mailfrom domain.
- Compare routes: If a direct message passes but an Exclaimer-routed message fails, inspect the return connector and final DKIM signing step.
- Retest after DNS: Confirm authoritative DNS returns the updated record and cached answers have expired, then send a new message. Old headers cannot validate a later DNS change.
Exclaimer Mail Flow screen showing a successful server-side connection
Acceptable Exclaimer result
The signature is present, final DKIM passes with a domain that satisfies DMARC alignment, and DMARC passes. SPF results depend on the final sending IP and envelope sender domain.
- DKIM: Pass with the correct d= domain.
- DMARC: Pass through DKIM alignment or an SPF pass that satisfies alignment.
- SPF: Verify authorization separately from domain alignment; investigate authentication failures.
- Body: Expected Exclaimer signature appears once.
Result that needs action
DMARC fails when neither SPF nor DKIM passes with a domain that satisfies alignment. Fix the legitimate sending route before enforcing DMARC.
- No DKIM: Enable it for the custom domain.
- Wrong domain: Correct the final platform's signing domain.
- Hash failure: Find post-signing content modification.
- DMARC error: Remove duplicate or malformed records.
Header inspection is decisive because a green DNS check cannot prove how a real routed message was signed. Use the Authentication-Results header added by the receiving mailbox provider at its trusted boundary, identified by its authserv-id and Received chain. Do not trust an arbitrary header solely because it appears last.
The Suped email tester below gives a destination for a live message and returns an authentication diagnosis. Send through Exclaimer with the production From domain, then compare its DKIM and DMARC results with the expected route above.
Email tester
Send a real email to this address. Suped shows a results button when the test is ready.
?/43tests passed
Monitor authentication after setup
A one-time test misses connector edits, newly added domains, and later DKIM failures. Suped is our DMARC monitoring platform. Use it to review aggregate reports by sending source and investigate authentication regressions after Exclaimer or mail-platform changes.
- Verify the route: Confirm Exclaimer-routed test messages pass, then review the corresponding Microsoft 365 or Google Workspace sending infrastructure in reports.
- Alert on regression: Notify the team when aligned DKIM drops or DMARC failures rise in the reports received.
- Trace the cause: Compare source-level failures with connector changes and DKIM or DNS configuration.
- Review new senders: Investigate unfamiliar source IPs before approving them; a familiar provider name does not prove the traffic is authorized.
Set alert recipients to a shared operational mailbox. Aggregate reports normally show the final sending platform, so they cannot by themselves distinguish every Exclaimer-routed message from direct mail sent by that platform. Keep header tests and mail-flow logs alongside report monitoring.
Aggregate reports are commonly sent daily, so report-based alerts follow the arrival of receiver data. They do not provide an immediate view of every message. RFC 9990 defines aggregate reporting; use a fresh external message test when a routing change needs immediate verification.
Secure your domain with p=reject
Move to p=reject only after every legitimate route has stable DMARC passes. For Exclaimer server-side mail, confirm final DKIM consistently passes with the correct domain after the signature is applied. Keep the SPF configuration valid as well.
- Collect a baseline: Keep p=none long enough to observe normal sending cycles and every active sender domain, including low-volume systems.
- Classify every source: Approve legitimate infrastructure, repair it, or stop it. Do not whitelist unknown traffic because it resembles Exclaimer.
- Stage quarantine: After fixing legitimate failures, change to p=quarantine and review reports and delivery outcomes before proceeding.
- Stage rejection: Change to p=reject when the quarantine stage shows legitimate mail authenticates correctly. Treat each policy change as applying to all DMARC-failing mail.
- Protect subdomains: Set sp=reject when unused and active subdomains have been reviewed, or publish separate DMARC records where policies differ.
- Keep monitoring: Treat p=reject as an operating state. New senders and connector changes still need authentication review.
RFC 9989 makes pct historic. Do not depend on pct=25 or another percentage to limit enforcement. For a smaller initial rollout, use a separately configured sending subdomain with its own DMARC record and verify that route before changing the main domain's policy. The version tag remains v=DMARC1.
Final DMARC TXT valuedns
v=DMARC1; p=reject; rua=mailto:dmarc@example.com
Suped's hosted DMARC workflow keeps policy changes and report review together. Check for legitimate-source failures after each policy change and allow for receiver reporting delays before advancing.
Do not lower an existing p=reject policy merely because Exclaimer-routed mail shows SPF alignment failures. If aligned DKIM passes, DMARC already passes. If both methods fail DMARC alignment, fix the final Microsoft 365 or Google Workspace sending path.
Frequently asked questions
Yes for server-side signatures. Add include:spf.<region>.exclaimer.net to the existing SPF record for each sending domain, using the subscription's exact region. No Exclaimer include is needed for a client-side-only deployment. The include authorizes Exclaimer infrastructure; DMARC SPF alignment is checked separately against the envelope sender and visible From domains.
No. A server-side signature changes the body, so Exclaimer removes the earlier DKIM signature and returns the message to Microsoft 365 or Google Workspace. That final sending platform applies a new DKIM signature before external delivery. Enable DKIM there for every visible From domain.
Check the final recipient's Authentication-Results header. SPF authenticates the envelope sender domain shown as smtp.mailfrom, while DMARC compares that domain with the visible From domain. If those domains do not satisfy alignment, SPF can pass while DMARC SPF alignment fails. A passing DKIM signature with the correct domain still gives DMARC a pass. Investigate an actual spf=fail separately.
Confirm the updated record is visible at the authoritative name servers, then allow cached records to expire according to their previous TTL. There is no fixed 24-hour wait for every change. Enable DKIM at the mail platform once its DNS check succeeds, then send a new external message through Exclaimer.
Yes. Confirm that Exclaimer-routed external mail receives an aligned DKIM pass from Microsoft 365 or Google Workspace, review every legitimate source under p=none, stage p=quarantine, then move to p=reject. Do not depend on pct for percentage-based enforcement. Keep monitoring after enforcement because connector or domain changes can break authentication later.
