Gmail, Yahoo, Outlook & iCloud Bulk Sender Requirements [2026]

Bulk email rules are no longer just guidelines. Since May 5, 2025, Outlook has sent high-volume email that fails SPF, DKIM, or DMARC checks to the spam folder and can reject it with error 550 5.7.515. Gmail stepped up enforcement in November 2025 with temporary and permanent rejections, while Yahoo has enforced its core requirements since February 2024.

If you send marketing email at scale, this guide breaks down what Gmail, Yahoo, Outlook, and Apple iCloud require in 2026 and shows you how to check that your setup meets those rules.

TL;DR Bulk sender requirements for Gmail, Yahoo, Outlook, and iCloud

Gmail, Yahoo, Outlook, and Apple iCloud Mail require bulk senders to authenticate their domain with SPF and DKIM and publish a DMARC record, with p=none as the minimum for Gmail, Yahoo, and Outlook. Gmail and Yahoo also require a one-click unsubscribe option for marketing emails and a spam complaint rate below 0.3%. Gmail and Outlook apply their bulk rules at about 5,000 emails a day, while Yahoo and Apple publish no threshold. Some rules apply to every sender regardless of their sending volume. Since 2024, the biggest change has been enforcement: non-compliant email can now be rejected by all four providers.

Note: The requirements in this guide are based on the providers’ official documentation as of November 2026, namely Google’s email sender guidelines and sender guidelines FAQ, Yahoo’s sender requirements and recommendations and Sender Hub FAQs, Microsoft’s Outlook.com postmaster policies and support article for error 550 5.7.515, and Apple’s postmaster page for iCloud Mail. Providers update these pages without much notice, so if anything in this guide differs from the latest provider documentation, use the provider’s current guidance.

Who counts as a bulk sender for Gmail, Yahoo, and Outlook?

The 5,000-emails-a-day threshold doesn’t apply equally to every provider. Gmail and Outlook publish a specific volume threshold, while Yahoo doesn’t specify one.

Gmail’s bulk sender threshold

According to Gmail’s sender guidelines FAQ, bulk sender requirements apply when you send around 5,000 or more messages to personal Gmail accounts within 24 hours. Messages from the same primary domain count together, including those sent from its subdomains.

For instance, if you send 2,500 emails from example.com and another 2,500 from news.example.com to personal Gmail accounts in one day, all 5,000 count toward example.com. Once a domain reaches bulk sender status, that status doesn’t expire even if your sending volume later drops.

Yahoo’s bulk sender threshold

Yahoo doesn’t publish a fixed daily limit for classifying bulk senders. It defines a bulk sender only as one sending a significant volume of emails and states plainly: “We will not specify a volume threshold.”

Instead, Yahoo identifies the sender by the authenticated domain or the From header domain. It then uses all available information, including message content and sending IP, to review whether that sender complies with its requirements.

Don’t assume you’re exempt from Yahoo’s bulk sender requirements just because you send fewer than 5,000 emails a day.

Outlook’s bulk sender threshold

According to Outlook.com Postmaster policies and Microsoft’s support article for error 550 5.7.515, Microsoft’s requirements apply once your domain sends about 5,000 emails a day to Outlook.com and related Microsoft consumer services, such as Hotmail, Live.com, and MSN. Microsoft counts messages by the domain in the From address and doesn’t specify whether Microsoft 365 business mailboxes are included.

Above that threshold, messages from the domain need to meet Microsoft’s authentication requirements: SPF and DKIM must pass, a DMARC record of at least p=none must be published, and either SPF or DKIM must align with the From domain.

What if you send fewer than 5,000 emails a day?

Lower volume doesn’t mean there are no rules. Each provider still has baseline requirements for regular senders:

• Gmail. SPF or DKIM, valid forward and reverse DNS (PTR) records, TLS encryption, RFC 5322 formatting, and a spam complaint rate below 0.3%.
• Yahoo. SPF or DKIM, valid forward and reverse DNS records, compliance with RFC 5321 and RFC 5322, and a spam complaint rate below 0.3%.
• Outlook. Valid reverse DNS, an easy-to-find unsubscribe option, and no repeat sends after a permanent (5xx) error. SPF, DKIM, and DMARC become mandatory above 5,000 emails a day, although Microsoft “strongly recommends” them for all senders.

It’s better to set up authentication before your sending volume grows. Otherwise, you may end up fixing SPF, DKIM, or DMARC only after campaigns start getting rejected.

What email authentication do Gmail, Yahoo, and Outlook require from bulk senders?

SPF, DKIM, and DMARC work together to verify that your emails come from an authorized source. Gmail, Yahoo, and Outlook require bulk senders to use all three, but each one checks a different part of the sending setup.

SPF requirements for bulk senders

Sender Policy Framework (SPF) lists the mail servers allowed to send email on behalf of your domain. Receiving servers check it against the envelope sender domain, also known as the Return-Path or MAIL FROM domain. That’s why Gmail’s SPF errors refer to the “(E)MAIL FROM domain.”

A few SPF details are especially important:

• One SPF record per domain. Your record should include every service that sends email using that domain, including your email marketing platform.
• A maximum of 10 DNS lookups. Under RFC 7208, include, a, mx, ptr, and exists mechanisms, as well as the redirect modifier, count toward the limit. Lookups inside included records count too. The ip4, ip6, and all mechanisms do not. Going past 10 results in a permanent error (permerror), so SPF won’t pass.
• Extra care with a hard-fail policy. A record ending in -all specifies that mail from unauthorized sources should fail SPF. Gmail can reject messages with error 550 5.7.26 when a domain uses -all and the SPF check fails.

SPF alone can still leave an alignment gap. An email platform may pass SPF using its own bounce domain rather than the domain in your visible From address. Signing with DKIM on your own domain, or using a custom Return-Path on your domain, helps close that gap.

DKIM requirements for bulk senders

DomainKeys Identified Mail (DKIM) adds a digital signature to each message. That signature lets receiving servers verify that the message was authorized by the signing domain and wasn’t changed in transit.

For bulk sending, 2048-bit DKIM keys are recommended. Gmail requires at least 1024 bits.

If you use an email service provider (ESP), set up DKIM with your own domain rather than relying only on the provider’s signing domain. That keeps your sending identity consistent and helps satisfy DMARC alignment.

DMARC and domain alignment requirements

Domain-based Message Authentication, Reporting, and Conformance (DMARC) builds on SPF and DKIM. It verifies whether the domain authenticated by either method matches the domain shown in the From address. It can also define how messages that fail authentication should be handled.

This match is called domain alignment, and it can be relaxed or strict. With relaxed alignment, a subdomain such as mail.example.com can align with example.com. Strict alignment requires an exact domain match. The adkim and aspf tags define which mode applies.

Gmail, Yahoo, and Outlook require bulk senders to align the From domain with SPF or DKIM. Yahoo accepts relaxed alignment and also requires DMARC to pass. Microsoft requires alignment with SPF or DKIM and recommends using both where possible.

For example, if you send a campaign from newsletter@example.com, DKIM should pass with example.com or an aligned subdomain. A signature that uses only an unrelated domain belonging to your email provider won’t meet the alignment requirement.

The same limitation applies to free mailbox addresses. If you send bulk email through an ESP using an email address such as yourname@gmail.com, you can’t authenticate gmail.com yourself, so DMARC alignment isn’t possible. Google also warns against using Gmail email addresses in the From field for bulk sending because its DMARC enforcement can affect delivery.

A basic DMARC record might look like this:

• Host. _dmarc.example.com
• Type. TXT
• Value. v=DMARC1; p=none; rua=mailto:dmarc@example.com

The p=none policy enables monitoring without instructing receiving servers to quarantine or reject messages that fail. The rua address is used for aggregate DMARC reports, and Yahoo strongly recommends including one.

DMARC policy levels for bulk senders: p=none, p=quarantine, p=reject

Is p=reject mandatory in 2026? No. Gmail, Yahoo, and Outlook accept p=none as the minimum DMARC policy, although Microsoft recommends moving toward p=reject.

For a typical marketing domain, it makes sense to begin with p=none and review your reports for a few weeks. Fix any legitimate sending sources that fail authentication before moving to p=quarantine and, later, p=reject if that level of enforcement suits your setup.

There’s no fixed timetable for making those changes. A stricter policy gives you more protection against domain impersonation, but it can also block legitimate emails if SPF or DKIM isn’t configured correctly.

The updated DMARC standard adds two points worth keeping in mind:

• Domains using p=reject must not rely on SPF alone for DMARC to pass and must apply valid DKIM signatures.
• Domains used by people who post to mailing lists should not publish p=reject. This matters more for company mailbox domains than for dedicated marketing subdomains.

The old pct tag, which was commonly used to roll out enforcement gradually, is no longer part of the current standard. RFC 9989 introduces the t tag for testing behavior instead.

DMARCbis (RFC 9989) and bulk sender requirements

On May 19, 2026, the IETF published RFC 9989, the updated DMARC standard commonly called DMARCbis, as a Proposed Standard. Reporting moved into two companion documents: RFC 9990 for aggregate reporting and RFC 9991 for failure reporting. Together, they replace the original RFC 7489.

The main changes include:

• The new t tag. This provides a way to request testing behavior before fully enforcing a policy.
• The np tag. This defines how to handle messages from non-existent subdomains of your organizational domain.
• The psd tag. This identifies a domain as a public suffix domain.
• Removal of pct, rf, and ri. These older percentage, failure-report format, and reporting-interval tags are no longer valid DMARC tags.
• DNS Tree Walk. The organizational domain is now determined using a DNS Tree Walk rather than relying only on the Public Suffix List.

These updates matter mostly to teams managing DNS and authentication directly. They don’t introduce a new Gmail, Yahoo, or Outlook bulk sender requirement, and the providers’ published minimum DMARC policy remains p=none.

What one-click unsubscribe rules are set for bulk senders?

Gmail and Yahoo require bulk senders to support one-click unsubscribe in marketing and promotional emails. This gives recipients a way to leave a mailing list directly from their inbox, without logging in, filling out a form, or opening a separate unsubscribe page.

One-click unsubscribe headers (RFC 8058)

A marketing email needs two things: a visible unsubscribe link in the message itself and the headers required for one-click unsubscribe. Gmail requires both, and Yahoo follows the same approach.

Here’s how that looks in a real marketing email from Levi’s. The regular unsubscribe link appears in the footer, as it does in most campaigns:

That link alone doesn’t meet the one-click requirement. The email also needs the appropriate headers, which allow Gmail to display an “Unsubscribe” button next to the sender’s name:

The RFC 8058 standard defines how this works with two headers:

• List-Unsubscribe: <https://example.com/unsubscribe/123>
• List-Unsubscribe-Post: List-Unsubscribe=One-Click

You can check them in the source of a sent email. In Gmail, open the message, click ⋮ next to the sender, and select “Show original.” In the Levi’s example, the headers look like this:

The first header contains the HTTPS address used for the unsubscribe request. The second enables one-click processing through a POST request.

RFC 8058 also sets two important technical requirements:

• DKIM coverage. Both headers need to be included in a valid DKIM signature. In the Levi’s email, the DKIM-Signature header includes both in its h= tag. Without that coverage, the message doesn’t meet the RFC 8058 one-click standard.
• POST-only processing. The unsubscribe endpoint needs to complete the request from the POST itself, without requiring a confirmation page, cookies, or a redirect.

Yahoo also accepts a mailto address, although it describes the RFC 8058 POST method as highly recommended.

Most email platforms add these headers automatically. It’s still worth checking the source of a sent campaign to confirm that they’re present.

Unsubscribe processing deadlines

Each provider sets its own deadline for processing unsubscribe requests:

• Gmail. Google recommends completing requests within 48 hours. If that doesn’t happen, delivery support and mitigations may no longer be available.
• Yahoo. Unsubscribe requests need to be honored within two days.
• Outlook. Microsoft’s policy doesn’t set a deadline, but it requires an unsubscribe method that’s easy to find and use.
• Apple iCloud Mail. The unsubscribe link needs to allow recipients to unsubscribe immediately.

In practice, there’s little reason to use the full window. Your email platform should suppress an unsubscribed contact before another campaign is sent to them.

One-click unsubscribe for transactional emails

One-click unsubscribe isn’t required for every type of email. Gmail applies the requirement to marketing and promotional emails, not transactional messages such as password resets, reservation confirmations, or form submission confirmations. Yahoo makes the same distinction and gives order confirmations and password resets as examples.

The purpose of the message matters here. An order confirmation with a promotional offer added to it starts to blur the line between transactional and marketing email.

Keeping the two types of email separate is the safer setup. For example, campaigns could use news.example.com, while order emails use mail.example.com.

One-click unsubscribe requirements for Outlook

Microsoft’s current Outlook policy doesn’t specifically require RFC 8058 one-click unsubscribe. It does require every sender to provide an unsubscribe method that is clearly documented and easy for recipients to find and use.

If your campaigns go to Gmail, Yahoo, and Outlook users, maintaining different unsubscribe setups usually isn’t worth the extra complexity. Using RFC 8058 one-click unsubscribe on every marketing email, keeping a visible unsubscribe link in the body, and processing requests right away (and never later than 48 hours) covers the stricter requirements and gives recipients a simpler way to opt out.

What spam complaint and bounce rates do Gmail, Yahoo, and Outlook set?

Passing SPF, DKIM, and DMARC doesn’t guarantee inbox placement. Complaint rates matter too, and Gmail and Yahoo publish specific thresholds. Bounce handling is another factor, with Gmail, Yahoo, Microsoft, and Apple each publishing guidance on how to respond to SMTP errors.

Spam complaint rates for bulk senders

Gmail and Yahoo both require a spam complaint rate below 0.3% from all senders, and Gmail recommends keeping it under 0.1%. Outlook and Apple iCloud Mail don’t publish a limit.

A 0.3% rate works out to roughly 3 spam reports for every 1,000 emails delivered to the inbox. At Gmail, going above that threshold has a specific consequence. Since June 2024, bulk senders with a spam rate above 0.3% cannot get mitigation. You become eligible again only after your rate stays below 0.3% for seven days in a row.

Both Gmail and Yahoo calculate the rate from emails that reach recipients’ inboxes, not from everything you send:

Spam complaint rate (%) = (Spam complaints ÷ Emails delivered to inboxes) × 100

Case in point: if 10,000 emails reach inboxes and 20 recipients mark them as spam, the complaint rate is 0.2%. This is under the 0.3% limit, but it is still double Gmail’s recommended 0.1%.

Gmail narrows the count further. The spam rate in Google Postmaster Tools covers only DKIM-authenticated messages delivered to engaged recipients’ inboxes, so it’s based on a smaller set of messages than the delivered total your email platform reports. Check both: a low complaint rate in your ESP dashboard doesn’t guarantee a low rate in Gmail.

High complaint rates often come down to a few familiar problems: recipients don’t remember subscribing, the unsubscribe option is difficult to find, or emails arrive more often than expected. A few practices can lower that risk:

• Confirmed permission. Send emails only to people who opted in, and use confirmed opt-in where it makes sense. Apple requires bulk email to go only to recipients who explicitly subscribed and doesn’t allow purchased or rented lists.
• Easy unsubscribing. Make sure your emails have a clear unsubscribe link and allow one-click unsubscribing. This way, it’s easier for people to leave your list than to mark your message as spam.
• Automatic complaint suppression. Remove recipients who submit spam complaints from future sends. Yahoo requires an active Complaint Feedback Loop for all DKIM domains, while Microsoft provides the Junk Mail Reporting Program (JMRP).
• Consistent list and sending practices. Suppress contacts who remain inactive after a re-engagement attempt, avoid overlapping campaigns, and keep sending domains and IP addresses consistent. Apple requires consistent sending IPs and domains for bulk email. Long-inactive Yahoo email addresses need extra care too. After 12 months without mailbox access, a Yahoo Mail mailbox becomes inactive and stops receiving new email.

Bounce handling for bulk senders

Gmail, Yahoo, Outlook, and Apple don’t publish a numerical bounce rate limit, including the 2% figure that is often quoted. What they do publish is guidance on handling delivery failures. Here’s what each provider asks for:

• Gmail delivery errors. Google advises reducing your sending volume until the error rate drops, then ramping back up gradually. It also suggests automatically unsubscribing recipients with multiple bounces.
• Permanent Outlook errors. After a permanent 5xx error, don’t retransmit the same message to that recipient. After repeated non-delivery responses, stop sending to that email address altogether.
• Permanent Yahoo errors. A 5xx response should not be retried. A 4xx response is temporary, so another delivery attempt can be made later.
• Apple delivery errors. Temporary and permanent errors need to be monitored and handled accordingly.

In practice, remove hard bounces such as non-existent email addresses (Gmail’s 550 5.1.1) after the first permanent failure, and suppress emails that continue to soft-bounce. Read the full response before removing anyone: Gmail also uses 550 5.2.1 both for inactive accounts and for recipients who are receiving too much email.

A sudden increase in bounces can also point to a wider delivery problem rather than a bad batch of email addresses. Before sending the next campaign, check the SMTP error codes for authentication failures, reputation blocks, or other provider-specific reasons.

What other technical requirements do Gmail, Yahoo, and Outlook set for bulk senders?

SPF, DKIM, and DMARC prove who sent a message, but providers also check how messages are transmitted, formatted, and routed. Your ESP usually handles most of this in the background, but these details become useful when you’re troubleshooting delivery issues.

TLS encryption requirements

Transport Layer Security (TLS) encrypts email while it moves between mail servers. It protects messages in transit, but it doesn’t verify the sender, so it complements SPF, DKIM, and DMARC rather than replacing them.

Of the four providers, only Gmail makes TLS an explicit requirement. Google added it to its sender guidelines in December 2023 and doesn’t specify a version, so TLS 1.3 isn’t required. If you send without TLS, Gmail can rate-limit your email with error 421 4.7.29 or reject it with 550 5.7.29.

To see how much of your email reaches Gmail over an encrypted connection, check the Encryption dashboard in Google Postmaster Tools.

Yahoo, Microsoft, and Apple don’t list TLS in their sender requirements. Microsoft’s closest rule is that messages “must not be transmitted through insecure email relay or proxy servers.”

Reverse DNS (PTR) requirements

While TLS protects the connection, reverse DNS identifies the server on the other end of it. A PTR record links your sending IP address to a hostname, so receiving servers can check which server is delivering the email.

Unlike TLS, this is something all four providers ask for. Gmail and Yahoo require valid forward and reverse DNS for sending IPs, Microsoft requires email servers to have valid reverse DNS records, and Apple includes reverse DNS in its bulk sender requirements.

In a correct setup, the sending IP resolves to a hostname, and that hostname resolves back to the same IP. If the PTR record is missing, Gmail can rate-limit your email with error 451 4.7.23 or reject it with 550 5.7.25.

Who manages this depends on your setup. With a shared email marketing service, the provider usually takes care of these records. If you run your own mail server or use a dedicated IP, check the setup with your hosting or email provider.

Message formatting requirements

Even an authenticated email from a correctly configured server can run into problems if the message itself is malformed. That’s why Gmail, Yahoo, and Apple require messages to follow the Internet Message Format standard in RFC 5322, and Yahoo and Apple also reference RFC 5321.

For most marketers, these standards come down to three checks:

• Required message headers. Every message needs a valid From address and Date header.
• Message identification. Gmail asks for a valid Message-ID in every message.
• No invalid duplicate headers. Headers that should appear only once, such as From, Date, or Subject, shouldn’t be duplicated.

Most ESPs generate compliant messages automatically, so manual checks are usually needed only when troubleshooting or when email is sent through a custom system.

ARC requirements for forwarded email

Authentication can break after an email leaves your server. When a mailing list or forwarding service resends a message, it arrives from a different server, so SPF can fail even though the original message was legitimate.

Authenticated Received Chain (ARC) preserves the authentication results from earlier stages of the delivery path. Those results provide evidence that the message passed authentication before it was forwarded.

ARC requirements differ by provider. Apple requires bulk senders to add ARC headers to forwarded messages, while Yahoo recommends ARC for forwarded email. Google’s sender guidelines and forwarding best practices don’t mention ARC. Instead, Google recommends adding X-Forwarded-For or X-Forwarded-To headers and changing the envelope sender to the forwarding domain.

These rules mostly apply to services that forward email. If you send regular marketing campaigns through an ESP, ARC usually doesn’t require any setup on your side.

MTA-STS requirements

Is MTA-STS required for bulk senders? No. Mail Transfer Agent Strict Transport Security (MTA-STS) is sometimes mistaken for a sending requirement, but it works in the opposite direction. It applies to incoming email, letting a domain require trusted TLS connections for messages delivered to it.

None of the four providers includes MTA-STS in its sender requirements for 2026. It becomes relevant when your organization manages its own receiving mail infrastructure, not when you send marketing campaigns through an ESP.

Does Apple iCloud Mail have bulk sender requirements?

Yes. Apple lists requirements for bulk senders on its postmaster page for iCloud Mail, dated February 25, 2025. It doesn’t specify a volume threshold or an enforcement date, but the requirements are mandatory: “All requirements must be met… If not, the email will be rejected.”

Much of Apple’s guidance overlaps with what we’ve already covered: SPF and DKIM, a published DMARC record, valid reverse DNS, compliance with RFC 5321 and RFC 5322, and an unsubscribe option. Unsubscribe requests also need to be processed immediately, which is the shortest deadline among the four providers.

A few additional requirements are worth noting:

• Explicit opt-in only. Send email only to people who subscribed themselves. Purchased lists, rented lists, and email appends are not allowed.
• A consistent sending identity. Use the same sending IP addresses, domains, and From name and address over time.
• Separate sending streams. Keep marketing and transactional email separate.
• ARC on forwarded mail. Add ARC headers to forwarded messages.
• SMTP error tracking. Monitor temporary and permanent SMTP errors returned by iCloud and adjust sending accordingly.
• List hygiene. Have a standard policy for bounced email addresses, remove inactive subscribers periodically, and never re-add email addresses from your unsubscribe or suppression list.

Apple doesn’t provide a feedback loop or an allowlist for bulk senders. That makes SMTP responses and the delivery data in your ESP reports the main sources for monitoring delivery to iCloud Mail.

What happens if your emails don’t meet the bulk sender requirements?

If a message doesn’t meet a provider’s bulk sender requirements, delivery may be delayed, redirected to spam, or rejected altogether. Apple only states that bulk email that fails to meet every requirement “will be rejected.” Gmail, Yahoo, and Microsoft provide more detail through SMTP error codes, which can help narrow down the cause.

Gmail deferrals and rejections

Since November 2025, messages that don’t meet Gmail’s requirements can face temporary and permanent rejections. Codes beginning with 4 indicate a temporary problem, so the sending server can retry later. Codes beginning with 5 indicate a permanent failure.

These are some of the errors most closely tied to Gmail’s sender requirements:

You can find the complete list in Gmail’s guidelines for SMTP errors and codes.

Yahoo deferrals and blocks

Yahoo can temporarily defer email when complaint rates are high. Non-compliant messages may also end up in spam or be rejected.

Yahoo’s SMTP error codes fall into four main groups:

• 421 or 451 errors. These indicate a temporary delivery problem, such as unusual traffic, high complaint levels, or authentication results that couldn’t be determined. Check authentication, sending patterns, and complaint rates before retrying later.
• 553 or 554 errors. These indicate a permanent problem, such as an invalid email address or a message that “failed authentication checks against your sending domain’s DMARC or DKIM policy.” Use the full SMTP response to identify the cause, and don’t retry the same message.
• TS* errors. These are temporary deferrals, so the sending server can retry later.
• PH* errors. These are content-based blocks, so start by reviewing the message itself.

Outlook error 550 5.7.515

Under Microsoft’s policy for high-volume senders, non-compliant messages are sent to the junk (spam) folder and, if the issues aren’t fixed, may be rejected with this error:

550 5.7.515 Access denied, sending domain [SendingDomain] does not meet the required authentication level.

This means Outlook rejected the message because the sending domain didn’t meet its authentication requirements.

It can indicate that SPF or DKIM failed, the sending domain has no DMARC record, or neither SPF nor DKIM aligns with the From domain. Check all three authentication records and their alignment.

How to fix a bulk sender rejection

The exact fix depends on the SMTP response, but the troubleshooting process is similar across providers:

1. Find the full SMTP response. Check your ESP’s delivery report; don’t rely only on a general bounce category.
2. Match the error to the failed requirement. For Gmail, Yahoo, and Outlook, use the error codes above. For iCloud Mail, compare your setup with Apple’s requirements in the previous section. Then correct the relevant DNS record, sending configuration, or message issue.
3. Resume gradually. Start with a smaller send and check the delivery results before returning to your normal volume.
4. Contact support if the error continues. Send the full SMTP response to your ESP’s support team so they can investigate the specific rejection.

How do you check if your emails meet the bulk sender requirements?

Your ESP’s delivery reports can confirm which messages were accepted or bounced, but they don’t give you the full compliance picture. For authentication, complaint, and reputation data, use the monitoring tools provided by mailbox providers and inspect your email headers. For iCloud Mail, SMTP responses are your main delivery signal, and the header check below confirms your authentication.

Compliance checks in Google Postmaster Tools v2

Google Postmaster Tools shows Gmail delivery data for domains you’ve verified. The current version, Postmaster Tools v2, has a Compliance status dashboard that shows whether your domain meets Gmail’s sender requirements. It’s available to all senders, not only bulk senders.

To get started, sign in at postmaster.google.com/v2, add your domain, and verify ownership by adding the TXT or CNAME record that Google provides to your DNS.

The dashboard checks two groups of requirements:

• All senders. “SPF and DKIM authentication,” “DNS records,” “Message formatting,” “Encryption,” and “User-reported spam rate.”
• Bulk senders only. “DMARC authentication,” “One-click unsubscribe,” and “Honor-unsubscribe.”

Each requirement gets one of three statuses:

• Compliant. Your setup meets the requirement, and no action is needed.
• Needs work. Something needs fixing, and the status column describes what to change.
• No data found. There isn’t enough email traffic to evaluate the requirement.

The dashboard doesn’t reflect fixes right away. Compliance status is based on a rolling average of data gathered over several days, so after you correct an issue, it can take up to seven days for the status to change. DNS checks also reflect the records Gmail saw when it received your emails, not your current configuration.

The other dashboards cover spam rates, IP and domain reputation, feedback loop data, authentication results, encryption, and delivery errors. Data usually updates within 24 hours.

Complaint checks with the Yahoo Complaint Feedback Loop

For Yahoo, complaint data is available through the Complaint Feedback Loop (CFL). Once you enroll a DKIM domain, Yahoo sends you a report whenever a Yahoo user marks a message signed with that domain as spam.

Enroll every domain you use for DKIM signing. In addition to suppressing recipients who submit complaints, use the reports to identify campaigns, segments, or signup sources associated with higher complaint rates.

Reputation and complaint checks in Microsoft SNDS and JMRP

Microsoft provides two programs for email sent to Outlook.com, both referenced in its Postmaster policies:

• Smart Network Data Services (SNDS). Provides IP-level data on sending traffic and reputation.
• Junk Mail Reporting Program (JMRP). Provides reports when Outlook.com users mark your messages as spam, so those contacts can be suppressed from future sends.

Access is managed through the Outlook.com Postmaster site.

Neither program provides a compliance status for Microsoft’s high-volume sender requirements. To verify SPF, DKIM, DMARC, and domain alignment, inspect the headers of a test email.

Authentication and unsubscribe checks in email headers

Header checks work across providers and only take a few minutes. Send a test campaign to your own Gmail or Outlook inbox, then open its headers:

• Gmail. Open the message, click the three-dot menu, and select “Show original.”
• New Outlook. Open the message and select “More actions” > “View” > “View message details.”
• Classic Outlook for Windows. Open the message in a separate window, select “File” > “Properties,” and look in the “Internet headers” box.

In the Authentication-Results header, look for these three results:

• spf=pass
• dkim=pass
• dmarc=pass

Gmail also summarizes these results at the top of the “Show original” page.

Next, check domain alignment. With DMARC’s default relaxed alignment, the domain that passes SPF or DKIM should share its root domain with the From domain. For instance, a From address on news.example.com aligns with a DKIM signature from example.com.

In the example below, DKIM passes for bestfernway.store, which matches the domain used in the From address. DMARC therefore passes as well.

Compare it with a test email sent from a free Gmail email address with no authenticated domain. SPF and DKIM still pass, but for SendPulse’s own domain, sendpulse.me, not for gmail.com in the From address. Because neither result aligns with the From domain, DMARC fails. Authenticating your own domain fixes this.

For marketing emails, also check for the List-Unsubscribe and List-Unsubscribe-Post headers. Both need to be covered by DKIM, so confirm that they appear in the h= tag of the DKIM-Signature header. Finally, use the unsubscribe option in your test email and confirm that the contact is removed or suppressed as expected.

Bulk sender requirements checklist

Use this checklist before launching a large campaign or adding a new sending domain:

A “—” means the item isn’t included in that provider’s published requirements, although many of these practices are useful across providers.

Once the setup is in place, keep the monitoring tools above active. Meeting the technical requirements doesn’t guarantee inbox placement, so keep checking complaint rates, reputation data, and delivery errors as your sending volume grows.

Is BIMI required for bulk senders?

No. BIMI isn’t part of the bulk sender requirements published by Gmail, Yahoo, Outlook, or Apple. Brand Indicators for Message Identification (BIMI) is an optional standard that can add your brand logo next to your emails in supported inboxes, making your messages easier to recognize.

BIMI has stricter prerequisites than the basic bulk sender requirements. For Gmail, Google’s BIMI setup guide includes these requirements:

• An enforced DMARC policy. The policy must use p=quarantine or p=reject. A p=none policy is enough for the bulk sender requirements, but not for BIMI.
• The pct option set to 100. Google’s BIMI guide says pct “must be set to 100.” Its DMARC guide adds that a record without pct applies the policy to 100% of messages, and in practice Gmail shows verified logos for senders without the tag (LinkedIn’s DMARC record, for example, has no pct). Still, adding pct=100 explicitly is the safest way to match Google’s instructions.
• A logo in SVG Tiny Portable/Secure (SVG Tiny PS) format. Your BIMI DNS record points to the logo’s URL.
• A Verified Mark Certificate (VMC) or Common Mark Certificate (CMC). In Gmail, senders verified with a VMC can also get a checkmark next to their name.

BIMI support varies by provider. Yahoo’s BIMI requirements are looser than Gmail’s: Yahoo requires a DMARC policy of quarantine or reject and a BIMI record that points to an SVG logo, but it doesn’t require a VMC. If one is present, Yahoo may use it as part of its eligibility checks. Logos are displayed only for bulk senders with “sufficient reputation and engagement” in the Yahoo and AOL mobile apps and in the read view of desktop webmail.

Apple Mail supports BIMI in iOS 16, iPadOS 16, macOS Ventura 13 or later, and on iCloud.com. Apple also supports VMCs and other forms of BIMI Evidence Documents.

Microsoft’s postmaster policy doesn’t mention BIMI. Its own BIMI documentation names Google, Fastmail, and Yahoo as examples of supporting providers, but not Outlook.

Even with BIMI configured correctly, logo display isn’t guaranteed. Each provider applies its own eligibility criteria.

BIMI is worth implementing if you send branded campaigns regularly, already enforce DMARC, and have a good sender reputation. It can make your emails easier to recognize, but it doesn’t fix authentication or deliverability problems.

How have the bulk sender requirements changed since 2024?

Since 2024, the biggest change has been stricter enforcement rather than a new set of rules. Gmail and Yahoo introduced their requirements in February 2024, Microsoft’s requirements took effect in May 2025, and Gmail ramped up enforcement in November 2025, including temporary and permanent rejections for non-compliant email. The DMARC standard was also updated in 2026, but the providers haven’t raised their DMARC minimum.

Bulk sender requirements timeline from 2023 to 2026

The requirements came into effect in stages. Gmail and Yahoo allowed extra time for one-click unsubscribe, while Gmail introduced stricter consequences for high spam rates after the initial rollout.

Here are the main milestones, starting with the most recent:

If you updated your email setup in 2024, it’s worth checking it again, especially if you’ve added new sending domains or email platforms since then.

Unconfirmed 2026 bulk sender rule changes

Not every “new rule” circulating online appears in the providers’ published policies. These common claims don’t match the providers’ current published requirements:

• “DMARC p=reject is now mandatory.” No. Gmail, Yahoo, and Microsoft still accept p=none as the minimum, even after DMARCbis. Microsoft recommends p=reject but doesn’t require it.
• “TLS 1.3 or MTA-STS is mandatory.” Not in the published requirements. Gmail requires TLS but doesn’t specify a version, and none of the four providers requires MTA-STS.
• “The 5,000-email threshold has been lowered.” No published change indicates this. Gmail still refers to “close to 5,000 messages,” Microsoft to “more than 5,000 emails per day,” and Yahoo doesn’t publish a numerical threshold.
• “Outlook blocks senders with an open rate below 8%.” Microsoft’s published policies contain no such requirement.

Before changing your setup because of a reported new rule, check it against the official providers’ pages listed at the top of this guide.

How to meet the bulk sender requirements in SendPulse

SendPulse provides tools to help you authenticate your sending domain, manage unsubscribes, and maintain a healthy mailing list. Here’s what to check before launching your next email campaign.

Authenticate your sending domain

Start by adding and verifying your sending domain. Go to “Email” > “Settings” > “Domain settings” and, in the “Authenticated domain” section, click “Activate.” The number of domains you can authenticate depends on your pricing plan.

Add the SPF and DKIM records SendPulse shows you to your domain’s DNS. SPF is a TXT record at @, such as v=spf1 include:mxsspf.sendpulse.com +a +mx ~all, and DKIM is a TXT record named sign._domainkey. If your domain already has an SPF record, add SendPulse’s include to it instead of creating a second one. After adding the records, click “Check DNS records.”

DNS changes can take up to 24 hours to take effect, and the domain status will change from “Awaiting confirmation” to “Connected.”

Make sure your sender email address uses the domain you authenticated, since SendPulse notes that the two must match. If you’ve authenticated several domains, specify the right one in your sender address settings.

Next, publish a DMARC record by following SendPulse’s DMARC setup guide. Start with p=none and a rua address, analyze the reports, and then move to quarantine or reject.

Once all three records are in place, green DKIM, SPF, and DMARC badges appear next to your domain on the “Domain settings” tab.

Set up unsubscribe options

SendPulse automatically adds an unsubscribe link to your email if your template doesn’t include one, and you can place your own with the {{unsubscribe_url}} variable.

SendPulse also adds one-click unsubscribe headers (List-Unsubscribe and List-Unsubscribe-Post) to campaigns automatically and covers them with its DKIM signature, so Gmail and Yahoo can show their own Unsubscribe button. There’s nothing to configure.

To make unsubscribing feel like part of your brand, create a custom unsubscribe page. Go to “Email” > “Settings” > “Subscription tools” and click “Add unsubscribe page.”

Add your company name or logo, choose brand colors, and select the form language. You can even add a short survey to find out why subscribers are leaving or let them pause your emails for 90 days instead of unsubscribing, which helps keep people who just need a break. New pages go through moderation, which usually takes 10 to 30 minutes.

Keep spam complaints and bounces under control

Spam complaints and bounces often come down to two things: list quality and sending habits. SendPulse has a few tools that can help with both.

• Email verification. Use the email verifier to check email addresses before sending. Results are grouped as valid, invalid, or unconfirmed. You can verify up to 100 emails a month for free.
• Bounce handling. Email addresses that hard-bounce or repeatedly soft-bounce receive the “Disabled by moderator” status and are excluded from future sends.
• Inactive contact cleanup. Go to “Email” > “Mailing lists,” click “Update contacts and lists,” and select “Find inactive contacts.” You can filter by status, including unsubscribed or disabled, or find contacts who haven’t opened 20 or more previous campaigns within six, nine, or 12 months. From there, you can delete them or move them to another list.
• Spam checks before sending. SendPulse estimates spam risk while you prepare a campaign. If anything needs attention, anti-spam recommendations appear at the “Preview and send” step.

A simple routine helps here: verify new email addresses before the first campaign, then review inactive contacts every few months. That can keep your complaint and bounce rates low as your list grows.

Final thoughts

Meeting the bulk sender requirements comes down to a handful of habits. Set up SPF and DKIM, publish a DMARC record, support one-click unsubscribe, and process unsubscribe requests promptly. Keep spam complaint rates well below 0.3%, and check your message headers and Postmaster data regularly for authentication or delivery issues.

Technical compliance is only one part of good email performance. Some subscribers may stop engaging with email but still prefer another communication channel. Say they’ve opted in to WhatsApp or Telegram; a chatbot can be a better way to continue the conversation. SMS can also make sense for urgent or time-sensitive updates. Using the communication channel that fits the message and the subscriber’s preferences can reduce unnecessary emails and, in turn, the risk of spam complaints.

SendPulse combines email campaigns, chatbots, SMS, and a built-in CRM system, so your contact data and conversation history are stored in one place. This makes it easier to segment audiences by interests and engagement across your communication channels. You can start on the free plan and add tools as your business grows.