Why Exim Logs Gmail 421 Rate Limit Deferrals for cPanel Domains

You check the Exim mail queue on your cPanel server and find dozens or hundreds of outbound emails addressed to @gmail.com sitting frozen or marked as retry-pending. When you inspect the failure message, Exim does not show a permanent rejection like a 550 mailbox unavailable error. Instead, it logs an SMTP 421 temporary deferral mentioning that Gmail has restricted traffic from your server IP or domain due to unusual sending rates or missing authentication. A 421 status code is a temporary failure, not a permanent bounce. It tells your Mail Transfer Agent (MTA)—in this case, Exim—that Google's incoming MX servers are currently unwilling to accept the connection or transaction, but Exim should hold the message in its local queue and retry delivery later according to its retry rules. When administrators see these deferrals, the first instinct is often to assume the server IP landed on a public anti-spam blacklist. In reality, modern Gmail 421 deferrals are almost always triggered by automated bulk sender protection systems reacting to incomplete authentication records or sudden surges in message volume.

Checking the Exim Log for the Exact Error String

The first step is to pull the exact error message that Google returned during the SMTP transaction. Looking only at the queue count in WHM Mail Queue Manager shows that emails are backed up, but it obscures the actual SMTP conversation. Log in to your server via SSH as root and run exigrep or a read-only grep against /var/log/exim_mainlog targeting the recipient domain or a specific deferred message ID:

BASH

grep -E 'gmail-smtp-in.l.google.com.*421' /var/log/exim_mainlog | tail -n 10

When Google defers your outbound email, the logged response typically includes an extended status code like 421 4.7.0 or 421 4.7.28. A representative log line looks like this illustrative example:

TEXT

2026-03-29 10:14:22 1tABCd-000123-XY H=gmail-smtp-in.l.google.com [142.250.153.26]: SMTP error from remote mail server after end of data: 421-4.7.28 [203.0.113.10] Our system has detected an unusual rate of unsolicited mail originating from your IP address. To protect our users from spam, mail sent from your IP address has been temporarily rate limited.

Notice the phrase temporarily rate limited. Google does not drop the message on the floor; it intentionally returns a 4xx error. This instructs Exim to keep the email on disk and slow down. However, if your cPanel server attempts to deliver hundreds of messages per hour across multiple hosted accounts while this rate limit is active, Exim's queue builds up exponentially. If you want to understand how queue stalls occur even when blacklists show zero flags, read Why Outbound Emails Queue Up When Your IP Is Not Blacklisted.

Why Google Enforces Bulk Sender Throttling

Google maintains strict authentication requirements for anyone sending email to personal Gmail accounts (@gmail.com and @googlemail.com). While these standards apply across the internet, Google enforces non-negotiable thresholds for anyone sending close to 5,000 or more messages per day. On a shared cPanel server hosting dozens or hundreds of accounts, reaching 5,000 daily messages sent to Gmail addresses across all hosted domains is common. Under these rules, three core requirements dictate whether Gmail accepts your mail smoothly or begins deferring it: First, sender authentication via SPF (Sender Policy Framework) and DKIM (DomainKeys Identified Mail) must be valid and verifiable. For bulk senders, relying on only one of the two is no longer acceptable; both must be present, and your domain must also publish a DMARC (Domain-based Message Authentication, Reporting, and Conformance) policy record. If an account sends transactional emails or marketing blasts without these records, Google's filters treat the traffic as suspicious. Second, the sending domain must maintain alignment. DMARC alignment requires that the domain visible in the user-facing From: header matches the domain authenticated by SPF (the envelope sender domain) or the domain signing the email via DKIM (d=domain.com). When web scripts like WordPress send email using generic PHP mail wrappers, the envelope sender often defaults to [email protected], breaking alignment with the From: [email protected] header. Third, spam complaint thresholds must remain exceptionally low. If recipients mark your messages as spam at a rate exceeding Google's acceptable baseline (typically targeted below 0.10% and never consistently exceeding 0.30%), automated rate limits trigger immediately. The result is the exact 421 deferral error recorded in your Exim logs.

Inspecting DNS Records for the Deferred Domain

Once you identify which domain is generating the deferred messages, check its public DNS records immediately. In many hosting setups, cPanel acts as the primary mail server, but the domain's DNS is managed externally at Cloudflare, registrar nameservers, or an external cloud DNS provider. If a user migrates to your cPanel server but forgets to copy over DKIM and SPF records, outbound mail leaves the server unauthenticated. Run these checks directly from the server terminal:

Check the SPF record for the sender domain: Look for a TXT record starting with v=spf1. Ensure it includes the public IP address of your cPanel server (for example, +ip4:203.0.113.10) or includes your mail host record. If there is no SPF record, or if multiple SPF records exist, receiving servers will fail SPF evaluation.
Check the DKIM public key record: cPanel typically stores DKIM keys under the selector default._domainkey.yourdomain.com. Verify that a TXT record exists for that selector and contains a valid p= public key block. If cPanel generates a DKIM signature in the email headers but the public DNS zone lacks the matching key, Gmail treats the signature as invalid.
Check the DMARC policy record: Query _dmarc.yourdomain.com for a TXT record. At minimum, a domain should publish an initial monitoring record: v=DMARC1; p=none; sp=none;. Without this base record, domains sending higher volumes fail Google's bulk sender validation.

If the domain lacks proper alignment or signatures, you can follow the detailed step-by-step setup in our guide on Arsitektur Email Deliverability 2026: Konfigurasi SPF, DKIM, dan DMARC pada Exim cPanel.

Fixing Authentication Within cPanel and WHM

If the domain's DNS is hosted locally on the cPanel server, fixing missing authentication records is straightforward. In cPanel, direct the user to Email Deliverability under the Email section. The interface scans the domain's zone file and identifies missing or invalid SPF and DKIM records. Clicking Repair or Install Suggested Records automatically writes the correct DKIM TXT record and an SPF entry containing the local server IP. If the domain uses external nameservers (such as Cloudflare), the user cannot simply click repair in cPanel. Instead, they must copy the raw values generated in cPanel's Email Deliverability page and paste them as TXT records into their external DNS manager:

The DKIM record name must be default._domainkey (or the specific selector shown in cPanel), and the type must be TXT.
The SPF record must be created at the root (@) as a TXT record, containing the valid v=spf1 ... ~all syntax.
The DMARC record must be created at _dmarc as a TXT record with at least v=DMARC1; p=none;.

After adding these records, verify that Exim is signing outbound messages with the newly generated DKIM key. In WHM, ensure that DKIM is enabled globally for new accounts under Tweak Settings -> Mail.

Clearing the Deferred Queue Safely

After fixing the underlying authentication issues or stopping an unauthorized spam script that triggered the rate limit, the deferred messages will still sit in the Exim queue. Exim retries them automatically based on the default retry configuration in /etc/exim.conf, but users may become impatient if urgent emails are delayed. Do not force-flush the entire Exim queue at once if you have hundreds of queued messages for Gmail. Attempting to blast 500 queued messages immediately to gmail-smtp-in.l.google.com will re-trigger the exact same 421 rate limit, extending Google's temporary ban for several more hours. Instead, let Exim's native retry schedule handle the queue gradually, or retry messages in small, deliberate batches. Once Google detects that newly connecting connections carry verified SPF, valid DKIM signatures, and legitimate DMARC alignment, the 421 deferrals will decrease and normal queue delivery will resume automatically. Understanding that a 421 error is an automated throttle—not a permanent ban—keeps your troubleshooting focused where it matters: verifying DNS records, checking message alignment, and ensuring that outbound volume from shared accounts meets modern recipient standards.