Why third-party email fails DMARC in Microsoft 365

The symptoms

• Your DMARC reports show a sending service, such as SendGrid, Mailchimp, Salesforce or Zendesk, failing DMARC even though SPF or DKIM shows "pass".
• After moving to p=quarantine or p=reject, invoices, newsletters, password resets or support replies start landing in spam or bouncing.
• Recipients see "via" or "on behalf of" next to your name, or a warning that the sender couldn't be verified.

Why it happens: alignment

Every email has two sender addresses. The From address is the one people see. The Return-Path (envelope sender) is a hidden address used for bounces. SPF checks the Return-Path domain, and DKIM checks the domain in the signature (d=).

DMARC passes only when at least one of those checks passes for a domain that matches the From domain. Here's a typical newsletter sent through a third-party service:

Both checks passed, but for the service's domain. DMARC can't tell this message apart from a spoofed one, so it fails. The fix is to make at least one check pass for your domain, and ideally both.

Find your third-party senders

Before you fix anything, find everything. Publish a DMARC record with p=none and a reporting address (see our DMARC setup guide), then collect a few weeks of reports. Open them in the free DMARC Report Analyzer and list every source that isn't Microsoft 365.

Then ask each department what tools they use. Common senders people forget:

Fix 1: Set up DKIM for your domain in the service (best)

Almost every reputable sending service can sign email with your domain instead of theirs. They usually call it domain authentication, sender authentication or custom DKIM.

1. In the service's settings, find the domain or sender authentication section and add your domain.
2. The service gives you DNS records to publish, usually two or three CNAME records, or a TXT record containing a public key.
3. Publish them at your DNS host, then verify in the service.
4. Send a test message and check the headers for dkim=pass with header.d= your domain. Our Email Header Analyzer shows whether it's aligned.

DKIM is the most reliable fix, because the signature survives forwarding, while SPF doesn't.

Fix 2: Use a custom return-path (SPF alignment)

Some services also let you use your own subdomain as the Return-Path, for example bounce.contoso.com, usually by publishing a CNAME record they provide. SPF then passes for a domain aligned with yours. This is a useful backup to DKIM, especially for services that can't sign with your domain.

Fix 3: Send from a subdomain

Microsoft recommends sending bulk and third-party email from a subdomain, such as news.contoso.com for newsletters or billing.contoso.com for invoices. This:

• Keeps a marketing tool's reputation problems away from your main domain, which your staff use for everyday email.
• Gives each subdomain its own SPF record, with its own 10-lookup budget.
• Lets you enforce DMARC on your main domain sooner, and tighten each subdomain on its own schedule.

You still need DKIM or a custom return-path for the subdomain. A subdomain without its own DMARC record follows the main domain's policy.

What about adding the service to SPF?

Many services tell you to add their include: to your SPF record. That's often not enough for DMARC, because most services use their own domain as the Return-Path. SPF then checks their SPF record, not yours.

• Adding the include: only helps when the service sends with your domain (or a custom return-path on your domain) as the Return-Path.
• Every include: uses DNS lookups. Go over 10 and SPF fails for all your email, including Microsoft 365.
• Remove includes for services you no longer use.

Special cases in Microsoft 365

Apps and devices that send through Microsoft 365

Scanners, line-of-business apps and websites that submit email through your Microsoft 365 tenant, using an authenticated mailbox or a connector, are covered by Microsoft 365's SPF and DKIM. Devices or apps that send directly to the internet from your own IP address aren't. Add that IP to SPF with ip4:, or route the mail through Microsoft 365.

Services that process your outgoing mail

Email signature tools, disclaimers and outbound security gateways can change a message after Microsoft 365 signs it, which breaks DKIM. If they deliver mail directly to recipients, they also need to be covered by SPF. Prefer services that return mail to Microsoft 365 for final delivery, or that sign with your domain themselves.

A security gateway in front of your mailboxes

If incoming mail passes through a third-party gateway or filter before reaching Microsoft 365, the gateway can change messages and cause legitimate senders to fail DMARC at Microsoft 365. Microsoft recommends adding the gateway as a trusted ARC sealer: in the Defender portal, go to Email authentication settings → ARC and add the gateway's signing domain (the d= value in its ARC-Seal header). Note that while your MX record points to a gateway instead of Microsoft 365, Microsoft 365 doesn't send DMARC reports about the mail your organization receives.

Forwarding and mailing lists

When a message is forwarded, SPF is checked against the forwarding server, so it no longer aligns with the original sender. DKIM usually survives forwarding, as long as the message isn't changed, which is another reason to set up DKIM for every service.

Checklist before you move to p=reject

• Every legitimate source in your DMARC reports passes DMARC, preferably with aligned DKIM.
• Each third-party service has domain authentication (custom DKIM) set up and verified.
• Your SPF record is a single record, stays under 10 DNS lookups, and only includes services you still use.
• You've collected at least two to four weeks of clean reports at p=quarantine.
• Someone is responsible for reviewing reports after enforcement, so new tools are caught before their email bounces.