Microsoft Outlook's New Sender Requirements: What Developers Need to Do Now

Google and Yahoo forced bulk senders to authenticate in 2024. Now Microsoft is doing the same thing — and if you send more than 5,000 messages a day to Outlook.com, Hotmail.com, or Live.com addresses, your emails will get junked or outright rejected unless you comply.

Enforcement started May 5, 2025. Non-compliant messages are already being routed to junk folders, and hard rejections with 550 errors are rolling out. If your transactional emails — password resets, verification codes, invoices — hit Outlook inboxes, this applies to you.

What changed

On April 2, 2025, Microsoft announced that Outlook.com would begin enforcing email authentication requirements for high-volume senders — anyone sending 5,000 or more messages per day to Microsoft consumer domains (outlook.com, hotmail.com, live.com).

The requirements mirror what Google and Yahoo rolled out in early 2024, but with Microsoft's own enforcement timeline:

• SPF — The sending domain must pass SPF checks, and the domain in the MAIL FROM (envelope sender) must align with the From header domain
• DKIM — Messages must be signed with DKIM using at least a 1024-bit key, and the signing domain must align with the From header domain
• DMARC — The sending domain must have a DMARC record published in DNS with at least p=none, and it must pass based on SPF or DKIM alignment

Enforcement timeline

Microsoft rolled this out in two phases:

1. May 5, 2025 — Non-compliant messages from high-volume senders are routed to the Junk folder. Senders get a grace period to fix their records.
2. Later in 2025 — Full rejection. Non-compliant messages are bounced with a 550 5.7.515 error. No junk folder safety net — the message simply doesn't arrive.

The requirements breakdown

All three protocols must be configured correctly. Missing even one means you fail the check. Here's what each requires.

v=spf1 include:send.example.com ~all

resend._domainkey.yourdomain.com. IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBA..."

_dmarc.yourdomain.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; pct=100"

How to check your compliance

Before waiting for a 550 bounce to tell you something is wrong, verify your records proactively.

Check with CLI tools

You can verify all three records from your terminal using dig or nslookup:

dig TXT yourdomain.com +short
# Look for: "v=spf1 include:... ~all"

dig TXT resend._domainkey.yourdomain.com +short
# Look for: "v=DKIM1; k=rsa; p=..."

dig TXT _dmarc.yourdomain.com +short
# Look for: "v=DMARC1; p=none; ..." (or p=quarantine / p=reject)

Check with Resend's domain verification

If you use Resend, the dashboard shows the verification status of each DNS record (SPF, DKIM, DMARC) for your sending domains. Green checkmarks mean you're passing. If any record shows as unverified, Resend tells you exactly which DNS record to add.

Programmatic DMARC verification

You can build a simple API endpoint that checks DMARC status for any domain using Node.js DNS lookups. This is useful for monitoring your own domains or checking customer domains in a multi-tenant setup:

import { NextRequest, NextResponse } from "next/server";
import { promises as dns } from "dns";

export async function GET(req: NextRequest) {
  const domain = req.nextUrl.searchParams.get("domain");

  if (!domain) {
    return NextResponse.json(
      { error: "Missing domain parameter" },
      { status: 400 }
    );
  }

  try {
    const records = await dns.resolveTxt(`_dmarc.${domain}`);
    const dmarcRecord = records
      .map((r) => r.join(""))
      .find((r) => r.startsWith("v=DMARC1"));

    if (!dmarcRecord) {
      return NextResponse.json({
        domain,
        hasDmarc: false,
        policy: null,
        record: null,
      });
    }

    const policyMatch = dmarcRecord.match(/p=(none|quarantine|reject)/);
    const ruaMatch = dmarcRecord.match(/rua=([^;]+)/);

    return NextResponse.json({
      domain,
      hasDmarc: true,
      policy: policyMatch?.[1] ?? "unknown",
      hasReporting: !!ruaMatch,
      reportingAddress: ruaMatch?.[1] ?? null,
      record: dmarcRecord,
    });
  } catch (err) {
    return NextResponse.json({
      domain,
      hasDmarc: false,
      policy: null,
      record: null,
      error: "DNS lookup failed — record may not exist",
    });
  }
}

What happens if you don't comply

Microsoft's enforcement isn't a single switch flip. It's a cascade, and each phase gets worse.

Phase 1: Junk folder routing

Starting May 5, 2025, non-compliant messages from high-volume senders land in the Junk folder instead of the inbox. Your emails still technically arrive, but most users never check their junk folder — especially for transactional messages they expect to see immediately.

Phase 2: Hard rejection

In the next phase, Microsoft will reject non-compliant messages outright with a 550 5.7.515 error. The message never reaches the recipient — not the inbox, not the junk folder, nowhere. Your sending infrastructure gets a bounce notification, but the user gets nothing.

Impact scope

Microsoft's consumer email network is massive. Outlook.com, Hotmail.com, and Live.com together represent hundreds of millions of active mailboxes worldwide. If your SaaS product has consumer users, a meaningful percentage of them are likely on one of these domains.

Even if you're below the 5,000-message threshold today, Microsoft has signaled they may extend these requirements to smaller senders over time — exactly as Google did.

Best practices beyond the minimum

SPF, DKIM, and DMARC are the enforcement requirements. But Microsoft's guidance goes further with recommendations that, while not mandatory today, signal where the industry is heading.

One-click unsubscribe

Microsoft recommends supporting List-Unsubscribe headers, particularly the RFC 8058 one-click unsubscribe mechanism. This lets mail clients show a native unsubscribe button — no link hunting, no landing page friction.

For transactional email, this is mainly relevant if you also send product update or notification emails that recipients might want to opt out of. Pure transactional messages (password resets, verification codes) typically don't need unsubscribe headers.

Valid sender addresses

Your From and Reply-To addresses should be real, monitored mailboxes that can receive replies. Using noreply@ addresses is technically valid but increasingly frowned upon — it signals to both providers and users that you don't care about engagement.

Bounce and complaint handling

Microsoft expects senders to actively process bounces and remove invalid addresses. Continuing to send to addresses that bounce harms your sender reputation and can trigger additional filtering.

React Email compliance checklist

If you're building transactional emails with React Email and sending through Resend, most of the heavy lifting is already done. But it's worth understanding what's handled automatically and what requires your attention.

What Resend handles automatically

• SPF — When you verify your domain in Resend, the DNS records you add include Resend's sending IPs in your SPF record
• DKIM — Resend generates a 2048-bit DKIM key pair and signs every outgoing message automatically
• Envelope alignment — Resend sets the MAIL FROM envelope sender to align with your verified domain

What you need to configure

• DMARC record — You need to publish a DMARC TXT record in your domain's DNS. Resend can't do this for you because it's a domain-level policy you control.
• List-Unsubscribe headers — For notification-type emails, you should add unsubscribe headers to stay ahead of evolving requirements.
• From address — Use a consistent From address on a domain you've verified, not a freemail address.

Compliant email send example

Here's a complete example of sending a compliant transactional email with Resend, including the recommended headers:

import { Resend } from "resend";
import { VerificationEmail } from "@/emails/verification";

const resend = new Resend(process.env.RESEND_API_KEY);

export async function sendVerificationEmail({
  to,
  code,
  userId,
}: {
  to: string;
  code: string;
  userId: string;
}) {
  const { data, error } = await resend.emails.send({
    from: "MyApp <notifications@mail.myapp.com>",
    to,
    subject: "Verify your email address",
    react: VerificationEmail({ code }),
    headers: {
      // One-click unsubscribe (RFC 8058) — for notification emails
      "List-Unsubscribe": `<https://myapp.com/unsubscribe?uid=${userId}>`,
      "List-Unsubscribe-Post": "List-Unsubscribe=One-Click",
    },
  });

  if (error) {
    console.error("Email send failed:", error);
    throw new Error(`Failed to send verification email: ${error.message}`);
  }

  return data;
}

For a complete setup from scratch — including domain verification, DNS records, and your first send — see the SPF, DKIM & DMARC guide.

How this compares to Google and Yahoo

Microsoft's requirements are nearly identical to what Google and Yahoo enforced starting February 2024. The convergence is the point — the three largest consumer mailbox providers now agree on the same baseline.

• Same threshold — 5,000+ messages per day triggers enforcement (Google's number, Microsoft adopted it)
• Same protocols — SPF, DKIM, and DMARC are required by all three
• Same trajectory — All three providers have signaled that requirements will expand to smaller senders over time
• Same enforcement pattern — Junk folder first, then hard rejection

The practical implication: if you already complied with Google's 2024 requirements, you're likely already compliant with Microsoft's. If you didn't — or you've been meaning to get around to it — the window is closing.

Your compliance action plan

If you're not sure where you stand, here's the priority-ordered list: