# Google, Yahoo and Microsoft bulk sender requirements: what to check now

Canonical URL: https://www.martechdevs.com/blog/bulk-sender-requirements

By [Jafrin Akter Alo](https://www.martechdevs.com/authors/jafrin-akter-alo)

Data Engineer and Co-founder, martechdevs

Published: 2026-03-20

Last updated: 2026-09-23

Bulk sender requirements cover authentication, message handling and recipient control. Passing a DNS checker is only part of the job. You also need to verify the messages each tool actually sends, whether unsubscribe requests take effect, and whether recipients are reporting the mail as spam. A technically authenticated message can still be unwanted and filtered.

## Start with the receiving provider and the sending domain

These rules apply to mail arriving at the provider's service. They are not determined by the email application a recipient happens to use. Someone reading a company mailbox in the Outlook app is not automatically an Outlook.com consumer-mail recipient.

Inventory the systems sending as your business: employee mail, CRM sequences, newsletters, product notifications, billing, support and external agencies. Record the visible From domain, envelope sender, DKIM signing domain, sending provider and approximate daily volume by recipient provider.

Do this across teams. A marketer looking only at newsletter volume can miss another system sending from the same domain.

## Gmail: count across the primary domain

Google's FAQ describes a bulk sender as one sending close to 5,000 or more messages to personal Gmail accounts in 24 hours. Messages from the same primary domain count together, including subdomains. Once assigned, bulk-sender status does not expire. The FAQ also states that enforcement increased from November 2025, including temporary and permanent rejections. [Gmail sender FAQ](https://support.google.com/mail/answer/14229414?hl=en).

Do not design around sending just below a presumed exact boundary. Establish the required controls before a product launch, seasonal promotion or new notification stream changes the volume.

For bulk traffic, Google's requirements include SPF and DKIM, a DMARC policy that may be `p=none`, alignment of the visible From domain with a passing SPF or DKIM identity, valid forward and reverse DNS, TLS and correct message formatting. Marketing and subscribed messages need one-click unsubscribe and a visible body link. Requirements began in February 2024. [Gmail sender guidelines](https://support.google.com/mail/answer/81126?hl=en).

Lower-volume senders still have requirements. Do not interpret the bulk threshold as permission to omit authentication or send unwanted mail.

## Yahoo: there is no published 5,000-message threshold

Yahoo defines bulk sending by significant volume and does not publish a numeric threshold. Its assessment can consider the authenticated or From domain alongside other information. Do not import Google's number into a Yahoo compliance checklist. [Yahoo sender FAQ](https://senders.yahooinc.com/faqs/).

Yahoo's bulk requirements include SPF and DKIM, passing DMARC with at least `p=none`, low complaint rates, valid DNS and compliant formatting. Marketing and subscribed mail need an unsubscribe mechanism and visible body link, with requests honored within two days. Its current guidance recommends RFC 8058 POST and also accepts a mailto method. Enforcement began in February 2024. [Yahoo sender requirements](https://senders.yahooinc.com/best-practices/?is_listing=false).

For a shared implementation serving Gmail and Yahoo, build and verify RFC 8058 support. Yahoo's acceptance of another method is not evidence that it meets Gmail's requirements.

## Microsoft: authentication rejection is already part of the rule

Microsoft's announcement originally described a junk-folder phase. The updated announcement replaces that plan with rejection of messages failing the required authentication, starting 5 May 2025, using `550 5.7.515`. Do not use the superseded “junk first, rejection later” text as the current timeline. [Microsoft's updated announcement](https://techcommunity.microsoft.com/blog/microsoftdefenderforoffice365blog/strengthening-email-ecosystem-outlook%E2%80%99s-new-requirements-for-high%E2%80%90volume-senders/4399730).

Microsoft's support guidance identifies high-volume domains sending 5,000 or more messages to its consumer email services with the same visible From domain. SPF and DKIM must both pass, and DMARC must pass through alignment with at least one. A valid `p=none` policy is permitted. Inspect the actual message authentication results when diagnosing `5.7.515`. [Microsoft authentication-error guidance](https://support.microsoft.com/en-us/outlook/fix-ndr-error-550-5-7-515-in-outlook-com).

The announcement separately recommends functional unsubscribe links, valid sender addresses and sound list practices. It does not state the same explicit RFC 8058 mandate as Gmail. Implementing one-click across your marketing stack remains a useful operating choice, but distinguish that choice from a provider's exact published requirement.

## Check authentication and alignment on a real message

Three green DNS records do not prove that three authentication checks pass on every sending path.

SPF evaluates whether the sending source is authorized for the envelope-sender domain. DKIM verifies a signature associated with its signing domain. DMARC relates an authenticated identity to the domain the recipient sees in From. Under relaxed alignment the organizational domains match; strict alignment requires an exact domain match. The current DMARC standard is RFC 9989, published in May 2026, which supersedes RFC 7489. [DMARC specification](https://www.rfc-editor.org/rfc/rfc9989.html).

Consider this simplified, illustrative header result:

```text
From: Product Team <updates@example.com>
Return-Path: <bounce-123@mailer.example.net>
Authentication-Results: receiver.example;
  spf=pass smtp.mailfrom=mailer.example.net;
  dkim=pass header.d=mailer.example.net;
  dmarc=fail header.from=example.com
```

Both mechanisms pass for the provider's domain, but neither aligns with `example.com`. The sending service needs an appropriate authenticated domain configuration. A passing DKIM signature aligned with `example.com` could supply the DMARC path; the provider's separate requirement for SPF and DKIM still needs checking.

This is an explanation of results, not a complete message or a signature you can paste into an email. Read the receiving service's trusted authentication results rather than treating a sender-inserted header as proof.

For every sending tool, test a representative message through its normal production path to a mailbox you control. Inspect the source headers and confirm which domain actually authenticated. Repeat for transactional and marketing streams when their configurations differ.

### Avoid common DNS fixes that create new failures

Use the provider's instructions for the actual envelope and signing domains. Google documents that a domain has one SPF record, which can authorize multiple services, and limits DNS-dependent references. Do not add a second independent SPF record whenever a new vendor requests authorization. [Google's SPF record guidance](https://knowledge.workspace.google.com/admin/security/about-spf-records).

For an initial read-only inspection, these commands illustrate the kinds of records to inspect. Replace the reserved example names and use the selector configured by your sending service:

```bash
dig +short TXT example.com
dig +short TXT _dmarc.example.com
dig +short TXT selector1._domainkey.example.com
dig +short CNAME selector1._domainkey.example.com
```

A DKIM record may be delegated through a CNAME. An empty TXT response for the guessed selector therefore does not, by itself, prove DKIM is absent. Check the configured record and a received message together.

Likewise, `p=none` is an allowed minimum policy in these requirements; it is not a promise that receivers will deliver failing messages. Plan stronger enforcement only after identifying legitimate senders and fixing their authentication. A rushed change to `reject` can disrupt legitimate product or support email that your inventory missed.

## Verify one-click unsubscribe beyond the footer

A footer link that opens a preference page is useful, but it is not the same mechanism as header-based one-click unsubscribe.

RFC 8058 uses an HTTPS endpoint and a `List-Unsubscribe-Post` header. The endpoint must identify the recipient and list without a logged-in browser session. The relevant headers must be covered by a valid DKIM signature; the POST cannot depend on cookies or additional authorization, and the sender must not redirect it. [RFC 8058](https://www.rfc-editor.org/rfc/rfc8058.html).

An illustrative header pair is:

```text
List-Unsubscribe: <https://mail.example.com/unsubscribe/opaque-test-token>
List-Unsubscribe-Post: List-Unsubscribe=One-Click
```

The token must resolve to the correct test recipient and list in your implementation. This example endpoint does not exist. Adding these strings without a functioning handler and DKIM coverage is insufficient.

Test the full path with an address and list you control:

- Confirm the received message contains the intended headers after the sending provider has processed it.
- Confirm the valid DKIM signature covers both unsubscribe headers.
- Exercise the one-click POST without browser cookies or a login.
- Confirm the request updates the intended list or preference state.
- Confirm an already queued marketing message observes the new state.
- Confirm later CRM imports or synchronizations do not restore the old preference.

Gmail's compliance guidance requires honoring unsubscribe requests within 48 hours and identifies blocked requests or processing failures as operational problems. A web firewall blocking the provider's request does not make the unsubscribe requirement disappear. [Postmaster Tools dashboards](https://support.google.com/mail/answer/14668346?hl=en).

Aim for immediate processing where your architecture permits it. Record failures and retries so someone owns the gap between receiving a request and stopping messages.

## Read complaint rates with the right denominator

Google recommends keeping its user-reported spam rate below 0.1% and avoiding 0.3% or higher. These are not interchangeable targets: operating just under the higher boundary leaves little room for an audience or campaign problem. [Gmail sender FAQ](https://support.google.com/mail/answer/14229414?hl=en).

Yahoo requires a complaint rate below 0.3% and says its calculation is based on inbox-delivered mail. Do not compare it with a blended rate using all messages attempted across every provider. [Yahoo sender requirements](https://senders.yahooinc.com/best-practices/?is_listing=false).

For an original illustrative example, nine complaints among 3,000 relevant inbox deliveries equal **0.3%**. Dividing the same nine complaints by 100,000 total campaign attempts gives **0.009%**. The smaller result answers a different question and conceals the concentration of complaints in the affected audience.

Use the provider's reported metric when assessing its requirements. Google's dashboard describes a DKIM-authenticated, inbox-based user-report rate, with data that can be delayed or unavailable at low volume. A low rate can coexist with poor delivery if much of the mail is already filtered before people see it. [Postmaster Tools dashboards](https://support.google.com/mail/answer/14668346?hl=en).

Track complaints alongside authentication, rejects, temporary deferrals and audience source. An open-rate change alone cannot establish whether the provider accepted the message or why recipients disliked it.

## Investigate the failure before changing sending volume

When a stream starts failing, retain the exact SMTP response, time, recipient provider, sending system, From domain and message type. Compare affected messages with a recent successful example from the same path.

If authentication fails, identify which service sent the message and whether its current signing or envelope domain differs from the expected setup. If authentication passes but complaints rise, examine recipient expectations, targeting, frequency and opt-out handling. Rewriting the SPF record will not solve an audience problem.

For Yahoo, the official SMTP reference distinguishes retryable 4XX responses from permanent or policy failures and provides diagnostic guidance. Use the response category rather than immediately resending every failure as though it were temporary. [Yahoo SMTP errors](https://senders.yahooinc.com/smtp-error-codes/).

![Identify the affected sending path, check authentication and unsubscribe handling, review recipient and delivery evidence, then retest before resuming traffic.](https://www.martechdevs.com/assets/blog/bulk-sender-requirements.svg)

Keep transactional messages and marketing programmes distinguishable in your inventory and monitoring. That makes it easier to isolate a failed stream without losing visibility into critical account messages. Distinct streams do not excuse unwanted mail or remove domain-level obligations.

If you are changing providers, preserve preferences and delivery exclusions during the overlap. The [Braze to Customer.io migration guide](https://www.martechdevs.com/blog/braze-to-customer-io-migration) explains why data imports and send ownership need separate cutover checks.

## What this means for cold outreach

Calling a message a personal sequence does not change its authentication requirements or the receiving provider's ability to filter it. If the content is promotional, assess it as such when implementing opt-out handling.

Google's sender guidance emphasizes sending messages recipients want and making it easy to unsubscribe. Authentication proves something about the sending identity; it does not prove the recipient expected the message or agreed to receive it. [Gmail sender guidelines](https://support.google.com/mail/answer/81126?hl=en).

For a founder, the practical question is whether the targeting and offer justify the interruption, and whether negative feedback changes the programme. A system that continues contacting the same person after an opt-out is an operational failure even if every DNS check is green.

Do not use additional domains, mailboxes or subdomains as a substitute for fixing complaints and preferences. Put ownership of audience selection, message relevance and stopping rules beside ownership of authentication. This article covers provider delivery requirements; jurisdiction-specific marketing rules are a separate input to the sending policy.

## A repeatable sender review

- [ ] Every employee, CRM, product, marketing and support sender is inventoried.
- [ ] Volumes use the receiving provider's scope and relevant domain definition.
- [ ] Actual messages pass the required SPF, DKIM and DMARC checks.
- [ ] Alignment is verified against the visible From domain.
- [ ] The sending provider has correct DNS, transport and message-format configuration.
- [ ] Marketing messages have working header-based unsubscribe and a visible body link.
- [ ] Unsubscribe requests reach the handler and suppress the intended future sends.
- [ ] Preference updates survive queues, imports and cross-tool synchronization.
- [ ] Complaints and failures are monitored by provider and sending stream.
- [ ] Someone owns incident review and the decision to pause or resume a campaign.

Retain a received test message, the observed authentication results, the unsubscribe test outcome and the review date for each sending path. Repeat the relevant checks when adding a vendor, changing domains, rotating keys or migrating providers. Those records are more useful than a one-time screenshot saying the domain passed.

If your CRM, outreach and product tools disagree about sender identity or recipient preferences, our [GTM engineering work](https://www.martechdevs.com/gtm-engineering) can help trace and repair the complete sending path. Start with the failed message and its evidence so the fix addresses the actual source of the problem.

## Frequently asked questions

### Do these requirements apply only above 5,000 emails a day?

No. Google and Yahoo also publish requirements for lower-volume senders, and Yahoo does not publish a numeric bulk threshold. Count mail using each provider's definitions and implement the necessary controls before growth pushes you across a boundary.

### Is publishing a DMARC record enough?

No. The message needs to pass the applicable authentication and alignment checks. Inspect received messages from every sending system. A record at your root domain does not establish that an external vendor is signing or using the envelope domain you expect.

### Must the DMARC policy be reject?

The cited bulk requirements allow a valid minimum policy of `p=none`. Stronger enforcement is a separate domain-protection decision that requires understanding legitimate senders. Neither a minimum policy nor a stricter policy guarantees inbox placement.

### Does every transactional email need one-click unsubscribe?

Google's FAQ excludes transactional messages such as password resets from its one-click requirement. Evaluate the actual content and purpose; adding promotional material can complicate that classification. Keep necessary service-message behaviour separate from optional marketing preferences. [Gmail sender FAQ](https://support.google.com/mail/answer/14229414?hl=en).

### Why is mail still going to spam when authentication passes?

Authentication is one signal. Review complaints, targeting, recipient expectations, unsubscribe processing and the provider's delivery evidence. Confirm that the apparent success belongs to the affected sending path, rather than a different tool or domain that happens to pass your test.

## Sources

1. [Google: sender guidelines FAQ and enforcement](https://support.google.com/mail/answer/14229414?hl=en)

2. [Google: email sender requirements](https://support.google.com/mail/answer/81126?hl=en)

3. [Yahoo: bulk-sender classification FAQ](https://senders.yahooinc.com/faqs/)

4. [Yahoo: sender requirements](https://senders.yahooinc.com/best-practices/?is_listing=false)

5. [Microsoft: updated high-volume sender announcement](https://techcommunity.microsoft.com/blog/microsoftdefenderforoffice365blog/strengthening-email-ecosystem-outlook%E2%80%99s-new-requirements-for-high%E2%80%90volume-senders/4399730)

6. [Microsoft: diagnose Outlook.com error 550 5.7.515](https://support.microsoft.com/en-us/outlook/fix-ndr-error-550-5-7-515-in-outlook-com)

7. [IETF: DMARC, RFC 9989](https://www.rfc-editor.org/rfc/rfc9989.html)

8. [Google Workspace: SPF records](https://knowledge.workspace.google.com/admin/security/about-spf-records)

9. [IETF: one-click unsubscribe, RFC 8058](https://www.rfc-editor.org/rfc/rfc8058.html)

10. [Google: Postmaster Tools dashboards](https://support.google.com/mail/answer/14668346?hl=en)

11. [Yahoo: SMTP error codes](https://senders.yahooinc.com/smtp-error-codes/)