Why B2B Invitation Emails Fail DMARC (Jan 2026 Change)

Why Entra B2B Invitation Emails Fail DMARC After Microsoft's January 2026 Change

When an external user can't accept a B2B collaboration invitation because the invitation email itself got rejected - that's a DMARC problem. Specifically, it's a problem Microsoft's January 2026 sender change created for every Entra tenant that enforces strict DMARC on incoming mail.

The failure looks like this: a recipient's mail system rejects the invitation during SMTP delivery with a message like "553 5.7.23 STOREDRV.Submit; invalid sender" or a DMARC policy rejection. The admin investigating sees nothing wrong with their Entra configuration - everything worked fine last month. What changed is how Microsoft sends B2B invitation emails.

What Microsoft Changed in January 2026

Before January 2026, B2B invitation emails from Microsoft 365 appeared to come from sender domains Microsoft controlled. Microsoft had proper SPF and DKIM configured on those domains, so even if your tenant had a strict DMARC policy, the invitation emails passed authentication without issue.

Microsoft changed this. B2B invitation emails now align to your tenant's domain - the From address shows your domain, not Microsoft's. This matters because DMARC checks the alignment between the domain in the From header and the domains that passed SPF or DKIM.

If your tenant domain is `contoso.com` and the B2B invitation now arrives with a From header of `invitations@contoso.com`, the receiving mail system checks whether `contoso.com` passes SPF and DKIM. If Microsoft is relaying the message but `contoso.com` doesn't have SPF include for Microsoft's relay IPs and doesn't have DKIM signing configured for this sending path, both SPF and DKIM fail alignment - and your DMARC policy of `p=reject` rejects the message.

Why This Causes DMARC Failures

DMARC has three ways to pass authentication:

SPF alignment - the domain in the From header matches the domain that passed SPF

DKIM alignment - the domain in the From header matches the domain that passed DKIM

Both

When Microsoft sent from its own domains, the From header and the sending infrastructure were both Microsoft's. SPF and DKIM aligned automatically.

After the change, the From header is your domain. But Microsoft is sending on your behalf, from IP addresses Microsoft controls, using an envelope sender structure that may not align with your SPF record. And depending on your DKIM configuration, Microsoft may not be signing B2B invitation traffic with a DKIM signature that aligns to your domain.

The result: SPF none, DKIM none, DMARC fail. And if your policy is `p=reject`, the message gets rejected at SMTP delivery - before it even reaches the recipient's inbox.

You can confirm this is happening by looking at your DMARC aggregate reports. The failing source IPs will be Microsoft's relay infrastructure (typically in the 52.100.0.0/15 or similar ranges), and the aligned domain will be your tenant domain. Both authentication results will show as "fail."

Available Workarounds

None of these are automatic - Microsoft hasn't provided a configuration flag to revert the sender behavior. The fix is on your side.

Workaround 1: Add Microsoft's Relay IPs to Your SPF Record

Include Microsoft's relay IP ranges in your tenant's SPF record. This lets SPF pass for B2B invitation traffic even though Microsoft is sending on your behalf.

The relevant Microsoft 365 relay IPs are documented in Microsoft's publicly available IP ranges. You would add something like:

v=spf1 include:spf.protection.outlook.com include:microsoft.com ~all

The risk: if your SPF record already has many includes, you may approach or exceed the 10-DNS-lookup SPF limit. Each `include:` mechanism counts as a lookup. Exceeding the limit causes SPF to return `permerror`, which effectively disables SPF checking - the opposite of what you want.

Workaround 2: Configure DKIM for Your Tenant Domain

Microsoft 365 supports DKIM signing for your tenant domain. If DKIM is configured and Microsoft is signing outbound B2B invitation traffic with a key that aligns to your domain, DKIM alignment passes and DMARC passes even with `p=reject`.

To verify this is working:

Check that DKIM is enabled in Microsoft 365 Security settings for your domain

Confirm the DKIM DNS records are published correctly (two CNAME records in your DNS)

Test by sending a B2B invitation to a test external address and examining the authentication results in the message headers

If DKIM isn't configured, set it up - this is the cleanest long-term fix because it makes your domain's email infrastructure trustworthy regardless of which relay Microsoft uses.

Workaround 3: Use a Custom Domain for B2B Invitation Sender Address

Microsoft 365 allows you to specify a custom domain for B2B invitation sender addresses. If you use a subdomain with its own, more permissive DMARC policy (`p=quarantine` or `p=none`), B2B invitation emails sent from that subdomain won't be rejected by strict DMARC enforcement on the receiving side.

This is a tactical workaround - it doesn't fix the underlying authentication gap on your primary domain, but it gets B2B invitations delivered while you work on the full fix.

Workaround 4: Adjust DMARC Policy Temporarily (Not Recommended Long-Term)

If you need immediate relief and the above options aren't ready, you can lower your DMARC policy from `p=reject` to `p=quarantine` as an interim step. This tells receiving mail systems to treat failing mail as suspicious rather than rejecting it outright.

This is not a fix - it's a temporary measure. The real fix is getting SPF or DKIM aligned for your domain's outbound mail, including Microsoft's relay traffic. Set a reminder to revert this before it becomes permanent.

How to Monitor B2B Invitation DMARC Failures

You need DMARC aggregate reports to see this failure pattern. Without them, you won't know how many B2B invitations are being rejected, which domains are rejecting them, or whether your fixes are working.

A DMARC monitoring tool parses your rua reports and surfaces authentication failures by source and domain. For B2B invitations specifically, look for:

Source IPs in Microsoft's relay ranges
Failure counts showing SPF and DKIM both failing
The aligned domain being your tenant domain

If your current DMARC reporting setup requires manual XML parsing or gives you data that's hard to act on, this is the kind of failure pattern that justifies better tooling. The failure is clear, the fix is technical, and the monitoring tells you whether the fix worked.

The Microsoft Situation

Microsoft's messaging team has reportedly told affected admins that this is "not solvable" from Microsoft's side - meaning the sender change is permanent and the mitigation is entirely up to the tenant. There is no planned update to revert to the old behavior.

For organizations with strict DMARC enforcement, this means the work of configuring proper SPF include for Microsoft relay IPs or DKIM signing for tenant domains is now a permanent part of your Microsoft 365 email authentication posture. It's not a one-time project - it's an operational requirement.

FAQ

Can I stop B2B invitations from failing DMARC without changing my domain's DMARC policy?

Yes. The fix is to ensure either SPF or DKIM aligns to your tenant domain when Microsoft sends on your behalf. That means either adding Microsoft's relay IP ranges to your SPF record (if you have room under the 10-lookup limit) or configuring DKIM signing so Microsoft can sign B2B invitation traffic with your domain's DKIM key.

What error do recipients see when this happens?

Typically an SMTP rejection during the delivery attempt - something like "553 5.7.23 STOREDRV.Submit; invalid sender" or a plain DMARC rejection from the receiving system's mail filter. The invitation never reaches the inbox and the external user never knows why they weren't invited.

Does this affect all B2B invitations, or only some?

Any invitation sent after the January 2026 change uses the new sender behavior. Whether it fails depends on the receiving system's DMARC policy. Some receivers accept mail that fails DMARC if the policy is `p=quarantine` or if the failure is on a signal they deprioritize. Receivers enforcing `p=reject` strictly will reject it.

Is lowering my DMARC policy to p=none a valid long-term solution?

No. Running `p=none` means you're collecting reports but not acting on them. It provides no protection against spoofing of your domain. Use it only as a temporary measure while you configure SPF or DKIM alignment, then revert to `p=reject` once your mail is authenticated properly.

Will Microsoft fix this automatically?

Based on Microsoft's stated position, no. The sender change is a configuration decision that affects all Microsoft 365 tenants and is treated as working as designed. The mitigation is the tenant's responsibility.