Blog · Dmarc
Do Subdomains Count Toward Gmail's 5,000-a-Day Bulk Sender Threshold?
Do Subdomains Count Toward Gmail's 5,000-a-Day Bulk Sender Threshold?
No. Gmail adds up every message you send from one registered domain, subdomains included, and counts them against a single 5,000-a-day limit. Moving your marketing mail to a subdomain does not give you a fresh allowance, and the bulk sender status you pick up along the way never expires.
That last part is the one that bites. One busy campaign, one domain migration, one seasonal send at 8,000 messages, and you are a bulk sender from then on. Google says so in plain words: "Senders who meet the above criteria at least once are permanently considered bulk senders."
The short answer
Three things, and they are the three that get repeated wrong.
A subdomain does not get its own threshold. Google: "Messages sent from the same primary domain count toward the 5,000 limit."
Bulk sender status is permanent. Google: "Bulk sender status doesn't have an expiration date. Changes in email sending practices will not affect permanent bulk sender status once it's assigned."
The minimum DMARC policy is p=none, not p=reject. Gmail, Yahoo and Microsoft all say at least p=none. The idea that bulk senders must enforce p=reject is the most persistent myth in this area, and no provider requires it.
How Google counts it: one primary domain, one number
The rules apply to senders of roughly 5,000 messages or more to personal Gmail accounts in a 24-hour period. Google calls it "close to 5,000", so do not treat 4,999 as automatically safe.
Google's own worked example
From the Gmail sender guidelines FAQ:
For example, every day you send 2,500 messages from solarmora.com and 2,500 messages from promotions.solarmora.com to personal Gmail accounts. You're considered a bulk sender because all 5,000 messages were sent from the same primary domain: solarmora.com.
That is the whole question answered. A subdomain is not a separate sender for threshold purposes. It is a separate sending identity for reputation purposes. Those are different things and people constantly merge them.
So if you run:
text
outreach.example.com 2,000/day to @gmail.com
news.example.com 2,500/day to @gmail.com
mail.example.com 1,000/day to @gmail.com
------------------------
primary domain total 5,500/day -> bulk sender
Three subdomains, three sending identities, one bucket.
When a subdomain really is a separate domain
A genuinely different registered domain is a different story. example.com and example.net are not subdomains of one another, so each carries its own count. Do not treat that as a compliance escape hatch though. Each domain still carries the full obligation on its own, and you now have more DNS, more keys and more aggregate reports to manage. Splitting volume across domains changes the arithmetic, not the rules.
Bulk sender status never expires
This is the part with real operational consequences.
Google's FAQ is unambiguous. Status is permanent once assigned, it has no expiration date, and changing how you send afterwards does not reverse it. What that means in practice:
- A single campaign spike is enough to trigger it.
- Dropping back to 2,000 a day does not undo it.
- Moving to a subdomain does not undo it.
- It follows the primary domain, so a domain you have used for years is already carrying the status from the first time you crossed.
Find out today whether the domain has already crossed, before you launch a product or run a migration.
Which messages count: personal Gmail, not Google Workspace
The threshold counts mail to personal Gmail accounts. Addresses ending in @gmail.com or @googlemail.com.
It does not count mail to Google Workspace recipients. Google: "The Email sender guidelines don't apply to messages sent to Google Workspace accounts. Sender requirements and Google enforcement apply only when sending email to personal Gmail accounts."
This is bigger than it looks for B2B senders. If your list is mostly firstname@company.com on Workspace, a large part of your volume may not be counting at all. If your list is consumer-heavy, most of it is.
One caveat. Google Workspace senders have a separate policy, the "Spam and abuse policy in Gmail", which is part of the Google Workspace Acceptable Use Policy. If you send through Workspace, you are inside that one instead. You still need the authentication.
What you actually have to meet once you cross 5,000
Here is the complete list, because the requirements are spread across two Google pages and usually presented in fragments.
Requirements for all senders
These have applied to every sender to Gmail since February 1, 2024, threshold or not. If you only remember one line from this article, it is this one: SPF or DKIM plus PTR plus TLS plus a spam rate under 0.3%.
- SPF or DKIM on the sending domain
- Valid forward and reverse DNS (PTR) for the sending IP, with the forward record matching the IP
- TLS for the SMTP connection
- Spam rate below 0.3% in Postmaster Tools
- Message formatting per RFC 5322
- No Gmail
From:header impersonation
Additional requirements for bulk senders
Crossing the line adds these. Nothing here is optional once you are over the threshold, and every item has an error code attached to it further down.
- SPF and DKIM, both passing
- A DMARC record on the sending domain
- DMARC alignment: the
From:header domain must align with the authenticated SPF or DKIM domain - One-click unsubscribe on marketing and subscribed messages, plus a clearly visible unsubscribe link in the body
Two details worth knowing. DKIM keys must be 1024 bits or longer, and Google recommends 2048-bit. And one-click unsubscribe applies to marketing and promotional messages only. Transactional mail, password resets and order confirmations are excluded.
The DMARC policy minimum is p=none
Gmail's enforcement table lists this row: "DMARC record is missing (Minimum policy of none, p=none)". Yahoo's bulk sender requirements say "Publish a valid DMARC policy with at least p=none". Microsoft says "DMARC - At least p=none and align with either SPF or DKIM".
None of the three requires p=quarantine or p=reject to meet the bulk sender standard.
That does not make p=reject a bad idea. It is the only DMARC policy that actually stops someone spoofing your domain, and that is a security decision rather than a deliverability one. Keep the two separate in your head. Meeting the bulk sender bar does not require enforcement. Choosing enforcement is still worth doing, on its own merits, once your legitimate senders are aligned.
Alignment is judged against the organisational domain
This is where subdomain senders get bitten, and the rule is in RFC 7489 rather than in a provider blog.
Short version: the DMARC record at your organisational domain governs your subdomains, and Google checks your alignment against that same organisational domain. A record published only on a subdomain does not behave the way most people expect, and the sp tag does not rescue it.
DMARC alignment has two modes. In relaxed mode, the organisational domains of the DKIM signing domain and the From: domain must be equal. In strict mode, only an exact FQDN match counts. The organisational domain is derived from the public suffix list, so a.b.c.d.example.com resolves to example.com.
Now the part that catches people. RFC 7489 section 6.6.3 sets out policy discovery:
1. The receiver queries the DMARC TXT record at the From: domain.
2. If that returns nothing, the receiver queries the organisational domain instead, and "This record can contain policy to be asserted for subdomains of the Organizational Domain."
So a record published at the organisational domain covers its subdomains by default. The p tag "applies to the domain queried and to subdomains, unless subdomain policy is explicitly described using the sp tag."
And the trap in the trap: sp "will be ignored for DMARC records published on subdomains of Organizational Domains due to the effect of the DMARC policy discovery mechanism."
Put together, that means this does not do what people expect:
text
example.com IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"
mail.example.com IN TXT "v=DMARC1; p=none; sp=reject"
The sp=reject on the subdomain is ignored. It is a subdomain record, and policy discovery treats it that way. What protects mail.example.com here is the organisational domain record, not the one on the subdomain.
Google's error 4.7.32 checks alignment against the organisational domain too: "the From: header (RFC5322) in this message isn't aligned with either the authenticated SPF or DKIM organizational domain."
If you send from subdomains, check the organisational domain record first. A subdomain with no record of its own is not unprotected, it inherits. A subdomain with a record of its own can quietly mean something different than you think.
That is the part worth automating. DMARCFlow's DMARC checker at https://dmarcflow.com/dmarc-checker reads a domain's DMARC record and reports the policy in force and the alignment status, so you can run it against the organisational domain and against each sending subdomain and see which one is actually deciding the outcome. The three things you want green on every sending identity are a valid p= tag on the organisational domain, a DKIM selector aligned to it, and a rua address that receives mail.
What failure looks like: the error codes
Google publishes the codes. Nobody arranges them into a triage table, so here is one.
The codes that bounce your mail
The 4.7.x codes are temporary failures where your sending server gets rate limited. The 5.7.x codes are permanent blocks.
| Code | What it means | What to fix |
|---|---|---|
| 4.7.23 | No PTR record, or the PTR forward DNS does not match the sending IP | Fix or publish the reverse DNS for the sending IP |
| 4.7.27 | SPF did not pass | Add the sending IP or provider to your SPF record |
| 4.7.29 | Not using a TLS connection | Turn on TLS for the SMTP connection |
| 4.7.30 | DKIM did not pass | Check the selector is published and the key is 1024 bits or longer |
| 4.7.31 | No DMARC record on the sending domain, or the record has no valid policy | Publish a DMARC record with at least a valid p= tag |
| 4.7.32 | From: header not aligned with the authenticated SPF or DKIM organisational domain | Align the From: domain with your SPF or DKIM domain |
| 5.7.25 | Permanent version of 4.7.23 | Same fix, but mail is blocked rather than deferred |
| 5.7.27 | Permanent version of 4.7.27 | Same fix |
| 5.7.29 | Permanent version of 4.7.29 | Same fix |
| 5.7.30 | Permanent version of 4.7.30 | Same fix |
Google started ramping enforcement on non-compliant traffic in November 2025. Temporary codes mean your mail is deferred and retried. Permanent codes mean it is refused.
The failures that do not bounce your mail
Here is the part that costs teams the most time, because nothing visibly breaks.
Four requirement failures do not cause a rejection. They make "Delivery support or mitigations unavailable":
- Spam rate greater than 0.3%
- DMARC record missing, or without a valid policy
- Marketing and promotional messages missing one-click unsubscribe
- Unsubscribe requests not honoured within 48 hours
Your mail keeps landing. Then one morning a campaign gets misclassified, you need a mitigation request, and you find out you are ineligible because of a row in a table you never read.
The spam rate row has its own mechanics. Google calculates it daily, asks you to keep it below 0.1%, and says rates at or above 0.3% have a greater negative effect on inbox delivery. At 0.3% or above you are ineligible for mitigation. Stay below 0.3% for seven consecutive days and you become eligible again.
Outlook and Yahoo have their own rules
Neither provider copies Google, and both use the same 5,000 number for a different rule set. If you send to Outlook or Yahoo at volume, you are clearing three sets of requirements, not one.
Outlook: 5.7.515 and the Junk phase
Microsoft requires domains sending over 5,000 emails a day to Outlook to have SPF passing, DKIM passing, and DMARC at least p=none aligned with either SPF or DKIM.
The rollout was staged. From May 5, 2025 non-compliant messages were routed to Junk first, giving senders room to fix things. The rejection code when it tightened is specific and worth putting in your runbook:
text
550; 5.7.515 Access denied, sending domain [SendingDomain] does not meet the required authentication level
Two Microsoft details that differ from the usual advice. Outlook sends RUA aggregate reports but has no plans to send RUF. And Microsoft recommends separate DKIM selectors per business unit or campaign, so one sender's reputation problem does not become everyone's. That last one is also just good practice for everyone else: DMARCFlow's DKIM checker guidance is to publish a distinct selector per mail stream, use 2048-bit RSA, and avoid CNAME-published keys unless your provider forces one.
Yahoo: at least p=none, relaxed alignment, two-day unsubscribe
Yahoo's bulk sender requirements: SPF and DKIM, a DMARC policy of at least p=none that passes, a rua tag strongly recommended, one-click unsubscribe with a visible link in the body, unsubscribes honoured within two days, spam rate below 0.3%, valid forward and reverse DNS, and RFC 5321 and 5322 compliance.
Yahoo explicitly allows relaxed alignment, so a d=example.com signature aligns with a From: address at news.example.com. It also publishes the same segregation advice as everyone else: "Don't send bulk/marketing email from the same IPs you use to send user mail, transactional mail, alerts, etc."
How to check your own setup before a campaign
A short list, in the order that actually saves time.
1. Establish whether you are over the threshold at all. Count mail to @gmail.com and @googlemail.com recipients over a rolling 24-hour window, across every subdomain. If you are under, you still need SPF or DKIM and PTR and TLS, but you are not subject to the bulk sender tier.
2. Check the organisational domain DMARC record. Not the subdomain record. This is where the sp trap lives. Run the DMARC checker at https://dmarcflow.com/dmarc-checker against your organisational domain and against every sending subdomain you use. You want a valid p= tag and a rua address that actually receives.
3. Verify alignment for each sending identity. For every From: domain you send with, check that its SPF or DKIM domain shares the same organisational domain. DMARCFlow's DKIM checker and SPF checker do this for one domain at a time, and the email header analyzer reads the Authentication-Results header on a real message to show what a provider actually decided.
4. Confirm one-click unsubscribe is present on every marketing message. Not a link in the body. The List-Unsubscribe and List-Unsubscribe-Post headers, with List-Unsubscribe-Post: List-Unsubscribe=One-Click. A mailto: link does not count.
5. Watch Postmaster Tools for the right domain. Google tracks a sending subdomain as its own entry. Look up the subdomain you actually send from, not the root, or you will be reading someone else's numbers.
One more thing worth checking, because it is free and it is in Google's own guidance: "Messages of the same category should have the same From: email address." If you rotate From addresses, you split the signal about each one. Keep one address per category and let it build history.
Frequently asked questions
Do subdomains have their own 5,000-message threshold at Gmail?
No. Google counts all messages sent from the same primary domain together, including subdomains. The worked example is 2,500 messages from the root plus 2,500 from a subdomain, which is 5,000 and counts as one bulk sender.
Can a domain stop being a bulk sender once its volume drops?
No. Status is permanent once assigned and has no expiration date. Google states that changes in sending practices will not affect it. A single spike is enough to trigger it.
Does moving to a subdomain avoid the bulk sender requirements?
It avoids nothing on the threshold. A subdomain does isolate reputation, which is a real benefit, but the volume still counts against the primary domain and the requirements still apply. It also adds a policy discovery trap if your subdomain DMARC record assumes it controls its own policy.
Do I need DMARC p=reject to be a compliant bulk sender?
No. The minimum is p=none at Gmail, Yahoo and Microsoft. Gmail's enforcement table states the minimum policy explicitly as none. p=reject is worth having for the security benefit, but it is a separate decision from meeting the bulk sender standard.
Does the 5,000 threshold count mail to Google Workspace recipients?
No. The Gmail sender guidelines apply only to personal Gmail accounts. Mail to Google Workspace recipients is not counted. Workspace senders follow a separate spam and abuse policy.
What happens if my domain crosses 5,000 during a campaign or a migration?
Your mail starts being held to the bulk sender rules immediately, and the status stays with the domain. If you are missing DMARC, SPF, DKIM, TLS or PTR, you will see 4.7.x and 5.7.x codes. Check the code, fix the specific thing it names, and do not assume the volume dropping will make the problem go away.
Do Outlook and Yahoo use the same threshold and the same rules?
The same threshold, about 5,000 a day. Different rules. Outlook wants SPF and DKIM passing plus DMARC at least p=none and aligned, and uses rejection code 550; 5.7.515. Yahoo wants the same three plus one-click unsubscribe and a two-day unsubscribe honouring window, and accepts relaxed alignment.
Which Gmail error code should I look for first?
4.7.31 if you have no DMARC record on the sending domain, and 4.7.32 if you have one but the From: header is not aligned. Those two are the authentication failures that bounce mail. The rest of the requirement failures do not bounce anything, they only remove your access to mitigation.
To find out which of the two applies to you, start with the DMARC checker at https://dmarcflow.com/dmarc-checker on your organisational domain and on each sending subdomain. That tells you which record is in force, and if the answer is that your subdomain inherits the organisational domain policy, the alignment work belongs at the organisational domain.