Gmail 421 4.7.27, 4.7.30, 4.7.32 and 4.7.40: Authentication Rate Limits Explained

421 4.7.27, 421 4.7.30, 421 4.7.32 and 421 4.7.40 are Gmail telling you it is slowing down mail that failed an authentication check. Each code names one check. 4.7.27 is SPF, 4.7.30 is DKIM, 4.7.32 is alignment between your From domain and the authenticated domain, and 4.7.40 is a missing DMARC record. They are temporary, so your server retries, but they will not clear until the DNS or the sending setup is fixed. Google also lists permanent 550 versions for the same failures.

Not sure which one you have? Paste the full bounce into Bounce Doctor. It reads the code and the text together.

The codes, from Google's own list

Google's Gmail SMTP errors and codes page (last updated 26 October 2026, read 2 November 2026) lists these:

Code	Google's message (shortened)	The check that failed
421 4.7.27	"Your email has been rate limited because SPF authentication didn't pass for this message."	SPF
550 5.7.27	"This message was blocked because it didn't pass SPF authentication."	SPF, permanent
421 4.7.30	"Your email has been rate limited because DKIM authentication didn't pass for this message."	DKIM
550 5.7.30	"This message was blocked because it didn't pass DKIM authentication."	DKIM, permanent
421 4.7.32	"...rate limited because the From: header (RFC5322) in this message isn't aligned..."	DMARC alignment
421 5.7.32	"Your email was blocked because the From: header (RFC5322) in this message isn't aligned..."	Alignment, blocked
421 4.7.40	"...rate limited because the sending domain doesn't have a DMARC record..."	DMARC record exists
550 5.7.40	"Your message was blocked because the sending domain doesn't have a DMARC record..."	DMARC record, permanent

These are separate from 550 5.7.26, which covers mail that is unauthenticated altogether, fails an SPF -all record or fails a DMARC p=reject policy. That code has its own guide: Gmail 550 5.7.26.

Why Gmail sends them

Google's email sender guidelines (read 2 November 2026) set two tiers. All senders must set up SPF or DKIM. Bulk senders, defined as more than 5,000 messages a day to personal Gmail accounts, must set up SPF, DKIM and DMARC, and the domain in the From header must align with the SPF or DKIM domain. The DMARC policy can be p=none.

The rate-limit codes are the enforcement. When a message misses one of the requirements, Gmail accepts less of your mail and says which requirement is missing. That is useful, because it tells you exactly where to look. Our Gmail and Yahoo bulk sender requirements guide covers the full list.

The four checks in plain English

SPF (4.7.27)

SPF is checked against the envelope sender, the Return-Path address your sending server uses for bounces, not the From address people see. Gmail looks up the SPF record of that domain and checks whether the sending IP is listed. It fails when:

• The IP is not in the record. A new sending tool was added and nobody updated SPF.
• The record has more than 10 DNS lookups, which makes it a permanent error. The SPF lookup counter shows your count.
• There are two SPF records on the same domain. Only one is allowed. The SPF record merger combines them.
• The record has a syntax error or the include points at a domain that no longer exists.

DKIM (4.7.30)

DKIM is a signature added by the sending server and checked against a public key in DNS at selector._domainkey.yourdomain. It fails when:

• The key in DNS does not match the private key the server signs with, usually after a key rotation or a copy-paste error.
• The DNS record was never published, or was published on the wrong host name.
• Something changed the message after signing. Footers added by a gateway or a list server are a common cause.

The DKIM checker looks up a selector and tells you whether the key is valid. If you don't know the selector, the DKIM selector finder tries the common ones, and the DKIM signature validator checks a real message.

Alignment (4.7.32)

Alignment is the one that catches people out, because SPF and DKIM can both pass and Gmail still complains. DMARC requires the domain that passed to match the domain in your From header. With relaxed alignment, a subdomain counts as a match, so bounce.example.com aligns with example.com. A different domain does not.

A message from you@example.com that passes SPF for mail.sendingtool.net and DKIM for sendingtool.net passes both checks and still fails alignment. Our DMARC alignment checker shows which domain each check used.

DMARC record (4.7.40)

This one is simple. Gmail looked up _dmarc.yourdomain and found nothing. Publish a record. The smallest valid one is:

v=DMARC1; p=none; rua=mailto:dmarc@example.com

The DMARC generator builds one, and the DMARC checker confirms it is live. Note that the record must be on the From domain (or its parent), not on the domain your sending tool uses.

The cold email setups that cause them

Setup	What usually goes wrong	Code
Google Workspace inboxes connected to a sequencer	DKIM never turned on in the Workspace admin console, so mail goes out with no DKIM for your domain	4.7.30 or 4.7.32
Microsoft 365 inboxes connected to a sequencer	DKIM not enabled for the custom domain, so Microsoft signs with its own onmicrosoft.com domain	4.7.32
A sending platform with its own bounce domain	SPF passes for the platform, not you; DKIM is the platform's default	4.7.32
A new domain bought for outreach	DMARC record skipped during setup	4.7.40
Several tools on one domain	Two SPF records, or one record over 10 lookups	4.7.27
Mail forwarded by a third party	SPF breaks on forwarding; only DKIM survives	4.7.27

The fix for the first three is the same idea: make the tool sign DKIM with your domain, and where it allows a custom bounce domain, use a subdomain of yours. Our guides to Google Workspace DKIM and Microsoft 365 DKIM walk through both consoles, and cold email domain setup covers a new domain from scratch.

Fix plan

1. Read the bounce and fix only what is named

Each code names one check. Don't rebuild your whole DNS for a 4.7.40 when the only missing piece is a DMARC record.

2. Send one test to a Gmail address

Send a normal message from the same tool, same inbox and same domain to a personal Gmail account you control. In Gmail, open it and choose Show original. The summary at the top shows SPF, DKIM and DMARC as PASS or FAIL, and the domain each one used.

3. Read the Authentication-Results header

The header shows exactly what Gmail saw. For example:

spf=pass smtp.mailfrom=bounces.sendingtool.net
dkim=pass header.d=sendingtool.net
dmarc=fail header.from=example.com

Here both checks pass but neither domain is example.com, which is a 4.7.32 waiting to happen. The email header analyzer lays this out for you.

4. Check every sending source on the domain

If a CRM, a newsletter tool and a sequencer all send as example.com, each one needs to pass. A DMARC aggregate report lists every source that sent as your domain and whether it passed. The DMARC report analyzer turns the XML into a readable table.

5. Wait for DNS, then resume slowly

DNS changes can take time to spread, so check with the DNS propagation checker. Once the test message shows all three passing and aligned, resume at a lower volume and build back up. Deferred messages already in your server's queue will retry on their own. Don't resend them by hand.

How they relate to other Gmail codes

Code	Meaning	Guide
421 4.7.26 / 550 5.7.26	Unauthenticated, SPF hard fail or DMARC reject	Gmail 550 5.7.26
421 4.7.28	Unusual rate of (unsolicited) email	Gmail 421 4.7.28
421 4.7.0 / 550 5.7.1	Very low reputation	Gmail low reputation
550 5.7.25	No PTR record for the sending IP	Reverse DNS and PTR

The whole set is in our Gmail bounce codes reference.

Check the domain before the next send

The bulk sender checker runs Google's and Yahoo's requirements against a domain in one pass: SPF, DKIM, DMARC, PTR and one-click unsubscribe. The deliverability audit does a wider check. Both are free and need no account.

Where SimpleVerifier fits

These codes are about authentication, so verification won't clear them. What it does is keep the other half of your sending record clean. SimpleVerifier runs a live mailbox check on each address and returns safe to send, send with care, check again later or do not send, with the reason, so that once your domain passes, the mail goes to addresses a server confirmed. Catch-alls stay risky, never guessed valid.

The first 100 checks are free with a Google sign-in on the verify page. Pro is $39 a month with the first 100,000 checks a month at full speed, then slower, never cut off. See pricing.