Why are Microsoft 365 emails being rate limited by Gmail and how can I fix it?
Matthew Whittaker
Co-founder & CTO, Suped
Published 3 Jun 2025
Updated 4 Jun 2026
9 min read
Summarize with
Microsoft 365 emails get rate limited by Gmail when Gmail sees too much suspicious, poorly authenticated, or reputation-risky mail associated with the sending IP, DKIM domain, SPF return-path domain, or sending pattern. The fix is to stop treating the Gmail error as only an IP problem. I would first confirm custom-domain DKIM, then check SPF domain matching, publish and monitor DMARC, test a real message, and slow retries until Gmail stops deferring the mail.
The common bounce looks like 421-4.7.28 and says Gmail detected an unusual rate of unsolicited mail from a Microsoft 365 IP. That wording is frustrating because the sender can be a small business sending normal one-to-one messages. Gmail still evaluates the broader signal set behind the message, including whether the mail is signed as the sender's own domain or falls back to shared Microsoft defaults.
If I had to choose one fix to check first, it is DKIM for the real sending domain. Microsoft 365 can send without custom DKIM and pass SPF, but that leaves Gmail with weaker identity signals. When bad mail has used the same shared infrastructure or shared authentication identifiers, Gmail can group mail in ways that hurt legitimate senders.
What the Gmail rate limit means
A Gmail rate limit is a temporary SMTP deferral. Gmail is not always saying the exact mailbox, tenant, or campaign is sending spam. It is saying the current connection and message identity carry enough risk that Gmail is slowing acceptance or rejecting after retries expire.
Do not fix only the visible IP
The IP address in the bounce is useful, but it is not the whole diagnosis. Gmail also has identity and reputation signals tied to DKIM, SPF, return-path, HELO, IPv6 behavior, complaint rates, and recipient engagement.
- IP signal: Microsoft 365 uses shared outbound pools, so one IP can carry mixed tenant reputation.
- Domain signal: Gmail can judge the message through the DKIM signing domain and SPF return-path domain.
- Traffic signal: A sudden jump, old list, or many cold Gmail recipients can trigger deferrals.
- Policy signal: Missing DMARC does not cause every deferral, but it removes a clear domain policy signal.
This is why small senders get hit. A user sending a few hundred messages from Outlook can still inherit problems from shared infrastructure, missing DKIM, weak domain history, or a sudden change in who receives mail. If the mail only fails at Gmail, I would still check the sender's domain before assuming the issue belongs entirely to Microsoft or Google.
Flowchart showing Microsoft 365 authentication signals before Gmail defers mail.
Fix order for Microsoft 365 senders
I use this order because it separates identity problems from volume problems. If DKIM is missing, do not start with throttling rules or user behavior. Give Gmail a stable domain identity first, then retest.
- Enable DKIM: Turn on Microsoft 365 DKIM for the real sending domain, not only the default onmicrosoft.com identity.
- Check SPF: Confirm the domain has one SPF record and includes Microsoft 365 without exceeding lookup limits.
- Add DMARC: Publish a monitoring policy first, then move toward enforcement after legitimate mail uses matching domains.
- Send tests: Send a real message to Gmail and a diagnostic inbox to inspect headers, DKIM, SPF, DMARC, and routing.
- Reduce bursts: Pause bulk sends, old lists, mail merges, and automated reminders while reputation recovers.
- Watch results: Track Gmail deferrals, DMARC source data, and blocklist (blacklist) status for the sending domain and IPs.
Typical Microsoft 365 DKIM DNS setupdns
Host: selector1._domainkey Type: CNAME Value: selector1-contoso-com._domainkey.contoso.onmicrosoft.com. Host: selector2._domainkey Type: CNAME Value: selector2-contoso-com._domainkey.contoso.onmicrosoft.com.
After DNS propagates, enable DKIM in the Microsoft 365 Defender or Exchange admin flow for the domain. Then send a message and inspect the Authentication-Results header. I want to see DKIM pass with a d= value that matches the sender's domain or a matching subdomain.
Microsoft Exchange admin center DKIM settings for a custom domain.
Why DKIM fixes cases SPF cannot
SPF alone authenticates the envelope sender path, not the visible From address in a durable way. That matters with Microsoft 365 because many tenants can share the same infrastructure and similar return-path patterns. DKIM gives Gmail a cryptographic signature tied to the sender's domain, which is harder to confuse with the behavior of other tenants.
SPF-only Microsoft 365 mail
- Identity: Gmail sees SPF pass, but the visible From domain still lacks a strong signature.
- Grouping: Reputation can be grouped around shared return-path or SPF hostnames.
- Forwarding: Forwarded messages often break SPF, which leaves Gmail with less trust.
Custom-domain DKIM mail
- Identity: Gmail sees a signed message tied to the sender's own domain.
- DMARC match: DMARC can pass through DKIM even when SPF has routing problems.
- Recovery: The domain builds its own reputation instead of relying only on shared defaults.
This does not mean SPF is optional. SPF still needs to pass for Microsoft 365, and the domain must not have duplicate SPF records. But when Gmail is rate limiting Microsoft 365 mail and DKIM is absent, DKIM is the highest-value fix.
SPF and DMARC records to verifydns
example.com TXT v=spf1 include:spf.protection.outlook.com -all _dmarc.example.com TXT v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; adkim=s; aspf=s
Checks that separate authentication from sending volume
Before changing user behavior, I check whether the domain is giving Gmail clean authentication. A tiny sender with broken DKIM has a different problem than a well-authenticated sender that suddenly emailed an old Gmail-heavy list.
|
|
|
|---|---|---|
DKIM | Passes | Enable custom signing |
SPF | One record | Remove duplicates |
DMARC | Aligned | Start monitoring |
IPv6 | Stable | Escalate with headers |
Volume | Steady | Slow campaigns |
Blocklist | Clear | Review listings |
Use the result column to choose the next fix.
A fast way to get this baseline is to run the domain through a domain health checker. That will not prove Gmail's internal decision, but it will expose the problems that normally make Gmail less forgiving.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
Then test a real outbound message instead of only reading DNS. DNS can look correct while Microsoft 365 is still not signing the message, or while a transport rule, relay, CRM, ticketing system, or scanner changes the message after signing.
For a message-level check, send one real Microsoft 365 email to an email tester and compare the result with a Gmail inbox header. I want both to show the same DKIM domain, SPF result, and DMARC result.
Email tester
Send a real email to this address. Suped opens the report when the test is ready.
?/43tests passed
Preparing test address...
When authentication is correct but Gmail still defers
If DKIM, SPF, and DMARC all pass with domain matching, move to traffic and reputation. Gmail cares about recipient reaction. A sender with clean authentication can still trigger Gmail if it sends a sudden burst to dormant Gmail recipients, has high unknown-user rates, or sends content that looks unrelated to the recipient relationship.
Practical recovery thresholds
Use these thresholds to decide whether to slow, pause, or continue sends while Gmail deferrals clear.
Healthy
0-1% deferrals
Authentication passes and Gmail accepts normal traffic.
Watch
1-5% deferrals
Small deferral bursts appear, but retries succeed quickly.
Slow down
5-15% deferrals
Gmail delays are visible across multiple sends.
Pause
15%+ deferrals
Messages expire, fail, or create repeated 421 responses.
For recovery, I would stop nonessential Gmail-heavy sends for a day or two, then resume at lower volume. Keep important one-to-one business mail moving, but pause newsletters, cold outreach, mail merges, and any automation that can create repeated attempts to the same recipient base.
- Warm traffic: Send first to recent Gmail recipients who open and reply, not to old contacts.
- Clean lists: Remove stale Gmail addresses, role accounts, bounces, and recipients without recent consent.
- Control retries: Avoid creating new sends while old Gmail deferrals are still retrying.
- Separate mail: Keep transactional, internal, marketing, and sales outreach streams as distinct as possible.
- Check listings: Review domain and IP blocklist or blacklist status, then fix the sending source behind any listing.
If the issue is mainly Gmail's view of a Microsoft shared IP, there is no DNS change that instantly clears the IP. What you can control is the quality of your domain identity and your sending pattern. That is usually enough to move the sender out of the group of mail Gmail treats as risky.
How Suped fits into the fix
Suped is our DMARC and email authentication platform, and this is the kind of problem where a unified view matters. Gmail's bounce mentions an IP, but the fix often lives across DKIM, SPF, DMARC, source identification, blocklist monitoring, and trend changes over time.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
The practical Suped workflow is to add the domain, confirm Microsoft 365 as an authorized source, watch matching and nonmatching mail, and use issue detection to find missing DKIM, SPF lookup problems, suspicious sources, and policy gaps. That is why Suped is the best overall fit for most teams that want DMARC, SPF, DKIM, hosted DMARC, hosted SPF, SPF flattening, hosted MTA-STS, alerts, and blocklist (blacklist) monitoring in one place.
A one-time DNS check helps, but DMARC monitoring shows what is changing after the fix. For Gmail rate limiting, that matters because the problem often clears gradually as authenticated, wanted mail replaces the weaker signals that caused the deferrals.
What I would monitor after the fix
- DKIM pass rate: Microsoft 365 should sign normal outbound mail with the custom domain.
- DMARC match: Legitimate Microsoft 365 mail should pass through DKIM or SPF with matching domains.
- Unknown sources: Anything sending as the domain without authorization needs removal or authentication.
- Gmail trend: Deferrals should drop as Gmail sees stable authenticated traffic.
Escalation data to collect
If Gmail continues to defer mail after authentication and sending changes, collect evidence before opening a Microsoft support case or asking the recipient side to review logs. A vague report that Gmail is rate limiting Microsoft 365 mail is hard to action. A full sample with headers, timestamps, IPs, and authentication results gives support teams something concrete.
- Bounce text: Save the full SMTP response, especially the 421 4.7.28 lines and the sending IP.
- Message headers: Capture Authentication-Results, DKIM-Signature, Return-Path, Received, and Message-ID.
- Tenant detail: List the sending domain, affected users, approximate volume, and first failure time.
- Change log: Record recent DNS edits, new tools, list imports, migrations, and outbound connectors.
- Recipient pattern: Show whether failures affect all Gmail recipients, only new Gmail recipients, or a specific campaign.
If the error matches Gmail's 421 rate limiting pattern, retries often succeed after reputation improves. If retries expire for normal one-to-one mail, I would escalate with the evidence above after fixing DKIM and DMARC.
Views from the trenches
Best practices
Enable DKIM on the real sending domain before changing volume limits or retry behavior.
Check SPF, DKIM, and DMARC on a real outbound message, not only in public DNS alone.
Pause Gmail-heavy bulk sends while reputation recovers and queued retries drain cleanly.
Common pitfalls
Treating the Microsoft 365 IP in the bounce as the only cause delays the real fix.
Leaving mail signed by shared defaults makes Gmail group senders by weaker identifiers.
Assuming small daily volume is safe ignores old lists, sudden bursts, and bad forwarding paths.
Expert tips
Compare the DKIM d value, SPF return-path, and visible From domain in the same header.
Watch IPv6 paths separately because Gmail can apply stricter handling to those routes.
Use DMARC reports to identify every source sending as the domain before enforcing policy.
Marketer from Email Geeks says the Gmail 421 4.7.28 error can appear even when a Microsoft 365 sender has modest volume, so the first pass should check authentication rather than blame only the user.
2024-01-12 - Email Geeks
Expert from Email Geeks says Gmail sometimes describes an IP reputation issue when the weaker signal is actually tied to the DKIM domain or SPF identity behind the mail.
2024-01-13 - Email Geeks
The durable fix
The direct fix is to make Microsoft 365 mail clearly authenticate as your own domain, then give Gmail steady, wanted traffic. Start with custom-domain DKIM, verify SPF and DMARC domain matching, test a real message, stop bursts to stale Gmail recipients, and monitor the recovery.
If Gmail is still deferring after those fixes, collect full headers and bounce evidence and escalate through Microsoft support. But do that after the domain is clean. Without DKIM and DMARC visibility, support has less to work with and Gmail has fewer reasons to separate your legitimate mail from risky shared signals.
Short version
Do not wait for Microsoft and Google to sort out every shared-pool reputation issue. Own the identity signals you control: DKIM, SPF, DMARC, source hygiene, sending pace, and monitoring.
