Exchange Server DKIM Setup: On-Premises Configuration

Exchange Server has shipped without native DKIM signing for over a decade. Microsoft added it to Exchange Online (Microsoft 365) but never backported it to the on-prem product, including the current Exchange Server Subscription Edition. If you're sending mail from on-prem Exchange and need DKIM (and after the Gmail/Yahoo bulk sender requirements, you almost certainly do), you have three viable paths.

This guide covers all three, with detailed setup for the most common: the Exchange-DkimSigner transport agent.

Three ways to sign DKIM from Exchange Server

Approach	Best for	Tradeoffs
Exchange-DkimSigner transport agent	On-prem only, full control	Free, open source, requires per-server install and updates
Route outbound via Exchange Online Protection	Hybrid environments	EOP handles signing; cleaner key rotation; licensing cost
Route outbound via third-party smart host (Proofpoint, Mimecast, etc.)	Already paying for a security gateway	Vendor handles signing; consolidates other policies

If you're already paying for EOP or a security gateway, use them. If you're pure on-prem with no smart host, the transport agent is the standard path.

Installing Exchange-DkimSigner

The maintained fork is Configuration.DkimSigner / Exchange-DkimSigner on GitHub. It supports Exchange 2007 through Subscription Edition.

Prerequisites

• Local administrator on each Exchange transport role server
• An Exchange management session with sufficient role assignments
• A maintenance window (the Transport service restarts)
• DNS edit access for the sending domain

Step-by-step

1. Download the latest signed installer from the Configuration.DkimSigner releases page.
2. Run the installer on every server that has the Hub Transport or Mailbox role. Do not skip any — unsigned mail from an unconfigured server will fail DMARC at the receiver.
3. Open the configuration UI (Start → Exchange DkimSigner Configuration).
4. For each accepted domain, click "Configure" and set:
   • Selector (e.g., exchange2026, ex01, or selector1 — see naming notes below)
   • Key length: 2048 bit RSA
   • Header canonicalization: relaxed
   • Body canonicalization: relaxed
   • Algorithm: rsa-sha256
5. Generate the key pair. Save the public key — you'll publish it as a DNS TXT record.
6. Restart the Microsoft Exchange Transport service:

   Restart-Service MSExchangeTransport
   

DNS record format

Publish the public key at <selector>._domainkey.<yourdomain>.com as a TXT record. The value:

v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCg...truncated...

For 2048-bit keys, the value exceeds 255 characters and DNS providers split it into chunks. Use your DNS provider's UI — most handle the chunking automatically. See DKIM key length and DNS limits for the chunking detail.

Verify

After DNS has propagated (5 to 30 minutes typically):

nslookup -type=TXT exchange2026._domainkey.yourdomain.com

Send a test message to a Gmail or Outlook recipient, open headers, and confirm:

• dkim=pass in the Authentication-Results header
• d=yourdomain.com matching the From: domain

Aligning DKIM for DMARC

DKIM authentication passing is not enough — for DMARC to pass, the signing domain (d= tag in DKIM-Signature) must align with the From: header organizational domain.

Two alignment modes:

Mode	Meaning	Use when
Relaxed (default)	Organizational domain must match	Most senders, including subdomain signing
Strict	Exact domain must match	Only when explicitly required

For most Exchange deployments, configure the agent to sign with the same domain users send from. If [email protected] sends, the d= should be marketing.acme.com or acme.com (with relaxed alignment). See DKIM alignment explained for full detail on the alignment rules.

Practitioner note: The most common Exchange-DkimSigner misconfiguration I see is one selector configured for the primary domain and nothing configured for accepted alias domains. Mail from the alias ships unsigned. Configure every accepted domain individually, even if they share a sending pool.

Key rotation

Rotate DKIM keys at least annually. Microsoft recommends every 6 to 12 months. The procedure:

1. Generate a new key pair in the DkimSigner UI under a new selector (e.g., increment from ex2026a to ex2026b).
2. Publish the new public key TXT record in DNS at the new selector.
3. Wait 24 to 48 hours for DNS propagation.
4. In the DkimSigner UI, switch the active selector to the new one.
5. Restart MSExchangeTransport on each server.
6. After 7 days (enough for in-flight mail to clear), remove the old public key from DNS.

The DKIM key rotation guide walks through the full procedure including verification at each step.

Selector naming

Selectors are arbitrary strings. Common patterns:

• selector1, selector2 (Microsoft's convention)
• default, mail, key1
• Date-based: s202605, exchange-2026-05
• Server-based: ex01, ex02 (if signing per-server, rare)

Avoid:

• Periods in the selector name (DNS-legal but adds confusion)
• Generic terms that clash with EOP if you later move to hybrid

Practitioner note: Date-based selectors make rotation easier to reason about. When troubleshooting why a message failed authentication, you can tell at a glance which key version signed it.

Common Exchange DKIM problems

Mail signs locally but fails at the receiver. Usually a DNS propagation issue or a malformed TXT record (line breaks in the wrong place, missing v=DKIM1 prefix). Use MXToolbox DKIM Lookup to verify the published key parses correctly.

Some mail signs, some doesn't. Almost always means one of your transport role servers doesn't have the agent installed or doesn't have the domain configured. Check each.

Signed but DMARC still fails. Alignment problem. Check the d= against the From: header organizational domain.

Service won't start after install. Usually a .NET runtime or Exchange version mismatch. Check the installer log; the project documentation lists compatible Exchange versions per release.

See DKIM verification failed and common DKIM failures for the troubleshooting tree.

When to abandon on-prem DKIM signing

If you're maintaining Exchange Server 2016 in a small environment and the DKIM agent is your only remaining customization, consider routing outbound through Exchange Online Protection at $1/user/month. EOP handles signing, MTA-STS, TLS, and rotation. The math usually works in favor of EOP for under 500 users.

For larger environments where outbound smart-hosting changes other dependencies, the transport agent remains the pragmatic choice.

If you need help configuring DKIM signing for on-prem Exchange — or migrating outbound flow through EOP without breaking existing transport rules — book a consultation. I configure Exchange transport and Exchange Online hybrid setups for organizations every month.

Sources

• Microsoft Learn — Configure DKIM to Sign Mail from Your Microsoft 365 Domain
• Configuration.DkimSigner on GitHub
• RFC 6376: DomainKeys Identified Mail Signatures
• RFC 8301: Cryptographic Algorithm and Key Usage Update to DKIM
• Microsoft — Mail Flow Best Practices for Exchange Online
• M3AAWG DKIM Key Rotation Best Practices

---

v1.0 · May 2026