Microsoft Now Rejects Outlook Email Outright, Not Junks It. The Customer.io Authentication Audit Most Senders Have Skipped

On 11 September 2025, a sender posted into the Microsoft Tech Community thread on Outlook's bulk-sender enforcement. Their setup looked clean. SendGrid as the ESP, a dedicated IP, SPF, DKIM and DMARC all in place, DKIM-aligned with the visible From domain. At 9.45am their message hit Outlook inboxes. At 12.45pm the same message was rejected with 550 5.7.515 Access denied. The difference between the two attempts was a forwarder at one.com routing mail into an Office 365 mailbox. SPF failed on the forwarded leg. Microsoft's new policy treated the failure as a permanent reject, not a soft fail to junk (Microsoft Tech Community thread, September 2025 comment).

That's the new normal at outlook.com, hotmail.com, live.com and msn.com. Authenticated, well-meaning senders are losing legitimate volume because Microsoft moved the goalposts on 5 May 2025 and most teams haven't audited their setup since. If you send to Microsoft consumer mailboxes through Customer.io, the rest of this post is the audit recipe.

This post walks through the seven checks specific to Customer.io's sending infrastructure, shows where each one lives in the UI, and finishes with a worked example of debugging a 5.7.515 bounce from a Customer.io broadcast. The reader leaves with a checklist they can apply in thirty minutes.

What Microsoft started rejecting on 5 May 2025

Microsoft hard-rejects with 550 5.7.515 Access denied for any domain sending more than 5,000 emails per day to consumer Outlook addresses (outlook.com, hotmail.com, live.com, msn.com). The trigger conditions: failed SPF, DKIM or DMARC alignment, or no functioning unsubscribe. The policy was announced on 2 April 2025 and took effect on 5 May 2025 (Microsoft Defender for Office 365 Blog, April 2025).

Two things are different from what came before. First, the failure mode is a hard reject, not a junk-folder placement. Your sending stats look healthy at the ESP layer because the message left Customer.io. The receiving server simply refused it. Second, the 5,000/day threshold is measured per sending domain across all consumer Outlook destinations, not per ESP, not per IP. A broadcast that hits 6,000 outlook.com subscribers from a single From domain is in scope. So is a transactional flow that drips 50 emails an hour out of a marketing domain.

Microsoft's stated grace period was about giving senders time to clean up. That grace period is over. The Tech Community announcement has picked up nearly a hundred comments through May 2026, mostly from senders who only just noticed the silent volume cliff (Microsoft Tech Community thread, comment timeline).

Why this catches Customer.io senders specifically

Customer.io covers SPF and DKIM by default when you connect a domain. The defaults are sound. What catches teams out is the gap between "the ESP says I'm authenticated" and "Microsoft says I'm aligned".

Three patterns trip up Customer.io accounts more than other ESPs.

First, custom From domains. Customer.io lets you send from any verified domain, which is the right design. But the workspace-level setup screen verifies SPF and DKIM independently. It doesn't tell you whether your DMARC record is published, whether it aligns with the visible From domain, or whether your CIO-managed DKIM selector matches what Microsoft expects to see. Microsoft checks all three. Customer.io's UI checks two (Customer.io sender authentication docs).

Second, shared sending IPs. If you're on Customer.io's shared pool—which most accounts under a million sends a month are—your reputation is partly your own, partly a neighbour's. DMARC alignment is the only way Microsoft tells your traffic apart from a noisy neighbour. Shared IPs amplify the cost of an alignment failure.

Third, the migration window. Teams porting from another ESP usually copy the SPF include line and the DKIM keys, then forget about DMARC because the old ESP "just worked". Authentication is the most-skipped step during a Customer.io migration. If you migrated in the last twelve months and haven't audited the DNS since, this post is for you.

If you want a refresher on the foundations of email authentication, start there. The audit below assumes you know what SPF, DKIM and DMARC are.

The seven-step Customer.io authentication audit

Each step takes about three minutes. Total: thirty minutes, end to end. You'll need DNS access for your sending domain and Workspace Admin in Customer.io.

1. SPF: confirm authorised hosts in your DNS record

Open your domain's DNS and pull the TXT record at the root. Look for v=spf1. It must include include:_spf.customer.io (or the legacy include:mail.customeriomail.com, depending on when you set up). Run dig txt yourdomain.com from a terminal, or paste the domain into MXToolbox. You want a single SPF record that ends in ~all or -all. Multiple SPF records on the same host is a fail by spec, not just by Microsoft.

Common gotcha: a record that includes Mailchimp, SendGrid, Google Workspace and Customer.io will exceed SPF's ten-DNS-lookup limit. Microsoft treats that as a permanent fail. Flatten the record with a tool like dmarcian's SPF surveyor or drop unused includes.

2. DKIM: verify CIO is signing for the visible From domain

In Customer.io, open Workspace Settings → Sending Domains. For each verified domain, the DKIM record should show a green tick. Now open your DNS and find the TXT record at cio1._domainkey.yourdomain.com (the selector might differ on older accounts). Confirm it matches Customer.io's published value.

The detail that matters for Microsoft is alignment. The DKIM signature d= value must match the visible From domain. If your From is [email protected] but the DKIM signature is d= a Customer.io-owned host, you've signed correctly but you've failed DMARC alignment. Customer.io's default custom-domain setup gets this right. It only breaks if someone changed the From domain in the campaign without updating the sending domain configuration.

3. DMARC: at minimum p=none with aligned SPF or DKIM

Look up _dmarc.yourdomain.com. You want a TXT record starting with v=DMARC1. The minimum that satisfies Microsoft is p=none. The minimum that satisfies you, eventually, is p=quarantine or p=reject. Start at none, collect reports for thirty days, then move to quarantine.

A few specifics. Add a rua= reporting address so you get the aggregate XML reports back. Free parsers like dmarcian's community edition or Postmark's DMARC Digests will read them. If you publish DMARC without a reporting address, you're flying blind. And if you've never published DMARC at all, your domain is wide open to spoofing—which is a separate problem, but the Microsoft policy at least forces the conversation.

If you're using DMARC reports to push towards BIMI, take a look at the honest cost-benefit on BIMI for SMBs before you spend on a Verified Mark Certificate. For sub-50,000-a-month senders, the maths usually doesn't work.

Customer.io's DMARC guide walks through publishing the record (Customer.io DMARC docs). Stick to its defaults.

4. From P2 address: must reflect the sending domain and be reply-able

The P2 From address is what the recipient sees. Microsoft's policy requires it to use a valid, reply-able mailbox on a domain that matches the authenticated sending domain. In Customer.io, this is set per workspace under Workspace Settings → Sender Defaults, and overridable per campaign.

Two bear traps. One: [email protected] is technically reply-able if the mailbox exists. If you've configured noreply@ to bounce, you fail. Set it to discard silently or auto-respond. Two: a campaign-level override that uses a non-authenticated From domain will fail Microsoft's alignment check even if the workspace default is correct. Audit each active campaign individually.

5. One-click unsubscribe header (RFC 8058) in Customer.io

Microsoft requires the List-Unsubscribe header in the form RFC 8058 specifies, and it requires the one-click POST variant, not just the mailto. Customer.io added native support for this in 2024 and turned it on by default for new workspaces.

For older workspaces, check Workspace Settings → Email Settings → Unsubscribe. The toggle is called "One-click unsubscribe (List-Unsubscribe-Post header)". If it's off, switch it on. Then send a test campaign to a personal Outlook account, view the source, and confirm both List-Unsubscribe and List-Unsubscribe-Post: List-Unsubscribe=One-Click are present (Customer.io List-Unsubscribe header docs).

A working header isn't the same as a working unsubscribe flow. The endpoint Customer.io posts to must actually suppress the recipient. Test it. If you've built a proper subscription centre, confirm the one-click POST removes the recipient from all relevant lists, not just the campaign-specific one. Partial suppression is worse than none—the recipient will mark you as spam the next time you send, and Microsoft uses complaint rates as a separate signal.

6. Forwarding edge case: ARC and SRS-aware forwarders

This is the one that bit the September 2025 sender from the intro. Their authentication was fine. The forwarder broke SPF on the hop into Office 365. ARC (Authenticated Received Chain) is the spec that lets a forwarder cryptographically vouch for the original authentication state. SRS (Sender Rewriting Scheme) rewrites the envelope sender to keep SPF aligned at the new hop. If your audience uses forwarders like one.com, Verisign's .name forwarder, or older university aliases, the forwarder may implement neither.

You can't fix the forwarder. What you can do is publish DMARC with a relaxed alignment mode (adkim=r, aspf=r), which gives the forwarder's modification a better chance of still aligning at the receiver. Microsoft also gives ARC-signed forwarded mail more benefit of the doubt than unsigned. There's no Customer.io setting for this—it's purely DNS.

If you see a pattern in your bounces where the same recipient was fine yesterday and broken today, suspect forwarding. The bounce message will usually name the forwarder in the Received: chain.

7. Microsoft's SNDS and Postmaster signals

Microsoft publishes free sender reputation data through the Smart Network Data Services (SNDS) programme. You sign up at sendersupport.olc.protection.outlook.com with the IP ranges Customer.io sends from. SNDS shows complaint rates, spam-trap hits, and a green/yellow/red verdict per IP per day.

The caveat: SNDS is per IP. On Customer.io's shared pool you'll see traffic that isn't all yours. That's still useful—if the shared pool is yellow, your sender reputation is in the same yellow. If it's red and your DMARC alignment is broken, you're the one tipping it over. Junk Mail Reporting Programme (JMRP) is the complementary feedback loop for complaints; sign up at the same portal.

There's no SNDS-equivalent in Customer.io's UI because Microsoft doesn't expose the data via API. You have to log in to their portal.

A worked example: debugging a 5.7.515 bounce from a Customer.io broadcast

Last quarter a client sent a 12,000-recipient newsletter through Customer.io. The Outlook segment—about 2,800 addresses—bounced 100%. Their team noticed because revenue from the newsletter was 30% below trend the next day. The deliverability report inside Customer.io showed "rejected" but didn't surface the SMTP response.

We opened the raw bounce log in the Customer.io campaign view (Deliveries → Activity → click a bounced recipient → response detail). The string came back as:

550 5.7.515 Access denied, sending domain [brand.com] does not meet the
required authentication level. Visit https://aka.ms/SenderRequirements for more.

The fix sequence took twelve minutes. DMARC was missing entirely—they'd never published it. We added a v=DMARC1; p=none; rua=mailto:[email protected] record to DNS. We waited fifteen minutes for propagation, ran dig txt _dmarc.brand.com to confirm, then sent a single test campaign to one outlook.com address. It delivered. We re-sent the full newsletter to the bounced segment using Customer.io's broadcast filter on email_bounced from the original send. 96% of the resend hit the inbox.

The lesson isn't that DMARC is hard. It's that Customer.io's status page said "domain verified" and the team took that as "Microsoft will accept this". The two checks are independent.

While you're auditing authentication, take fifteen minutes for Liquid anti-patterns that silently break sends. Auth failures cause hard bounces. Liquid failures cause embarrassing emails. Both fail silently until the wrong person opens the report.

What to do this week vs this quarter

Three things this week. Pull your SPF, DKIM and DMARC records and verify the audit-trail above. Send a test broadcast to a personal outlook.com address and view the headers. Sign up for SNDS for the IP ranges you send from.

Two things this quarter. Move DMARC from p=none to p=quarantine once you've watched thirty days of clean reports. Replace any noreply@ From addresses with a real, monitored inbox, or at least one that doesn't bounce.

One thing on the radar. Apple Mail Privacy Protection has quietly broken open-based triggers in much the same way Microsoft's enforcement has quietly broken authentication. Both are silent-failure modes at the mailbox provider level. The pattern is the same: the ESP shows green, the recipient never gets the message (or never engages), and the marketer finds out from a revenue chart, not a deliverability dashboard. Audit on a schedule, not when something goes wrong.

Frequently asked questions

Does Customer.io's default sending setup satisfy Microsoft's bulk sender requirements?

Partly. Customer.io configures SPF and DKIM correctly when you verify a sending domain. DMARC, From-address validity and the one-click unsubscribe header all need to be checked at the workspace level. The defaults are sound but they don't cover everything Microsoft requires.

I'm under 5,000 a day to Outlook, do I still need to do this?

Yes. Microsoft's stated policy applies above 5,000/day, but consumer Outlook is increasingly applying alignment checks to lower-volume senders as well. More importantly, every other large mailbox provider—Gmail, Yahoo, Apple, Fastmail—wants the same authentication setup. Doing it once covers all of them.

What is the 5.7.515 error code exactly?

It's Microsoft's SMTP enhanced status code for "Access denied, sending domain does not meet the required authentication level". The full bounce string usually points to https://aka.ms/SenderRequirements. It's a permanent reject (5.x.x), not a temporary one (4.x.x), so retries don't help.

How do I check my DMARC alignment for Customer.io?

Send a test broadcast to an outlook.com or gmail.com address, then view the raw message source (in Outlook on the web: ⋯ → View → View message source). Look for the Authentication-Results: header. You want dmarc=pass with dkim=pass showing header.d=yourdomain.com, not header.d=cmail1.com. The header.d value must match your visible From domain.

Will p=none be enough or do I need p=quarantine?

p=none is enough to satisfy Microsoft's current policy. It tells receivers to take no action on failures. To actually protect your domain from spoofing, you need p=quarantine or p=reject. Start at none, watch thirty days of aggregate reports for false positives, then move up.

My forwarding service is breaking SPF, what now?

Publish DMARC with relaxed alignment (adkim=r, aspf=r) so the DKIM signature can still align even when SPF breaks on the forwarded hop. Pressure the forwarder to implement ARC. There's no fix at the Customer.io layer because the modification happens after the message leaves Customer.io.

Will adding contacts to Safe Senders bypass enforcement?

No. Safe Senders is a per-recipient setting on individual Outlook mailboxes. The 5.7.515 reject happens at the Microsoft edge gateway, before the message reaches the user's mailbox where Safe Senders would apply. The Tech Community thread has multiple comments from senders who tried this and confirmed it doesn't work.

Does this affect Microsoft 365 business mailboxes too, or just consumer Outlook?

The 5,000/day enforcement is consumer-only (outlook.com, hotmail.com, live.com, msn.com). Microsoft 365 commercial tenants apply their own anti-spam policies which look at the same signals but with different thresholds. If you're a B2B sender, Microsoft 365 isn't covered by the May 2025 policy directly—but the underlying authentication requirements are the same.

How long after fixing DNS does Microsoft start delivering again?

Usually within a few hours, sometimes a few minutes. DNS propagation is the slow part. Once the records are visible to public resolvers, Microsoft will pick up the change on the next inbound message. Send a single test to confirm before resending a full broadcast.

Can I send a re-engagement campaign to recipients who bounced with 5.7.515?

Yes, after you've fixed the underlying authentication. Filter your audience on email_bounced from the original send and resend the same message. Don't suppress them, because the bounce wasn't a real recipient-level problem—it was an authentication failure on your end.

What's the difference between SNDS and JMRP?

SNDS (Smart Network Data Services) gives you aggregate reputation data per IP per day. JMRP (Junk Mail Reporting Programme) sends you a copy every time a Microsoft user marks one of your emails as junk. Both are free, both signed up at sendersupport.olc.protection.outlook.com.

Does Customer.io support BIMI once DMARC is in place?

Customer.io itself doesn't gate BIMI—that's a DNS-and-certificate question. Once your DMARC is p=quarantine or stricter and you've published a BIMI DNS record pointing at an SVG logo, supporting clients (Apple Mail, Yahoo, increasingly Gmail) will display the logo. Outlook has been promising BIMI support for years and hasn't shipped it broadly.

What's a "From P2 address" versus a "From P1 address"?

P1 is the envelope From (MAIL FROM: in SMTP), used for bounce routing and SPF checks. P2 is the visible From the recipient sees in their email client (the From: header). They can differ—Customer.io rewrites P1 to its own bounce-handling domain by design. Alignment checks compare P2's domain against the SPF and DKIM domains.

How often should I re-run this audit?

Every quarter, plus whenever you launch a new sending domain, migrate ESP, or add a new campaign type. The DNS rarely changes on its own, but team members add SPF includes, change From addresses, and override workspace defaults at the campaign level. A quarterly check catches the drift before Microsoft does.

Sources

• Strengthening Email Ecosystem: Outlook's New Requirements for High-Volume Senders—Microsoft Defender for Office 365 Blog, 2 April 2025
• Microsoft Outlook sender requirements 2025: What senders should know—Mailgun, 2025
• Microsoft's 2025 Sender Email Requirements—Red Sift, 2025
• Sender authentication—Customer.io Docs, 2026
• DMARC—Customer.io Docs, 2026
• List-Unsubscribe header—Customer.io Docs, 2026