Gmail 421 4.7.28 for an unusual rate from your DKIM domain: what to change first

Read the entire diagnostic, not only 4.7.28

Google publishes several 4.7.28 variants. Some identify unusual mail from an IP address or netblock; others name the DKIM domain, SPF domain, a URL domain, or repeated use of the same Message-ID. Those are different clues. If your logger collapses every response into a generic “rate limited” status, you lose the most valuable part of the incident. Store the full enhanced status code and text exactly as returned, together with timestamp, recipient provider, mailbox, domain, and queue job that produced it.

Stop the volume change while you still have a baseline

Because 421 is a temporary SMTP response, the queue may automatically retry. That is normal transport behavior, but an outbound system should not simultaneously keep feeding new campaign messages at the same pace. Freeze new volume increases and inspect planned versus actual sends. A double-run worker, retry storm, or batch-size bug can create an abrupt domain-level pattern even when each mailbox cap looks reasonable. The first containment step is to stop making the signal larger while you determine whether the cause is traffic shape, bad targeting, authentication, or another named identity in the error.

Check the identity Gmail named

If the response says the DKIM domain is producing an unusual rate, inspect messages signed with that d= value across all mailboxes and applications. Multiple internal mailboxes can share one DKIM domain, so mailbox-level dashboards may hide the total Gmail sees. If the diagnostic names SPF instead, group by the Return-Path identity. If it names a URL domain, review the common links being sent. The error text is telling you which aggregation surface triggered the policy; use that to define the scope of the incident.

Compare rate, volume and list quality separately

A high daily total and a sudden sending rate are different patterns. A sender can stay under an internal daily cap yet still burst many messages in a few minutes after a queue pause. Separately, a poor list can produce invalid-recipient and complaint signals even at modest volume. Build a timeline with sends per five or fifteen minutes, total sends per domain, hard bounces, temporary deferrals, and replies. This prevents a simplistic response such as lowering the daily cap when the real bug is a bursty worker—or changing cadence when the list source is deteriorating.

Let temporary deferrals retry with backoff

Do not convert a 421 into a hard bounce or immediately suppress the recipient. SMTP 4xx responses indicate a temporary failure class. Your mail transport should retry later according to a controlled backoff policy. The outbound application, however, should avoid creating duplicate logical sends while the MTA is already retrying. Track one message attempt through its queue identity so a temporary Gmail deferral does not cause the campaign layer to enqueue another copy with a new Message-ID.

Use a small verified probe before resuming

After the suspected cause is fixed and the system has cooled down, resume with a deliberately small batch of verified recipients. Keep every other variable stable. If the previous incident followed a jump from 18 to 60 sends, do not resume at 60 simply because several hours passed. Return to a level that previously behaved normally, watch the SMTP responses, and increase only when the receiver stops showing the same diagnostic. Recovery is about establishing a new clean baseline, not racing back to the old target.

Check Postmaster only as supporting evidence

If Google Postmaster Tools has enough data for the domain, review spam rate, authentication, and delivery errors around the incident. A small sender may see blank or delayed charts, so do not wait for Postmaster before containing a live 4.7.28 event. The SMTP response is already direct evidence from Gmail. Postmaster can help show whether the incident sits inside a broader reputation pattern, but it should not replace queue logs, actual headers, and the exact error variant.

Prevent recurrence in the scheduler

Add a health gate that blocks daily-cap increases when provider deferrals rise above baseline. Also cap burst size independently from daily volume, make queue retries idempotent, and record domain-wide totals across all mailboxes. A new mailbox should not silently double the DKIM-domain output because each worker thinks only about its own limit. The operational objective is predictable traffic and fast detection of deviation, not a universal Gmail-safe number.

Separate identity-specific throttling from generic IP panic

Gmail publishes several 421 4.7.28 diagnostics that can name different dimensions, including unusual rates associated with an IP, netblock, DKIM domain, SPF domain, URL domain, or repeated Message-ID behavior. If the diagnostic names the DKIM domain, do not immediately rotate IPs or blame every mailbox. Compare the affected signing domain with other traffic using the same infrastructure. A stable IP can carry mail for multiple domains, and a rate problem scoped to one authenticated identity needs a different investigation from a network-wide block.

Build a 24-hour timeline around the first deferral. Plot successful accepts and 4xx responses in small intervals, mark any new mailbox, list import, scheduler change, or provider migration, and preserve the full SMTP text. Freeze campaign growth while the queue uses bounded backoff; otherwise retries plus new traffic can increase the pressure that produced the deferral. When conditions settle, send a small verified cohort through the same authenticated path and watch whether acceptance normalizes before restoring the previous schedule. If Postmaster Tools has enough data, compare its delivery-error and authentication views, but do not let a delayed aggregate dashboard override the direct SMTP responses your sending system is receiving now.

Field checklist

• Preserve the complete 421 4.7.28 text and the identity it names.
• Freeze new campaign volume while transport retries existing messages.
• Compare planned sends with actual sends and burst rate.
• Group traffic by the DKIM/SPF/URL identity named by Gmail.
• Resume from a known-good level with a small verified batch.
• Add burst and provider-deferral gates to the scheduler.