Provider guide

Microsoft Exchange (On-Premise) DMARC

By Adam W., founder of DMARCit · Last updated 2026-06

On-premise Exchange (2016, 2019, and the new Subscription Edition) does not sign DKIM out of the box. There is no admin checkbox. The platform doesn't validate DMARC on inbound mail unless you install something that does. Every piece of the authentication stack is something you assemble yourself, usually with a third-party transport agent or by routing outbound mail through a smart host that handles DKIM for you. This page is for the on-prem deployment. For the cloud version, see Microsoft 365 DMARC.

On-prem vs Exchange Online: the gap that matters for DMARC

Exchange Online ships DKIM signing as a tenant feature, SRS rewriting for forwarded mail, ARC validation on inbound, and an SPF include (spf.protection.outlook.com) you can drop into a record. Most of the DMARC path is platform-native.

On-premise Exchange ships none of that. The product was designed before DKIM became a deliverability requirement, and Microsoft has chosen not to retrofit native signing into the on-prem builds. That leaves you with three real options for getting DKIM onto outbound mail:

• A transport agent that installs into Exchange and signs DKIM as mail leaves the transport pipeline.
• A smart host that you route outbound mail through (M365 hybrid, SendGrid, Mailgun, Mimecast, Proofpoint) which signs DKIM on your behalf.
• Edge transport rules in front of Exchange (less common; usually paired with one of the above for the signing itself).

None of these are wrong. Which one fits depends on whether you have a hybrid M365 setup already, whether you're comfortable installing third-party transport agents, and whether you have an existing security gateway you can lean on.

Option 1: Transport agent (Exchange DKIM Signer)

The most common open-source choice is Exchange DKIM Signer by Stefan Seyfried, an Exchange transport agent that signs outbound mail with DKIM before it leaves your edge. It installs as a transport agent in the Hub Transport or Edge Transport service, reads a config file for which domains to sign and what selector to use, and signs every outbound message that matches.

Operational shape:

• Generate an RSA 2048-bit key pair offline. Publish the public key as a TXT record at selector._domainkey.yourdomain.com.
• Install the agent on each Hub/Edge Transport server. Drop the private key into the agent's key directory.
• Configure the per-domain signing rules. Most installs want the relaxed/relaxed canonicalization to survive minor whitespace changes downstream.
• Restart the Transport service. Send a test message to an external mailbox and verify the DKIM-Signature header is present and validates.

Two things to watch. First, the agent has to be installed on every transport server in the routing path. A new server brought up without the agent will send unsigned mail and trip alignment failures. Second, Exchange Cumulative Updates can break third-party transport agents. Read the agent's changelog and the CU release notes together before patching.

Option 2: Smart host that handles DKIM

If you already have an outbound smart host (an M365 hybrid configuration, a gateway like Mimecast or Proofpoint, or a transactional sender like SendGrid or Mailgun set up for relay), let it handle DKIM. The Exchange side sends authenticated SMTP to the smart host; the smart host signs DKIM with a key you control before mail leaves to the internet.

The trade-off: the smart host introduces a hop where headers can be rewritten, encoding can shift, and any DKIM signature applied by an upstream component (rare for on-prem Exchange but not impossible) may not survive. Test end-to-end with an external mailbox before you trust the configuration.

In hybrid M365 setups specifically, the platform-native DKIM signing on the Exchange Online side is the easiest path. Route outbound through M365, enable custom DKIM in Exchange Online (see the M365 spoke for the CNAME setup), and let Microsoft sign for you.

SPF for on-premise Exchange

List your Exchange edge IPs explicitly. The pattern:

v=spf1 ip4:203.0.113.10 ip4:203.0.113.11 -all

Avoid the mx mechanism. It counts as a DNS lookup against the 10-lookup ceiling in RFC 7208, and it pulls in every MX-listed host for your domain, which usually includes inbound-only systems you don't want authorized to send. ip4: mechanisms are zero-lookup and explicit.

If you're running M365 hybrid and some mail flows out through Exchange Online, add the Microsoft include too:

v=spf1 ip4:203.0.113.10 ip4:203.0.113.11 include:spf.protection.outlook.com -all

The include adds 2 to 5 lookups depending on the day. Add a marketing platform or a transactional sender and you can blow through the 10-lookup budget quickly. SPF PermError walkthrough for the fix.

Hybrid topology gotchas

Hybrid Exchange/M365 setups are where DMARC alignment quietly breaks. A few recurring patterns:

Split-domain DKIM

Some users' mail goes out through M365 (signed with the M365 custom DKIM key), other users' mail goes out through the on-prem edge (signed by the transport agent, or not signed at all). If the two systems use different selectors or different keys, both signatures need to be valid in DNS, and both need to align. If on-prem signs nothing, mail from on-prem users fails alignment whenever SPF also fails (forwarded mail, third-party intermediaries).

SRS in hybrid routing

Exchange Online uses Sender Rewriting Scheme (SRS) on forwarded mail. On-prem Exchange does not. In a hybrid where mail flows on-prem → M365 → external, M365 may apply SRS that rewrites the Return-Path to a Microsoft-owned address. SPF then passes at the next hop but aligns with Microsoft's domain rather than yours. DMARC alignment via SPF is lost. The mitigation is the same as any forwarding scenario: rely on DKIM, not SPF, for alignment.

Outbound through edge vs outbound through M365

Hybrid setups can be configured to route outbound directly from on-prem to the internet (preserving on-prem control) or through M365 (centralizing security policy in Exchange Online). The DKIM signing implications differ. Direct-from- on-prem requires you to handle DKIM on-prem. Through-M365 lets you use the tenant's custom DKIM. Pick one path per domain and document which it is.

Edge transport rules and inbound DMARC handling

On-prem Exchange doesn't natively validate DMARC on inbound mail. To get inbound DMARC enforcement, you need either:

• A security gateway in front of Exchange (Mimecast, Proofpoint, Cisco IronPort, Microsoft Defender for Office 365 in hybrid mode) that performs DMARC validation and adds headers or modifies SCL based on the result.
• Transport rules that key off the Authentication-Results header added by your inbound gateway, raising SCL or routing to spam quarantine when DMARC failed.
• Third-party transport agents that perform DMARC validation in the Exchange transport pipeline directly.

Without one of these, inbound spoofing protection at on-prem Exchange is limited to sender filtering, recipient filtering, and content filtering, none of which are a DMARC enforcement substitute.

Failure modes specific to on-prem Exchange

Split-domain hybrid where on-prem mail is unsigned

The most common: a hybrid environment where the M365 side has custom DKIM enabled and the on-prem side has nothing. Aggregate reports show DMARC pass rates that vary by sender IP. M365-sourced mail passes; on-prem-sourced mail fails. The fix is to install a signing agent on-prem, or to route on-prem outbound through M365 so Exchange Online does the signing.

Journaling and inspection appliances modifying the body

DKIM signs a hash of the message body. Any byte change after signing breaks the hash, and DKIM fails with body hash did not verify. Journaling systems, DLP appliances, archiving solutions, and content-inspection gateways between the signing point and the recipient can all modify the body in ways that defeat DKIM: appending disclaimers, normalizing line endings, decrypting and re-encrypting attachments. The signing point needs to be the last touch before the message leaves your infrastructure. DKIM body hash failure walkthrough.

Disclaimer transport rules breaking body hash

A common Exchange transport rule appends a legal disclaimer to outbound mail. If the rule runs after DKIM signing, the appended text changes the body and breaks the hash. If the rule runs before signing, the disclaimer is included in the signed content, which usually works. The order of operations in the transport pipeline matters. Test both before assuming.

Transport agents that don't survive Exchange CUs

Cumulative Updates can change transport agent APIs in ways that break third-party agents. After every CU, send a test message to an external mailbox and verify DKIM is still present. Don't wait for an aggregate report two weeks later to discover the signer stopped working.

Misconfigured edge transport SPF

An Exchange Edge Transport server with the wrong outbound IP listed in SPF will fail SPF on every outbound message. Common in NAT setups where the outbound public IP differs from the host IP, or in failover configurations where a secondary IP gets used without being in the SPF record.

Inbound DMARC not validated at all

Without a gateway or agent that validates DMARC on inbound, your organization is still publishing DMARC for outbound protection but accepting spoofed inbound mail from other domains as if their DMARC records didn't exist. The spoofing protection is one-way until you install something that reads inbound DMARC results.

The minimum DMARC record for on-premise Exchange

Once outbound DKIM is signing (via agent or smart host) and SPF lists your edge IPs cleanly, publish DMARC. Start in monitoring mode:

_dmarc.yourdomain.com  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; sp=none; adkim=r; aspf=r"

Watch the aggregate reports for at least two weeks (longer for complex hybrid environments where mail flows split across paths). Identify every sender that fails alignment. Fix them one at a time, starting with the highest-volume failures. Then move to p=quarantine with pct=10, ramp gradually, and move to p=reject once you're confident every legitimate path passes.

The standard path through enforcement is in What is DMARC? The on-prem work above is what makes that path realistic when you don't have a platform handling DKIM for you.

Where on-prem Exchange admins get stuck

• No DKIM signing at all: The admin publishes a DMARC record without realizing on-prem Exchange isn't signing anything. Aggregate reports show 100% DKIM failure across the board.
• Transport agent installed on only one server: A multi-server Hub Transport deployment where the agent was rolled out to one box. Mail routed through the unsigned server fails DKIM intermittently.
• Disclaimer rules running after signing: The legal disclaimer gets appended after DKIM signs the body. DKIM body hash fails on every message. Reorder the transport pipeline or include the disclaimer in the signed content.
• Hybrid with split DKIM: M365 mail is signed, on-prem mail is not. Aggregate reports look healthy in aggregate but show high failure rates for the on-prem sender IPs specifically.
• SPF using mx mechanism: The record uses mx instead of explicit ip4: entries, pulling in inbound-only MX hosts that shouldn't be authorized senders.
• Inbound DMARC ignored: Outbound is protected; inbound spoofing from other domains is not. Until a gateway or transport agent validates inbound DMARC results, the protection is one-way.

How on-prem Exchange connects to the rest of the stack

• Microsoft 365 DMARC covers the cloud version. If you're hybrid, both pages are relevant.
• DMARC ties SPF and DKIM together with policy and reporting. Read the policy mechanics first if they're unfamiliar.
• DKIM is the path that matters most on on-prem Exchange. Without native signing, everything else is a workaround.

Related content