Gmail Authentication Rate Limits: 4.7.27, 4.7.30, 4.7.32 and 4.7.29 Explained

Gmail returns 421 4.7.27, 4.7.30, 4.7.32 or 4.7.29 when it's rate limiting your mail because it failed one of the sender requirements: SPF didn't pass (4.7.27), DKIM didn't pass (4.7.30), the From domain isn't aligned with the domain that passed SPF or DKIM (4.7.32), or the connection wasn't using TLS (4.7.29). These are temporary deferrals, so your mail is being slowed rather than rejected for now. Fix the specific check the code names and they go away.

Ignore them and you're likely to graduate to the permanent 5.7.x versions, which block the mail outright.

What the bounce says

Google's documented wording for the temporary versions:

421 4.7.27 Your email has been rate limited because SPF authentication
didn't pass for this message.

421 4.7.30 Your email has been rate limited because DKIM authentication
didn't pass for this message.

421 4.7.32 Your email has been rate limited because the From: header
(RFC5322) in this message isn't aligned with either the authenticated
SPF or DKIM organizational domain.

421 4.7.29 Your email has been rate limited because you're not using
a TLS connection.

And the permanent versions:

550 5.7.27 This message was blocked because it didn't pass SPF authentication.
550 5.7.30 This message was blocked because it didn't pass DKIM authentication.
550 5.7.29 This message was blocked because it wasn't sent over a TLS connection.
5.7.32 Your email was blocked because the From: header (RFC5322) in this
message isn't aligned with either the authenticated SPF or DKIM organizational domain.

In real logs each line ends with a session ID and gsmtp, and Google may append the authentication results it saw.

What it means

Gmail's sender guidelines require every sender to use SPF or DKIM and a TLS connection. Senders of more than 5,000 messages a day to Gmail accounts must have both SPF and DKIM, a DMARC record (p=none is enough), and a From domain aligned with either the SPF or the DKIM domain.

Google's FAQ says that starting November 2025 it is "ramping up its enforcement on non-compliant traffic," with temporary and permanent rejections that come with an error code naming the requirement. These codes are that enforcement. The good news is that, unlike a reputation block such as 421 4.7.0 or 421 4.7.28, they tell you exactly which check failed.

Common causes, by code

4.7.27 (SPF didn't pass)

• The sending IP isn't in the SPF record of the Return-Path (envelope sender) domain. Typical after adding a new ESP, CRM or helpdesk without updating SPF.
• The SPF record exceeds 10 DNS lookups and returns a permerror. See SPF lookup limit.
• The Return-Path domain has no SPF record at all, or has two (which is also a permerror).
• The message was forwarded, so it arrived from an IP your SPF never listed.

4.7.30 (DKIM didn't pass)

• The message isn't DKIM signed at all.
• The DKIM public key isn't published at the selector the message uses, or was removed during a key rotation.
• Something modified the message after signing (a footer, a link rewriter, a relay), breaking the body hash. See DKIM fail.

4.7.32 (From domain not aligned)

• The most common one. SPF and DKIM both pass, but for your ESP's domain, not yours. For example, From is news@example.com, the Return-Path is bounces.esp-example.net and the DKIM signature says d=esp-example.net. Nothing aligns, so DMARC fails.
• A custom DKIM domain was set up on one sending account or subdomain but not another.

4.7.29 (no TLS)

• An older on-premises server, appliance or application relaying straight to Gmail with STARTTLS disabled or broken.

How to fix it

1. Pull a few deferred messages and note the exact code. Each code points to one check. If you see more than one, fix them in the order SPF, DKIM, alignment, since alignment depends on the first two.
2. Identify the sending source. The bounce comes from whichever system sent the message, which tells you which ESP or server to fix. Your DMARC aggregate reports show every IP sending as your domain and how each did on SPF and DKIM.
3. For 4.7.27: add the sending service to the SPF record of the domain it uses as Return-Path, using the include the service documents. Check the record with the SPF analyzer and get under 10 lookups.
4. For 4.7.30: turn on DKIM signing in the sending service, publish the key it gives you, and confirm it validates. If it signs but fails, look for anything changing the message after it leaves the signer.
5. For 4.7.32: set up a custom DKIM domain (so d= is your domain) and, if the service supports it, a custom Return-Path on your domain or a subdomain. Under relaxed alignment, which is the DMARC default, d=mail.example.com aligns with a From of example.com. One aligned method is enough.
6. For 4.7.29: enable STARTTLS on the sending server or application and make sure its certificate and TLS versions are current.
7. Make sure you have a DMARC record. Bulk senders need one. Use the DMARC generator if you don't, and start at p=none with reporting turned on.

Deferred messages will be retried by your sending server, so messages caught in the queue may still go through once the fix is live. Anything that hit a 5.7.x needs to be resent.

How to confirm it's fixed

• Send a test to a Gmail address, open it, and use "Show original." SPF, DKIM and DMARC should all say PASS, and the DKIM line should show your domain. The header analyzer will spell out alignment for you.
• Check the "Compliance status" dashboard in Google Postmaster Tools, which reports SPF, DKIM, DMARC, encryption and the other requirements as Compliant or Needs work.
• Watch the deferral logs for the next few sends. The 4.7.2x and 4.7.3x codes should stop.

How to keep it from coming back

These usually come from a new sending tool added without telling whoever owns DNS. Keep a list of every service that sends as your domain, require custom DKIM before any goes live, and read your DMARC reports so new sources show up there first.

When to get help

If authentication passes in your tests but Gmail keeps deferring with these codes, or you have more sending sources than you can track, it's worth having someone go through your DMARC data with you. Get in touch.

FAQ

Are these errors only for bulk senders?

The SPF-or-DKIM and TLS requirements apply to everyone. The requirements for both SPF and DKIM plus DMARC alignment apply to senders of more than 5,000 messages a day to Gmail accounts, so 4.7.32 in particular mostly hits bulk senders.

SPF passes for my ESP. Why am I still getting 4.7.32?

Because it passes for the ESP's domain, not yours. Alignment means the domain that passed SPF or DKIM has to match your From domain (or share its organizational domain). Set up custom DKIM with your domain.

Is this the same as 550 5.7.26?

Related, but not the same. 550 5.7.26 is a permanent rejection for unauthenticated mail. These codes target a specific failed requirement and start as rate limiting.