Do the bulk sender rules apply to transactional email?

The authentication requirements apply to all of your mail above the threshold, including order confirmations and password resets. The one-click unsubscribe requirement is the exception: Google states it applies to commercial and promotional messages and not to transactional mail such as password resets, reservation confirmations and form submission confirmations.

I send 500 messages a day. Can I ignore all of this?

No. Google requires SPF or DKIM and valid forward and reverse DNS of every sender to Gmail at any volume, a rule that started on 1 February 2024, and a DMARC record is what makes those two checks mean anything. Volume also only has to cross the line once at Gmail for the bulk sender classification to stick.

Is p=none enough, or do I need p=reject?

All three providers accept a DMARC policy of at least p=none, so p=none meets the requirement. It does not stop anyone from sending mail as your domain, which is the reason to ramp to p=reject afterwards, once the aggregate reports show every legitimate sending source passing and aligned.

Bulk sender requirements: Gmail, Yahoo and Microsoft

A 14-person online store called us after their order confirmations stopped reaching about half of their customers. Nothing had changed on their side. What changed is that the three mailbox providers those customers use have each published a list of requirements for domains that send at volume, and the store crossed the line the month it ran its first real campaign.

The three lists overlap, which is the good news. They are not identical, which is where people get caught. A domain can satisfy Gmail and still be rejected outright by Outlook.com, because the providers differ on what happens when you fail rather than on what they ask for. Below is the comparison we work from on client projects, with every row taken from the provider's own page and the date we checked it.

Where the three providers agree, and where they do not

Everything in this table was checked on 16 October 2026 against the pages listed at the end of the post. Where a provider does not publish a figure, the cell says so rather than borrowing a number from somewhere else.

Requirement	Gmail	Yahoo	Outlook.com
Who the volume rules apply to	Senders of more than 5,000 messages a day to personal Gmail accounts; the FAQ says close to 5,000 or more in any 24-hour period, and the classification sticks once reached	Bulk senders. Yahoo's best practices page states the rules without publishing a daily number	Domains sending 5,000 or more messages a day to Outlook.com, Hotmail and Live addresses, counted by the domain in the `5322.From` address
SPF and DKIM	Both required above the threshold. SPF or DKIM is required of every sender, at any volume, since 1 February 2024	Both required	Both required, and both must pass
DMARC record	Required; `p=none` is accepted	Required; at least `p=none`, and it has to pass	Required; at least `p=none`
Alignment of the From domain	Required with SPF or DKIM	Required with SPF or DKIM	Required with SPF or DKIM, both preferred
One-click unsubscribe	Required on commercial and promotional mail, as `List-Unsubscribe` and `List-Unsubscribe-Post` headers per RFC 8058; requests honoured within 48 hours. Not required on transactional mail	Required on marketing and subscribed mail, RFC 8058 POST method recommended, plus a visible link in the body; requests honoured within two days	Listed as a practice Microsoft expects of large senders, a clearly visible unsubscribe option and a From or Reply-To address that can receive replies, rather than as an authentication requirement
Spam or complaint rate	Below 0.3% in Postmaster Tools, with 0.1% as the working target; above 0.3% a bulk sender is ineligible for mitigation until the rate stays below it for seven consecutive days	Below 0.3%, monitored through the Complaint Feedback Loop, which requires DKIM-signed mail to enrol	No published figure. Microsoft reserves the right to filter or block senders over hygiene problems
Forward and reverse DNS	Required of every sender: the sending IP needs a PTR record, and the hostname it names has to resolve back to that IP	Expected of all senders, together with RFC 5321 and 5322 compliance	No separate published requirement in the high-volume post
What failing looks like	Rejection or the spam folder, with an SMTP code that names the problem: `5.7.25` for a PTR mismatch, `5.7.29` for missing TLS. Gmail's FAQ says enforcement on non-compliant traffic has been ramping up since November 2025	Filtering and rate limiting rather than a published bounce string	Junk folder from 5 May 2025, and an update in the same Microsoft post says non-compliant mail is now rejected with `550 5.7.515 Access denied, sending domain [domain] does not meet the required authentication level`

Two columns in that table matter more than the rest when you are triaging a live problem. The bounce text tells you which provider is refusing you, and the alignment row tells you why, because a domain that passes SPF and DKIM on the wrong name still fails DMARC at all three.

Who counts as a bulk sender at each provider

The thresholds are per provider and per day, counted on a window nobody outside the provider can see. A campaign of 20,000 messages split across four providers can put you over the line at one of them and under it at the others, in the same hour. Gmail counts only personal Gmail accounts, so mail to a company that runs Google Workspace does not add to the count, which surprises people whose list is mostly business addresses.

Gmail's FAQ adds the detail that matters for planning: once a domain reaches the threshold it stays classified as a bulk sender. One Black Friday send is enough to put a domain in that category for good. Microsoft support material describes the same threshold by the domain in the envelope's From header, which means a subdomain you created for a single campaign is counted on its own name.

Yahoo is the honest gap in the table. Its own best practices page sets out the bulk sender requirements in full and does not attach a daily number to them on that page, so we do not quote one. In practice the question is not where the line sits: if you send the same message to a list of people who signed up for it, you are the kind of sender these rules describe.

What we set up for every client domain, whatever the volume

Because the counting is invisible and the classification is permanent, designing around a threshold is work you have to redo. We build the same baseline on every domain we touch, in this order, and it satisfies all three lists at once:

SPF with one include per sending system. One record on the organisational domain, under the 10-lookup limit, with dead includes from platforms the client stopped using removed first.
DKIM signed with the client's own domain. Not the sending platform's domain. This is the single change that fixes the most alignment failures, and it is the one most platforms let you skip.
DMARC at p=none with reports switched on, read for a few weeks before anything is tightened.
Forward and reverse DNS on any IP the client sends from directly, which usually means a self-hosted application rather than a mail platform.
TLS on outbound, which every mainstream platform does already and self-hosted senders sometimes do not.
One-click unsubscribe on anything a recipient subscribed to, with both headers emitted, covered by the DKIM signature, and an endpoint that acts on a POST rather than showing a confirmation page.
Marketing on its own subdomain, so a campaign's complaint rate cannot take the invoices down with it.

The DMARC record we start from looks like this, published as a TXT record on _dmarc.example.com:

_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com; fo=1; adkim=r; aspf=r"

That is deliberately the weakest policy. It asks every provider to send you reports and asks none of them to act yet. The ramp from there to p=reject is a separate piece of work, covered in our rollout guide, and it should not start until the reports show every legitimate sender passing.

The failures we find most often

Almost every domain that lands on our desk with a bulk-sender problem is failing one of six things, and none of them is exotic:

DKIM signed with the platform's domain. SPF passes, DKIM passes, DMARC fails, and the report looks healthy until you read the identifier columns.
SPF PermError from too many lookups. Over ten and the record stops evaluating, so SPF neither passes nor fails cleanly.
A DMARC record published on the wrong name, usually on the root domain instead of _dmarc, or on _dmarc.example.com.example.com because the DNS panel appends the zone.
Two SPF records or two DMARC records on the same name, left over from a migration. Both are invalid as a pair.
A List-Unsubscribe-Post header with an endpoint that ignores the POST. The header promises one click and the server asks for a confirmation, which fails the requirement that matters.
Forwarding. A recipient's alias relays your message, SPF breaks on the new hop, and the only thing holding alignment together is DKIM. We cover why in this post on forwarding and SPF.

How to check your domain today

Before changing a record, find out which of the eight rows above your domain actually misses. Run the domain through the checks below, then read a real message's headers from each of the three providers to confirm that SPF, DKIM and DMARC pass on your own domain name rather than on a platform's.

If you are already bouncing, the bounce text is faster than any tool. A 550 5.7.515 is Microsoft telling you the authentication level is not met. A Gmail 5.7.26 means the message was unauthenticated; a 5.7.25 means the reverse DNS does not match. Our guide to Gmail's low-reputation rejection covers the one case where the records are all correct and the domain is still refused.

What we watch in the month after

Authentication is the part you can verify in an afternoon. Reputation is the part that takes weeks, and it is what decides whether the mail lands in the inbox rather than merely being accepted. For the thirty days after a fix we watch three things with the client: the spam rate in Postmaster Tools, the pass rates per sending source in the DMARC aggregate reports, and the bounce text itself, because a provider that changes its mind says so in the SMTP response before it shows up anywhere else.

The complaint rate is the slowest signal to recover, which is the real argument for the subdomain split. A domain that has been over 0.3% at Gmail has to stay under it for seven consecutive days before it is eligible for mitigation again, and that clock does not start until the mail that caused the complaints stops.

How Guanacos Tech helps

We do this as a fixed piece of work for small and mid-sized teams across North America and Latin America: read the current records and the last month of reports, line the domain up against all three provider lists, fix what is missing in the order above, confirm it on a real message to each provider, then watch the rates with you for the month after. How we work fits on one page. If you would rather have the eight rows verified than researched, this is what email deliverability consulting for small business is for, and half an hour with your DNS panel and a recent bounce open is enough to say which provider you are failing and what it takes to clear it.

Gmail, Yahoo and Microsoft bulk sender requirements, side by side