What Email Signature Services Do to DMARC (And How to Pick One That Does Not Break It)

The Problem

An MSP posted on r/sysadmin about a client who had been hit by recurring email delivery failures traceable to their email signature service, Exclaimer. The pattern was familiar: approximately once per year, Exclaimer routing would break and email would stop flowing entirely. The client wanted a replacement that did not reroute their mail through a third-party SMTP server.

The alternative they were looking for was an API-based solution. That instinct is correct, but for a reason the post did not name: SMTP rerouting breaks DMARC alignment.

The Mechanism

Here is what happens with an SMTP-based signature service.

A user in your Google Workspace domain composes and sends an email. The From header shows your domain (yourdomain.com). Instead of going directly to the recipient's mail server, the email is routed through the signature service's SMTP servers. The signature service injects the email signature and forwards the message on. The From header still shows yourdomain.com.

At the receiving server, the message appears to come from the signature service's IP address, not from your mail servers.

For DMARC alignment to pass, the domain in the From header must match the domain that either passed SPF or signed the message with DKIM. When your outbound mail is rerouted through a third-party SMTP server, the sending IP changes to theirs. Their IP is not in your SPF record. SPF may technically pass for the signature service's server, but because the envelope sender domain may not match your From domain, alignment fails.

The same problem occurs with DKIM. If the signature service signs the message with its own DKIM key rather than yours, the DKIM signing domain (e.g., exclaimer.com) does not match your From header domain (yourdomain.com), and DMARC alignment fails.

Why It Matters for DMARC

When DMARC alignment fails, email receivers treat the message as unauthenticated. With a p=quarantine policy, your legitimate outbound mail gets filtered into spam. With p=reject, it is bounced entirely. This is the opposite of what you want from a signature management tool.

The failure may be intermittent. If the signature service uses multiple IPs and only some of them are properly authorized, your mail may pass DMARC some days and fail on others. Admins see inconsistent delivery and do not immediately connect it to their signature service.

The timing also makes this hard to catch. A signature service can work perfectly for months and then one day a configuration change, a routing update, or a certificate renewal breaks the sending path. By the time you notice, your users have been sending unauthenticated email for hours or days.

How to Diagnose It Using Your DMARC Reports

The first sign is usually not a complete outage. It is an unexplained drop in email delivery that does not correlate with any changes you made.

The most reliable way to catch this is by reviewing your DMARC aggregate reports. If you use a monitoring service like DMARCFlow, look for a pattern of alignment failures from IPs that are not your own mail servers. DMARCFlow breaks down failures by source IP and DKIM selector domain, so if you see a selector domain you do not recognize appearing in your failure reports, that is a signal that a third-party service is in the sending path without proper alignment.

If you see consistent alignment failures from the same non-corporate IPs, a signature service or other mail routing middleware is the most likely cause. Specifically look for:

• Failures where the DKIM selector domain does not match your From domain
• Failures where the envelope return-path domain differs from your From domain
• A volume of failures that stays roughly constant day over day, rather than spiking during incidents

The second clue is particularly useful. If you see alignment failures happening every day at roughly the same volume, the signature service is probably in the sending path and your DMARC policy is silently filtering some of your legitimate outbound mail. You may not be seeing bounces, but some percentage of your mail is being diverted to spam folders without you knowing.

How to Choose a Signature Service That Does Not Break DMARC

API-based signature services work differently. Instead of rerouting your mail through their SMTP infrastructure, they inject the signature at the compose stage via the email provider API. The email is sent directly from your mail servers, not from the provider's servers. SPF, DKIM, and DMARC alignment are unaffected because the sending path has not changed.

When evaluating a signature management tool for Google Workspace, ask these questions before signing up:

1. Does the service require you to change your MX records or add their servers to your SPF record?
2. Does the service sign outgoing mail with its own DKIM key, or does it use yours?
3. Does the service route your outbound mail through its own SMTP servers?

If the answer to any of these is yes, the service will likely interfere with DMARC alignment.

Tools like Exclaimer, when configured in SMTP routing mode, are the most common source of this problem. API-based alternatives like WiseStamp, Signite, or BetterCloud in API mode avoid the issue because they do not take over the sending path.

There is one caveat worth noting. Even with API-based services, verify that the service uses your DKIM selectors rather than its own. Some API services still sign with their own DKIM key when sending on your behalf, which breaks alignment even though the sending IP is correct. Check the service documentation or test with a DMARC lookup before fully onboarding.

What to Do If You Already Have an SMTP-Based Service

If you are already running an SMTP-based signature service and want to tighten your DMARC policy, the sequence matters. Do not switch your DMARC policy to p=reject before switching the signature service to API mode. You will bounce your own outbound mail.

The right order is:

1. Deploy a DMARC monitoring tool like DMARCFlow to establish a baseline


2. Identify the IPs and selector domains used by your current signature service


3. Onboard the API-based replacement and verify it is sending with proper alignment


4. Confirm that your DMARC reports show consistent passing for both your own mail and the new service


5. Tighten your policy to p=quarantine first, then p=reject

FAQ

Will turning on DMARC break my signature service?
If your signature service reroutes mail through its own SMTP servers, a p=quarantine or p=reject policy will likely cause delivery failures for mail sent through that service. Switch to an API-based service first, then tighten your DMARC policy.

Can I use a signature service with p=reject enabled?
Yes, if the service operates in API mode and does not reroute your outbound mail. Verify that the service uses your DKIM selectors and that your DMARC reports show consistent alignment for mail sent through the service.

My signature service was working fine and then suddenly email started failing. What happened?
This is a common pattern with SMTP-based signature services. A configuration change, routing update, or certificate renewal on the service side can break the sending path without any changes on your end. Check your DMARC reports for new alignment failure patterns, and contact the service provider to confirm their sending infrastructure is stable.

Is WiseStamp safe for DMARC?
WiseStamp operates in API mode for Google Workspace, which means it does not reroute your outbound mail through its own servers. However, verify that DKIM signing is handled through your domain's selectors rather than WiseStamp's own selectors before fully enabling a strict DMARC policy.