4.7.32

Enhanced Status Code 4.7.32: Rate Limited - From Header Not Aligned

Temporary failure High severity Authentication RFC 7489
What it means

Enhanced Status Code 4.7.32 means “Rate Limited - From Header Not Aligned.” The temporary form of an alignment failure. Google is throttling rather than blocking, which makes this the warning that arrives before 5.7.32 starts rejecting.

At a glance
Code4.7.32
Bounce typeSoft (temporary)
SeverityHigh
CategoryAuthentication
What to doQueued and retried automatically
StandardRFC 7489
What it looks like in your mail logs 
421 4.7.32 Email rate limited. The From header is not aligned with SPF or DKIM

What does 4.7.32 mean?

Google returns 4.7.32 with a 421 reply when it rate limits mail whose From header is not aligned with the domain that passed SPF or DKIM. It is the deferral form of 5.7.32 and carries exactly the same diagnosis: authentication succeeded for some domain, but not for the one your recipient sees.

The reason to document it separately is that it behaves differently in your monitoring. A rejection appears in bounce reports and gets investigated. A deferral retries, eventually delivers, and shows up as nothing worse than a slow queue. Senders routinely run for weeks in this state without noticing, then treat the eventual switch to 5.7.32 as a sudden new problem when it was signalled all along.

Alignment is fixed at the sending platform, not in DNS alone. You need a custom return-path on a subdomain you control so that SPF authenticates your domain rather than the platform bounce domain, and you need DKIM signing with your own domain and selector rather than the platform's shared key. Both are usually available and neither is usually on by default.

How 4.7.32 plays out

Your server attempts delivery
The recipient defers with a temporary 4.7.32 reply
Your server queues the message and retries on a back-off schedule
It delivers on a later attempt, or becomes a hard bounce if it keeps failing

Where 4.7.32 sits: soft vs hard bounce

Soft bounce (4xx) Hard bounce (5xx)
NatureTemporaryPermanent
SMTP class4xx5xx
What to doLet it retrySuppress the address
Recoverable?OftenNo
4.7.32 is✓ this code

What each provider means by 4.7.32

A registered code does not oblige a provider to use it that way, and the large ones diverge. Match the wording in your own bounce, not the definition above.

Gmail Email rate limited because the From header is not aligned with SPF or DKIM Reference

Common causes of 4.7.32

  • The sending platform signs DKIM with its own domain instead of yours
  • The envelope sender is the platform bounce domain, so SPF aligns to that
  • No custom return-path has been configured for the sending domain
  • DMARC is set to strict alignment while you sign with a subdomain
  • One of several sending platforms is aligned and another is not
  • A relay rewrites the envelope sender without signing on your behalf

How to fix 4.7.32

  • Configure a custom return-path on a subdomain you control so SPF aligns
  • Enable DKIM signing with your own domain and selector, not the platform default
  • Compare the spf and dkim domains in Authentication-Results against your From domain
  • Check DMARC aggregate reports, which report alignment separately from pass and fail
  • Treat throughput, not bounce rate, as the symptom while this is a deferral
  • Check aspf and adkim in your DMARC record if you sign with a subdomain

Frequently asked questions

What does 421 4.7.32 mean?
It means Google is rate limiting your mail because the From header is not aligned with the domain that passed SPF or DKIM. It is a temporary deferral, so messages retry and generally arrive, but at reduced throughput. It is the same diagnosis as 5.7.32, delivered as a warning rather than a rejection.
Why does this matter if the mail still gets delivered?
Because a deferral is invisible to any report that counts only final outcomes. Your queue drains slowly, delivery latency rises, and no bounce appears to explain it. Meanwhile the underlying alignment problem is unaddressed, and the same condition escalates to a 5.7.32 rejection when the policy tightens or the domain moves to an enforcing DMARC policy.
How do I confirm alignment is the problem?
Read the Authentication-Results header on a delivered message and look at the domain beside each result rather than just pass or fail. If spf=pass names a bounce domain belonging to your sending platform, and dkim=pass names the platform domain, neither aligns with your From header. Two passing checks and a DMARC failure is the signature of an alignment problem.
Is this fixed in DNS or at the platform?
Both, but the platform is where it starts. You enable a custom return-path and your own DKIM selector in the platform settings, and the platform then tells you which DNS records to publish. Publishing DNS records without making those platform changes achieves nothing, which is why senders often believe they have fixed alignment when they have not.
What is the difference between 4.7.32 and 4.7.30?
They name different failures. 4.7.30 means DKIM did not pass at all. 4.7.32 means DKIM or SPF did pass, but for a domain that does not match your From header. The second is harder to spot precisely because the underlying checks look healthy.

Related bounce codes

5.7.32 From Header Not Aligned with SPF or DKIM 4.7.40 Rate Limited - DMARC Record Missing or Invalid 5.7.26 DMARC Authentication Failed 4.7.30 Rate Limited - DKIM Authentication Failed 4.7.27 Rate Limited - SPF Authentication Failed

Sources & further reading

RFC 7489 · The standard that defines this reply code Gmail SMTP errors and codes · Google Workspace reference for every code Gmail returns Google email sender guidelines · The February 2024 authentication requirements for bulk senders
Reviewed by Jennifer Jackson, Email Deliverability Analyst · June 2026 ← All bounce codes