How to troubleshoot Gmail 4.7.28 throttling during sender warm-up (DKIM, SPF, and IP quota limits)

When Gmail returns 421 4.7.28, the useful question is not just "why was this message deferred?" but which sending identity did Gmail decide was moving too fast?

That distinction matters because Google can rate limit this error at more than one layer during warm-up:

• the sending IP address
• the SPF domain
• the DKIM signing domain
• sometimes the wider IP netblock
• sometimes a repeated Message-ID pattern or a URL domain in the message

So 4.7.28 is not the same kind of signal as 4.7.27 or 4.7.30.

Those codes say SPF or DKIM did not pass. 4.7.28 says Gmail is seeing an unusual rate of mail and is temporarily slowing or blocking it.

Google documents that warm-up limits are tracked per domain and IP address, and specifically notes that DKIM and SPF quotas are domain-specific while the IP quota is shared by every sender using that IP. Source: Google's Email sender guidelines.

What Gmail is actually telling you with 4.7.28

Google's SMTP error reference lists several 4.7.28 variants, including unusual mail rate from:

• your IP address
• your IP netblock
• your DKIM domain
• your SPF domain
• one of your URL domains
• repeated use of the same Message-ID

That is why generic advice like "just slow down a bit" is usually incomplete.

You need to identify which quota bucket you hit before deciding whether the fix is:

• lower volume from one domain
• lower volume from one IP
• separate traffic streams
• fix a shared-infrastructure problem
• stop reusing broken message templates or identifiers

If you treat every 4.7.28 like a pure IP reputation problem, you can waste days changing the wrong thing.

First, separate 4.7.28 from Gmail's auth-specific deferrals

Do this before changing warm-up pace.

If Gmail is returning:

• 4.7.27, fix SPF first
• 4.7.30, fix DKIM first
• 4.7.32, fix DMARC alignment first
• 4.7.40 or 4.7.31, publish or fix DMARC first

Those are not normal warm-up throttles. They are direct authentication compliance failures.

If you need that mapping in one place, keep Gmail bulk sender error codes explained nearby while troubleshooting.

4.7.28 is different because Gmail can return it even when SPF, DKIM, DMARC, PTR, and TLS are all technically correct.

Google's immediate recovery procedure is very specific

This is one of the more useful parts of Google's sender guidance, and it is often skipped.

When you hit quota and Gmail starts returning 4.7.28, Google says to:

1. Stop sending for at least 10 minutes.
2. Identify the cause.
3. If the error message does not specify whether you exceeded DKIM, SPF, or IP quota, assume all three are affected.
4. After 10 minutes, retry from a single SMTP connection.
5. If the single connection fails, wait another 10 minutes.
6. If it succeeds, increase the number of connections one at a time.

If your platform keeps blasting across many parallel connections during the recovery window, you are working against the guidance Gmail publishes for senders.

The three warm-up buckets that matter most

In practice, most sender warm-up 4.7.28 cases fall into one of these three buckets.

1. IP quota throttling

This is the version most teams think of first.

It usually looks like one of these situations:

• a new dedicated IP ramped too fast
• a shared ESP pool had another sender create trouble
• transactional and marketing traffic were mixed on the same IP and one stream destabilized the other
• connection count increased too quickly even when total daily volume seemed reasonable

Google's guidance is unusually explicit here: the IP address quota is shared for all senders that use that IP address. When the IP quota is hit, all domains using that IP stop sending mail through it until the rate is reduced. Source: Google's Email sender guidelines.

That one sentence explains a lot of confusing incidents.

If two domains share one IP and only one of them ramps aggressively, the other one can still feel the pain.

2. DKIM domain quota throttling

This catches teams that sign multiple streams with the same DKIM domain and assume separate IPs will isolate them.

Sometimes they will not.

Google says DKIM quotas are specific to your domain. So if several campaigns, business units, or providers all sign with the same d= identity, Gmail can still decide that domain-level behavior is too aggressive.

That is especially relevant during migrations and warm-up overlap periods where teams temporarily send the same visible brand from two platforms at once.

Check whether all of these share one signing identity:

• your normal campaign traffic
• a migration batch
• test traffic
• triggered mail from another platform

If yes, the domain may be warming faster than you think.

3. SPF domain quota throttling

This one is easy to miss because many teams think of SPF only as a pass/fail authentication mechanism.

But Google's sender guidance says SPF quotas are also domain-specific.

So if many streams reuse the same envelope-from namespace, such as bounce.example.com, Gmail may treat the aggregate volume on that SPF identity as the real pacing signal.

That can surprise teams that split visible From: addresses but leave the bounce domain architecture unchanged.

How to identify which quota bucket you hit

Start with the exact SMTP reply text, not just the code.

Google's SMTP reference includes variants that often tell you the quota surface directly:

• "originating from your IP address"
• "originating from your DKIM domain"
• "originating from your SPF domain"
• "originating from your IP Netblock"
• "containing one of your URL domains"
• "exceeded the quota for sending messages that have the same Message-ID"

That wording determines your next move.

If the reply names the IP address

Focus on:

• daily and hourly volume on that IP
• connection count and burstiness
• whether other streams or tenants share the IP
• recent changes in traffic mix, content, or recipient quality

Also review Shared IP vs dedicated IP for authenticated senders, because many teams think they own an IP reputation story that is actually shared.

If the reply names the DKIM domain

Focus on:

• which senders sign with the same d= value
• whether a new platform joined the same signing domain
• whether warm-up traffic and steady-state traffic were combined under one DKIM identity

Look at real delivered headers, not vendor setup screens. The DKIM-Signature header tells you the truth about the active d= domain.

If the reply names the SPF domain

Focus on:

• the real envelope-from domain in Return-Path
• whether multiple providers reuse the same bounce domain
• whether a recent change accidentally concentrated traffic into one SPF identity

If that part is fuzzy, Return-Path vs From: practical implications is the quickest refresher.

If the reply does not say which quota was hit

Follow Google's own advice and assume DKIM, SPF, and IP are all affected until proven otherwise.

That means the safe immediate action is not to keep half the traffic running on the theory that only one layer is limited.

Warm-up mistakes that trigger 4.7.28 even with clean authentication

The common pattern is not "missing DNS record."

It is one of these:

1. Volume doubled too quickly from one day to the next.
2. A sender started many parallel SMTP connections at once.
3. Promotional traffic was mixed with cleaner transactional traffic.
4. A new platform was added but reused the same DKIM or SPF identity.
5. A shared IP pool experienced trouble from another tenant.
6. Old or weak recipients created complaint and engagement signals that made the ramp look risky.

Google's sender guidance explicitly recommends consistent sending rate, gradual increases, starting with engaged users, and avoiding sudden spikes or major infrastructure changes without warming the modified segment separately.

That is the operational heart of this issue. 4.7.28 is often Gmail saying, "this sender behavior changed faster than trust developed."

A practical troubleshooting sequence

When 4.7.28 starts appearing during warm-up, this order usually gets to the cause fastest:

1. Save the full SMTP response text, including whether it names IP, DKIM domain, SPF domain, netblock, URL domain, or repeated Message-ID.
2. Pause sending for 10 minutes.
3. Confirm this is really 4.7.28, not 4.7.27, 4.7.30, 4.7.32, or 4.7.40.
4. Send a low-volume retry from a single connection only.
5. Review one fresh delivered sample and confirm SPF, DKIM, DMARC, PTR, and TLS are all clean.
6. Map the active identities from the message itself:
   • visible From: domain
   • envelope-from / Return-Path domain
   • DKIM d= domain
   • sending IP
7. Check what other traffic shares those same identities.
8. Reduce the warm-up curve for the affected identity, not necessarily for every unrelated stream.
9. Reintroduce concurrency one connection at a time.
10. Monitor Postmaster Tools for reputation and spam-rate deterioration while volume comes back.

What to change when the IP is the bottleneck

If the evidence points to IP quota pressure:

• cut parallel connections sharply
• flatten bursty send windows
• separate transactional from marketing traffic if they are sharing reputation
• ask the provider whether the IP is shared and whether other tenants are contributing to the throttle
• keep the next ramp step smaller than the previous one that failed

Do not respond by rotating rapidly across many fresh IPs. That often looks worse, not better.

What to change when the DKIM or SPF domain is the bottleneck

If Gmail is throttling a domain quota, the fix is often about identity design, not only raw speed.

For example:

• keep one stream on news.example.com and another on notify.example.com
• give separate platforms separate aligned sender identities where appropriate
• avoid piling migration traffic onto the same DKIM or bounce-domain namespace used by existing production mail

The principle is simple: if Gmail is counting volume by domain identity, stop making unrelated streams look like one sender.

This fits the broader warm-up advice in DMARC and sender domain warm-up: how to increase volume safely without triggering blocks.

Watch for the hidden shared-infrastructure trap

One of the hardest 4.7.28 incidents to diagnose is this:

• your domain is authenticated correctly
• your list is not terrible
• your ramp is conservative
• but the IP quota is still getting hit

That can happen when the real problem is upstream of you:

• a shared ESP IP
• a neighboring sender on the same netblock
• provider-side traffic concentration on the same route

If the throttle text points to IP or IP netblock, and your own ramp looks reasonable, this should move near the top of the suspect list.

Postmaster Tools helps, but read it with the SMTP reply

Google Postmaster Tools compliance dashboard is useful here, especially for watching domain reputation, spam rate, and bulk-sender compliance.

But Postmaster Tools does not replace the SMTP reply text.

4.7.28 is one of those cases where the rejection wording often contains more tactical direction than the dashboard alone.

Use both together:

• SMTP reply for the affected quota surface
• Postmaster Tools for trend direction and reputation context
• live headers for actual SPF, DKIM, and alignment identities

The recovery goal is controlled predictability

The goal is not to discover the maximum rate Gmail will barely tolerate.

The goal is to make the sender look stable again.

That usually means:

• fewer connections
• smaller ramp steps
• cleaner audience selection
• clearer separation of streams
• fewer sudden infrastructure or header changes

Bottom line

Gmail 4.7.28 during sender warm-up is not one single quota problem.

It can be an IP quota issue, a DKIM-domain quota issue, an SPF-domain quota issue, or a broader unsolicited-volume signal tied to your infrastructure or message pattern. Google's own guidance gives the most important response pattern: pause for 10 minutes, assume all three quota surfaces are affected if the reply is ambiguous, retry from one connection, and scale back up slowly.

Once that is paired with accurate identity mapping from Return-Path, DKIM d=, and sending IP, the fix becomes much more concrete and much less guessy.