My Third-Party Emails Bounce from Microsoft 365

Your Microsoft 365 tenant is rejecting email from a third-party vendor. The vendor says they have DKIM configured. Microsoft says the signature is missing. The vendor tells you to check your end. You check your end, your DKIM records are fine. The vendor is still sending.

This is one of the most common silent deliverability failures in Microsoft 365 environments. Mail does not get quarantined or flagged. It just disappears into NDRs or silent failures. A vendor's DKIM configuration can break the moment they change sending infrastructure or rotate keys, without telling anyone, and you only find out when someone reports a missing invoice.

Here is the actual technical explanation of why it happens and exactly whose responsibility each fix is.

How Microsoft 365 Validates DKIM

When an email arrives at Microsoft 365 from an external sender, Exchange Online Protection runs DKIM validation in this order:

1. Microsoft looks up the DKIM selector record for the sender's claimed domain. The selector is found in the DNS TXT record at `selector1._domainkey.yourdomain.com` (or `selector2._domainkey.yourdomain.com`). 2. That record points to the public key published by whoever is actually signing the email. 3. Microsoft uses that public key to verify the DKIM cryptographic signature in the email headers. 4. If the selector record does not exist, or if the signature does not match the public key, DKIM fails.

The critical detail: the DKIM selector record must point to the key that is actually signing the mail. Not just any DKIM key for the domain, the specific key used by the specific system sending the message. When a vendor's DKIM key breaks and your DMARC reports show failures, to read XML reports you need aggregate reports from a DMARC provider like DMARCFlow that catches the spike before users start complaining about missing mail.

Why Vendor Emails Commonly Fail This Check

The most common failure mode is a configuration where the vendor sends mail from their own mail infrastructure but uses your domain in the From: header. Here is what goes wrong:

The vendor's mail system signs the email using their own DKIM key. Their DKIM selector record points to their public key, published under their domain.

Your Microsoft 365 DKIM selector record points to the Microsoft-published public key for your domain.

Microsoft looks up your selector record and finds Microsoft's public key. It tries to verify the vendor's DKIM signature against Microsoft's public key. The signature does not match. DKIM fails.

The vendor sees DKIM as "configured." Your Microsoft 365 tenant sees a missing DKIM signature. Both are correct. Neither is talking about the same key.

The Three Most Common Vendor DKIM Misconfigurations

Misconfiguration 1: Vendor sends from their own infrastructure, uses your From: domain

This is the most common broken setup. The vendor's mail system sends from `support@yourdomain.com`, but the actual sending infrastructure belongs to the vendor. The DKIM signature uses the vendor's domain as the "d=" value, not your domain. When Microsoft 365 checks DKIM alignment against your domain's selector record, it fails because the signing domain does not match the From: domain.

Misconfiguration 2: Vendor has DKIM enabled - but for their own domain, not yours

Some vendors enable DKIM for their own sending domain in their own control panel. This helps their own deliverability but does nothing for mail sent from your domain. The DKIM signature d= value is the vendor's domain, not yours. Microsoft 365 never looks up the vendor's DKIM selector in this case, it looks up yours, finds Microsoft's key, and rejects the signature.

Misconfiguration 3: M365 DKIM is enabled and taking precedence

If you have Microsoft 365 DKIM turned on for your domain, Microsoft publishes DKIM records for your domain and expects all outbound mail to be signed with Microsoft's key. When a third-party vendor sends mail without using Microsoft's DKIM infrastructure, their signature is validated against Microsoft's selector record and fails. M365 DKIM effectively overrides any external DKIM configuration unless M365 DKIM is explicitly disabled for that domain.

How to Diagnose Which Side Is Failing

Before pointing fingers, pull the message headers from a bounced or rejected message. Look for the `Authentication-Results` header. It will look something like this:

``` Authentication-Results: spf=fail (sender IP is xxx.xxx.xxx.xxx) smtp.mailfrom=vendor.com; dkim=fail (signature did not verify) header.d=yourdomain.com; dmarc=fail (p=reject) header.from=yourdomain.com ```

The key field is `header.d=yourdomain.com`. This tells you that Microsoft is validating DKIM against your domain's selector record. The `dkim=fail` means the signature did not verify against that selector.

Now run these checks:

Check 1: Is M365 DKIM enabled? In Exchange Online PowerShell: ```powershell Get-DkimSigningConfig -Identity yourdomain.com ``` If `Enabled` is True, Microsoft is publishing DKIM records for your domain. Any vendor sending from your domain must either use Microsoft's DKIM signing or have M365 DKIM disabled.

Check 2: What DKIM selector record actually exists in DNS? ```bash dig TXT selector1._domainkey.yourdomain.com ``` If the answer shows a Microsoft-published key (look for a base64-encoded blob that Microsoft generated), your M365 DKIM is active. If the record points elsewhere or does not exist, check with your vendor.

Check 3: What selector record is the vendor publishing? Ask the vendor which selector record they published for your domain. They should be able to give you the full selector name (for example, `selector1._domainkey.yourdomain.com`) and the public key they published there. Run a DNS lookup on that record to confirm it exists.

Check 4: Does the vendor's selector record match what they are actually signing with? If the vendor says they published a DKIM record for your domain but DNS does not show any record for `selector._domainkey.yourdomain.com`, the vendor's configuration is incomplete; regardless of what their control panel says.

Who Fixes What

This is where most threads fall apart: both sides claim the other is responsible. Here is the actual breakdown.

If the vendor is sending from their own infrastructure and you want them to keep doing that:

The vendor must publish a DKIM public key for your domain under a selector record they control. You then add a CNAME record in your DNS pointing `selector1._domainkey.yourdomain.com` to the vendor's selector. Microsoft 365 follows the CNAME, finds the vendor's public key, and verifies the signature. This is the cleanest path when the vendor's infrastructure cannot change.

Alternatively, the vendor can sign using your domain's DKIM key directly, meaning you generate the DKIM key pair, give the private key to the vendor, and publish the public key in your DNS yourself. This requires the vendor to accept and correctly implement your key, which many vendors will not do for security reasons.

If M365 DKIM is interfering and the vendor cannot change their setup:

You can disable M365 DKIM for your domain: ```powershell Set-DkimSigningConfig -Identity yourdomain.com -Enabled $false ``` Once M365 DKIM is disabled, your custom DNS DKIM selector record (published by the vendor or set up manually) takes precedence. Microsoft 365 will no longer expect Microsoft's own DKIM key for your domain.

Note: disabling M365 DKIM means Microsoft no longer signs outbound mail from your tenant with Microsoft's key. If you have other senders relying on M365 DKIM signing, those will break. Make sure you understand your full sending picture before turning it off.

If neither side can or will change their configuration:

Use a mail gateway or email security product that can re-sign mail on behalf of your tenant. "Products like Proofpoint, IronPort, or Microsoft Defender for Office 365 (with SMTP routing through connectors) can accept mail from the vendor, validate it, and re-sign it with your domain's DKIM key before delivery into Microsoft 365