Bulk Sender Requirements Guide: Meeting Gmail, Yahoo and Microsoft Outlook Rules

Gmail, Yahoo and Microsoft Outlook now refuse to trust high-volume mail that is not authenticated, aligned and easy to unsubscribe from, so a gap in DNS or headers can stop your invoices, alerts and newsletters reaching customers. Google and Yahoo started enforcing sender requirements in February 2024, and Microsoft began enforcing its own rules for Outlook.com senders of more than 5,000 messages a day on 5 May 2025. These rules turned SPF, DKIM, DMARC and one-click unsubscribe from good practice into a condition of delivery. This guide sets out what each provider requires, how the requirements overlap, how to bring every sending platform into compliance without breaking legitimate mail, and how to measure it. It is for email administrators, marketing operations and security teams who own a domain that sends at scale. The record syntax itself is covered in the DMARC, SPF and DKIM Guide; this page focuses on the provider rules and the operating model.

Key takeaways

• The 5,000-a-day line is the trigger. Google applies its stricter rules to senders of 5,000 or more messages a day to personal Gmail accounts, and Microsoft applies its rules to senders of more than 5,000 a day to Outlook.com.
• Bulk senders need SPF, DKIM and DMARC together. A DMARC policy of p=none is the minimum, but DMARC must pass, which means the From: domain must align with the SPF or DKIM domain.
• One-click unsubscribe is a technical standard, not a footer link. RFC 8058 needs a List-Unsubscribe HTTPS URI, a List-Unsubscribe-Post header and a DKIM signature covering both.
• Spam complaints are now a hard limit. Google and Yahoo both set 0.3% as the line not to cross; Google advises keeping it below 0.1%.
• Every third-party platform that sends as your domain is in scope. Marketing, CRM, ticketing and billing tools each need aligned DKIM, and their API keys are now a deliverability and impersonation risk.

What each mailbox provider requires

The three providers publish their rules separately and in different levels of detail. The table below records what each provider's own pages stated when checked on 27 October 2026.

DKIM key length: Google requires at least 1024-bit keys and recommends 2048-bit where the sending platform supports them. Treat 2048-bit as the default for new selectors.

Practical reading: build to the strictest combined baseline (SPF and DKIM, aligned DMARC, RFC 8058, PTR, TLS, spam rate under 0.1%) rather than per provider. One baseline is easier to audit and covers mail that is forwarded between providers.

Authentication and alignment at scale

Most compliance failures are not missing records but unaligned ones. A platform signs with its own domain (for example a shared ESP domain) and passes DKIM, but the d= domain does not match your From: domain, so DMARC fails.

• Inventory every sender: start from DMARC aggregate (rua) reports, which list every source IP and the SPF and DKIM domains seen for your domain. Add tools found through procurement and finance records.
• Prefer DKIM alignment over SPF alignment: DKIM survives forwarding; SPF does not, and SPF has a ten DNS lookup limit that large estates exceed quickly. Configure each platform to sign with a selector under your domain (custom DKIM, often delegated with CNAME records).
• Use subdomains to separate streams: for example news.example.com for marketing and billing.example.com for transactional mail. Reputation, complaint rates and DMARC policy can then be managed per stream, and a marketing complaint spike does not hurt password reset delivery.
• Set the Return-Path deliberately: for SPF alignment, the envelope sender (MAIL FROM) domain must be your domain or subdomain, not the platform's bounce domain.
• Rotate DKIM keys: publish a new selector, switch signing, then remove the old public key after messages in transit have been delivered.
• Plan the DMARC journey past p=none: the providers accept p=none, but none gives no protection against spoofing of your domain. Move to quarantine and then reject once reports show every legitimate source aligned. See the DMARCbis Changes Guide for the updated specification.

One-click unsubscribe done properly

RFC 8058 (Standards Track, January 2017) defines one-click unsubscribe. The requirements that cause failures:

• List-Unsubscribe: must contain one HTTPS URI; a mailto URI may also be included.
• List-Unsubscribe-Post: must contain the single value List-Unsubscribe=One-Click.
• DKIM coverage: the message needs a valid DKIM signature that covers both headers, which means both names appear in the signature's h= tag. A gateway that adds the headers after signing breaks this.
• The POST endpoint: the receiver sends the request without cookies or HTTP authorisation, and the sender must not answer with a redirect. Embed an opaque, hard-to-forge identifier in the URI and verify it server-side, so the endpoint cannot be used to unsubscribe arbitrary addresses.
• Processing time: Yahoo requires unsubscribes to be honoured within 2 days. Make suppression lists propagate across every platform that mails the same audience within that window.
• Visible link: Google and Yahoo also want a clearly visible unsubscribe link in the body.

Scope: the unsubscribe requirement applies to marketing and subscribed messages. Transactional mail (receipts, password resets, security alerts) is a separate stream and is best kept on a separate subdomain so it is not judged with marketing mail.

Spam rate and reputation management

• Measure where providers measure: Google Postmaster Tools shows spam rate, reputation, authentication and delivery errors for mail to personal Gmail accounts, once the domain is verified. Data can be missing at low daily volume. Yahoo calculates spam rate on mail delivered to the inbox.
• Treat 0.1% as the operating ceiling and 0.3% as an incident. A single badly targeted campaign can take a domain over the line.
• Consent and list hygiene: confirmed opt-in, removal of hard bounces, sunset rules for disengaged recipients and no purchased lists are the controls that move complaint rates.
• Warm up new IPs and domains gradually rather than moving all volume at once.
• Infrastructure basics: forward-confirmed reverse DNS for every sending IP, TLS on outbound SMTP and RFC 5322 conformant headers.

Where identity fits: sending platforms are non-human identities

Once DKIM is delegated to a platform, anyone holding that platform's API key can send fully authenticated, aligned mail as your brand. DMARC at p=reject does not help, because the mail passes. The Mailchimp breach shows the pattern: attackers used an internal support tool to obtain customer API keys, and phishing aimed at a customer's contacts followed within a week.

• Least privilege keys: issue send-only keys per application, not full account keys.
• Vault and rotate: store keys in a secrets manager; rotate on staff departure and on any supplier incident. See the SendGrid, Mailgun and Mailchimp API Keys Security Guide.
• MFA and SSO on platform consoles: console access can create new keys and change DKIM settings.
• Offboard platforms: when a tool is retired, remove its DKIM CNAMEs and SPF include, otherwise it can still send as you.

Implementation plan

1. Discover (weeks 1-2): publish DMARC at p=none with a rua address if none exists; collect two to four weeks of aggregate reports; list every source and owner.
2. Classify streams: marketing, transactional, corporate and system mail; map each to a subdomain and a responsible team.
3. Align (weeks 3-8): enable custom DKIM (2048-bit) and branded Return-Path on each platform; remove unused SPF includes to stay under ten lookups.
4. Unsubscribe: implement RFC 8058 headers on all marketing and subscribed mail; test that DKIM h= covers both headers; connect suppression lists across platforms.
5. Verify: register domains in Google Postmaster Tools; send test mail to seed accounts at each provider and inspect Authentication-Results headers for spf=pass, dkim=pass and dmarc=pass.
6. Enforce (from month 3): move DMARC to p=quarantine with pct ramping, then p=reject, one subdomain at a time, starting with domains that send no mail at all. Rollback is a DNS change back to p=none; keep TTLs short during the change.
7. Operate: weekly report review, change control for new sending tools, quarterly key rotation.

Small versus large organisations: a small organisation with one mail platform and one ESP can be compliant in days. A large organisation with dozens of tools needs a DMARC report processor, an owner per sending source and procurement rules that require custom DKIM before a new tool can send.

Choosing between SPF and DKIM alignment: where a platform supports both, align both. Where it supports only one, choose DKIM, because a forwarded message keeps a valid signature while SPF is evaluated against the forwarding server. Choose SPF alignment alone only for internal relays that never forward, and record the exception in the sender inventory.

Reading a test message against the rules

Before and after every change, send a real campaign or transactional message to seed mailboxes at Gmail, Yahoo and Outlook.com and read the raw headers. Check the following in order:

Automate this check in a pipeline for each sending platform, so a template change or platform update that drops a header is caught before a full send rather than after complaints rise. Keep the seed results as evidence for audits and supplier reviews.

Detection and measurement

Security signals: alert on new sending IPs passing DKIM for your domain, new API keys created on sending platforms, and DMARC failures from unknown sources, which indicate spoofing attempts (ATT&CK T1566 Phishing) or abuse of a compromised email account (T1586.002).

Framework mapping

Common failure patterns

• DKIM passes but DMARC fails: the platform signs with its own domain. Check d= against From: for every source.
• Unsubscribe headers added after signing: a gateway or ESP inserts List-Unsubscribe after DKIM is applied, so the signature does not cover it and one-click is not honoured.
• Transactional and marketing on one domain: a complaint spike from a campaign degrades password reset and invoice delivery.
• SPF over ten lookups: adding an include for every tool produces a permerror and SPF fails everywhere.
• Stopping at p=none: deliverability is satisfied but the domain stays spoofable.
• Forgotten platform keys: an old ESP account with a live API key and DKIM CNAME still sends authenticated mail, as the Mailchimp incident showed.

Practitioner checklist

• Inventory every service sending as your domains, with an owner and a stream classification.
• SPF and 2048-bit DKIM on every source, with DKIM aligned to the From: domain.
• DMARC published on every domain with a rua address, and a dated plan to reach p=reject.
• Separate subdomains for marketing and transactional mail.
• RFC 8058 headers on all marketing mail, covered by DKIM, with a visible body link.
• Suppression lists synchronised across platforms within 2 days.
• Domains verified in Google Postmaster Tools; spam rate reviewed weekly against 0.1%.
• PTR records and TLS on all sending IPs.
• Sending platform API keys scoped, vaulted, rotated and removed at offboarding.

Standards and references

• Google: Email sender guidelines
• Yahoo: Sender Best Practices
• Microsoft: Outlook.com postmaster requirements
• IETF: RFC 8058 Signaling One-Click Functionality for List Email Headers
• Google: Postmaster Tools
• M3AAWG: Published documents, including Sender Best Common Practices

Related NHI Mgmt Group resources: DMARC, SPF and DKIM Guide · DMARCbis Changes Guide · SendGrid, Mailgun and Mailchimp API Keys Security Guide · Email Security Guide