Email sender requirements: a developer's guide to the Gmail, Yahoo, and Outlook rules

Last updated July 2026.

You shipped a password reset flow. It worked in staging. In production, a chunk of your users never get the email, and they're not in spam either. The message left your server, got a 550 back from Gmail, and vanished. No bug report, no stack trace. Only users who can't log in and a support queue that keeps growing.

This is what changed. For years, the failure mode for a misconfigured sender was the spam folder. Annoying, but recoverable. As of 2024 and 2025, Gmail, Yahoo, and Outlook rewrote the rules for bulk senders and, more importantly, started enforcing them at the SMTP level. Non-compliant mail now gets rejected outright, not filtered. If your transactional email isn't authenticated correctly, it doesn't land late. It doesn't land at all.

The good news: the three big consumer mailbox providers have converged on nearly the same rulebook. Get it right once and you're covered almost everywhere. This guide is that rulebook: the current email sender requirements for Gmail, Yahoo, and Outlook, written for the person who actually has to configure the DNS records and read the bounce logs.

Key takeaways

• Gmail, Yahoo, and Outlook now enforce the same core rules. Bulk senders (more than 5,000 messages a day to a provider's consumer addresses) must pass SPF, DKIM, and DMARC, align their From domain, support one-click unsubscribe, and keep spam complaints under 0.3%.
• Enforcement moved from spam-foldering to outright rejection. Non-compliant mail now gets permanent SMTP errors (Gmail's 5.7.x, Outlook's 550 5.7.515) instead of arriving late.
• DMARC alignment is the rule most senders miss. Passing SPF and DKIM isn't enough. The visible From domain has to match one of them, or DMARC fails.
• Google retired the old reputation score. Postmaster Tools v2 replaced the High, Medium, and Low domain reputation view with a binary pass/fail Compliance Status.
• The rules apply to transactional email too. Password resets and receipts ride the same DNS records as marketing, so a broken setup takes down your product, not only your campaigns.

What actually changed

The requirements themselves aren't new. Google and Yahoo announced them in late 2023, with rules taking effect February 2024. Microsoft followed for Outlook consumer domains in 2025. What changed is the enforcement, and it moved in one direction: from education to rejection.

That last change matters more than it sounds. The old model gave you a fuzzy reputation score and a lot of room to argue with yourself about whether "Medium" was fine. The new model is a checklist with a red or green next to each line. There's no partial credit.

Who these rules apply to

Every provider draws the same line: a bulk sender is anyone sending more than 5,000 messages in a single day to that provider's consumer addresses.

• Gmail counts mail to personal @gmail.com and @googlemail.com addresses. Google Workspace addresses don't count toward the threshold.
• Yahoo counts its consumer domains, including Yahoo, AOL, and associated brands.
• Microsoft counts outlook.com, hotmail.com, and live.com.

Two things developers get wrong here. First, the 5,000 count is per day and rolling, not a monthly average. One large campaign or a busy transactional day tips you over, and once you cross the threshold you're treated as a bulk sender going forward. Second, even if you never hit 5,000, the baseline rules still apply. Every sender, at any volume, needs at least SPF or DKIM, a valid PTR record, TLS in transit, messages formatted to RFC 5322, and a spam rate that stays low. The bulk threshold adds requirements. It doesn't create them from nothing.

If you send transactional email, assume the rules apply to you. Password resets, receipts, verification codes, and alerts all count as email to consumer inboxes. The provider doesn't distinguish "important" mail from marketing at the authentication layer. Your login flow lives and dies by the same DNS records as your newsletter.

The rules every sender must follow now

Here's the shared baseline, in rough order of what breaks first if you skip it.

1. Authenticate with SPF and DKIM. SPF (Sender Policy Framework) is a DNS TXT record listing which servers may send for your domain. DKIM (DomainKeys Identified Mail) cryptographically signs each message so the receiver can verify it wasn't altered. Bulk senders need both, not one or the other. Use a DKIM key of at least 1024 bits; 2048 is the sane default.

2. Publish a DMARC record. DMARC (Domain-based Message Authentication, Reporting, and Conformance) tells receivers what to do when a message fails authentication, and sends you reports. The minimum accepted policy is p=none, which monitors without blocking. That's the floor, not the goal.

3. Align your From domain. This is the rule most people miss. Passing SPF and DKIM isn't enough on its own. The domain in the visible From: header has to match the domain that passed SPF or the domain that signed with DKIM. A message can pass both checks and still fail DMARC alignment, which now means rejection.

4. Support one-click unsubscribe. Marketing and subscribed messages must include List-Unsubscribe and List-Unsubscribe-Post headers implementing one-click unsubscribe per RFC 8058. When a user unsubscribes, honor it within two days. Transactional mail is exempt, but the line between "transactional" and "subscribed" is thinner than you think, so err toward including it.

5. Keep your spam complaint rate down. Gmail and Yahoo want you below 0.3%, and never at or above it. Treat 0.1% as your real target, because the gap between 0.1% and 0.3% is the difference between "healthy" and "one bad campaign from rejection." Microsoft doesn't publish a number but expects the same low complaint behavior.

6. Send over TLS with valid reverse DNS. Connections should use TLS. Your sending IP needs a valid PTR record so a reverse lookup resolves to a hostname that forward-resolves back to the same IP. Missing or mismatched reverse DNS is a common, silent cause of rejection.

7. Format messages to spec. Follow RFC 5322 for message structure. Don't spoof a Gmail From: address. Don't send with a bare IP or a domain that doesn't resolve.

Here's how the three providers line up on the specifics:

Provider-specific gotchas

The table covers the shared rules. These are the details that trip developers up on each provider.

Gmail. The move to Postmaster Tools v2 is the thing to internalize. The old reputation score is gone, so any monitoring or alerting you built against "domain reputation" needs to point at the new Compliance Status instead. Register your domain in Postmaster Tools, and check that every line reads Pass. Gmail also enforces the 1024-bit minimum DKIM key length specifically for personal Gmail accounts, and rejects shorter keys.

Outlook. Microsoft's enforcement is phased, which lulls people into ignoring it. Right now, non-compliant bulk mail goes to Junk. That feels survivable, so teams deprioritize the fix. But Microsoft has been explicit that Junk is the temporary state and the endpoint is a hard 550 5.7.515 Access denied rejection. If your Outlook delivery quietly degraded in mid-2025, that's the warning shot. Use SNDS (Smart Network Data Services) and the Junk Mail Reporting Program to watch your standing.

Yahoo. Yahoo's rules mirror Google's closely, so if you're compliant with Gmail you're usually compliant here. The one real difference: Yahoo calculates spam rate against mail delivered to the inbox, which can read differently from complaint feedback loop numbers. Sign up for Yahoo's Complaint Feedback Loop so complaints come back to you as they happen instead of showing up as a reputation drop you can't explain.

The rest of the market is heading the same way

Gmail, Yahoo, and Outlook cover the majority of consumer inboxes, but they're not the whole picture, and the direction of travel is consistent.

Apple Mail doesn't publish sender authentication requirements the way the big three do, but it shapes deliverability in its own way. Mail Privacy Protection pre-fetches images and masks opens, which means open rate is no longer a signal you can trust for Apple users. If your sunset policy or engagement segmentation leans on opens, it's quietly broken for a large share of your list. Lean on clicks and other real engagement instead.

B2B and enterprise filters like Proofpoint, Mimecast, and Microsoft Defender apply their own layered rules on top of standard authentication. They weigh domain age, sending consistency, URL reputation, and content heuristics. Passing SPF, DKIM, and DMARC is the entry ticket, not the whole game, when you're sending into corporate inboxes.

The trend line is clear. DMARC started as a recommendation and is now a hard requirement for bulk senders. The expected next steps are enforcement policies moving from p=none toward p=quarantine and p=reject as the norm, wider adoption of MTA-STS to enforce TLS, and BIMI (Brand Indicators for Message Identification) letting authenticated senders show a verified logo in the inbox. None of that is mandatory yet. All of it rewards senders who treat authentication as infrastructure rather than a one-time checkbox. Build for p=reject and BIMI now and you're ahead of the next round of rules instead of scrambling after it.

What developers should actually do

The rules are the same everywhere, so the implementation is too. Here's the short version.

Set up authentication as real DNS records, not screenshots in a runbook. A minimal set looks like this:

; SPF: authorize your sending sources
example.com.  TXT  "v=spf1 include:_spf.google.com include:sendgrid.net -all"

; DMARC: start at monitor, with reports coming back to you
_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com; adkim=s; aspf=s"

DKIM records are generated by your sending provider and published at a selector subdomain. Once DMARC reports confirm your legitimate sources all pass and align, move the policy from p=none to p=quarantine, then p=reject. Don't start at p=reject. You'll block mail you forgot you were sending, like a legacy CRM or a forgotten cron job.

The one architectural decision that matters most: separate your transactional and marketing email onto different subdomains. Send password resets from something like notify.example.com and campaigns from news.example.com, each with its own authentication and its own reputation. This keeps a bad marketing send from dragging your login emails into the reject pile. Never send from your root domain.

Add the one-click unsubscribe headers to any subscribed mail:

List-Unsubscribe: <https://example.com/unsub?token=abc123>, <mailto:unsub@example.com>
List-Unsubscribe-Post: List-Unsubscribe=One-Click

Then monitor from the start, not after something breaks. Watch the Gmail Compliance Status, Outlook's SNDS, and your DMARC reports. By the time a user tells you email is missing, the reputation damage is already done.

This is the layer Courier is built to handle. Because Courier sits between your app and your email providers, you can route transactional and marketing streams to separate providers and domains through configuration instead of code, fail over to a backup provider when one gets blocklisted or has an outage, and track delivery status for every message in one place instead of stitching together three postmaster dashboards. And because Courier is multi-channel, a rejected email doesn't have to mean a lost message: a critical alert can fall back to SMS, push, or in-app so the user still gets it. The sender rules are non-negotiable, but the infrastructure to satisfy them across providers doesn't have to be something you build and maintain yourself.

Frequently asked questions

What counts as a bulk sender?

Anyone sending more than 5,000 messages in a single day to a given provider's consumer addresses. Gmail, Yahoo, and Outlook all use the same 5,000-per-day threshold. The count is per provider and per day, so a single large send can cross it.

Do these rules apply to transactional email?

Yes. Password resets, receipts, verification codes, and alerts are all email to consumer inboxes, and providers enforce authentication the same way regardless of message purpose. Transactional mail is only exempt from the one-click unsubscribe requirement, not from SPF, DKIM, DMARC, or spam-rate rules.

What happens if I don't comply?

Your mail gets rejected or spam-foldered. Gmail returns permanent 5.7.x errors that drop the message entirely. Outlook routes non-compliant bulk mail to Junk and is moving toward outright rejection with a 550 5.7.515 error. A rejected message produces no delivery and often no clear signal to the user, which makes failures hard to notice.

Do I need DMARC if I already have SPF and DKIM?

For bulk sending, yes. Bulk senders to Gmail, Yahoo, and Outlook must publish a DMARC record with at least a p=none policy, and the visible From domain must align with the domain that passed SPF or DKIM. Passing SPF and DKIM without alignment still fails DMARC.

What's an acceptable spam complaint rate?

Stay below 0.3%, and treat 0.1% as your working target. Gmail and Yahoo both draw the hard line at 0.3%. Consistently sitting between 0.1% and 0.3% leaves no margin, so a single bad send can push you into rejection territory.

Do the rules apply if I send fewer than 5,000 emails a day?

The bulk-specific rules (both SPF and DKIM, mandatory DMARC, one-click unsubscribe) target senders above 5,000 per day. But the baseline (at least SPF or DKIM, TLS, valid reverse DNS, low spam rate, RFC 5322 formatting) applies to every sender at any volume. Setting up full authentication regardless is the safe default, especially since one busy day can tip you over the threshold.

What is DMARC alignment, and why does it fail?

Alignment means the domain in the visible From: header matches the domain that passed SPF or the domain that signed with DKIM. A message can pass SPF and DKIM on a different domain, which is common when a third-party tool sends on your behalf, and still fail DMARC because neither aligns with your From address. Fix it by authenticating with a domain or subdomain that matches what recipients see.

How do I check whether my domain is compliant?

Register your domain in Google Postmaster Tools and read the Compliance Status dashboard, which shows pass or fail for each requirement. Use Microsoft SNDS for your Outlook standing, and read your DMARC aggregate reports to confirm every legitimate sending source passes and aligns. Sending a test message and inspecting the headers for dkim=pass, spf=pass, and dmarc=pass is the fastest spot check.

What's the difference between a 4.7.x and a 5.7.x SMTP error?

A 4.7.x code is a temporary failure: the provider is deferring or rate-limiting your mail, and a retry may succeed. A 5.7.x code is a permanent failure: the message is rejected and won't be retried. Gmail's shift from 4.7.x deferrals to 5.7.x rejections for non-compliant bulk mail is what turned deliverability problems into hard delivery failures.

Does any of this apply to Apple Mail?

Apple doesn't publish sender authentication requirements like the big three, but Mail Privacy Protection masks opens for Apple users, so open rate stops being a reliable engagement signal. Standard authentication still helps you land in Apple inboxes, but don't rely on opens to measure whether you did.

Common terms

• SPF (Sender Policy Framework): a DNS record listing the servers allowed to send mail for your domain.
• DKIM (DomainKeys Identified Mail): a cryptographic signature on each message that proves it came from your domain and wasn't altered in transit.
• DMARC (Domain-based Message Authentication, Reporting, and Conformance): a published policy that tells receivers what to do with mail that fails SPF and DKIM, and sends you reports.
• Alignment: the requirement that your visible From domain match the SPF or DKIM domain that passed.
• One-click unsubscribe (RFC 8058): a header-based unsubscribe that lets a recipient opt out in a single action, required for bulk marketing mail.
• PTR record: the reverse-DNS record that maps a sending IP back to a hostname.
• MTA-STS (Mail Transfer Agent Strict Transport Security): a policy that forces TLS encryption for mail in transit.
• BIMI (Brand Indicators for Message Identification): a standard that displays a verified brand logo next to authenticated mail.
• Feedback loop (FBL): a provider program that reports spam complaints back to you as they happen.

Sources

• Google, Email sender guidelines
• Yahoo, Sender best practices
• Microsoft, Outlook's new requirements for high-volume senders
• IETF, RFC 8058 (one-click unsubscribe) and RFC 5322 (Internet Message Format)
• DMARC.org and the BIMI Group