Gmail bulk sender error codes explained: 4.7.27, 4.7.30, 4.7.31, 4.7.32 and 5.7.x fixes

If Gmail starts replying with 4.7.27, 4.7.30, 4.7.31, 4.7.32, or the matching 5.7.x variants, the useful part is this: Gmail is usually being very specific.

These are not vague “deliverability seems bad” signals. They usually point to one missing piece in the authentication chain: SPF, DKIM, DMARC, or DMARC alignment.

And yes, the 4.x.x vs 5.x.x distinction matters. In SMTP, a 4xx response is a temporary deferral or rate limit, while a 5xx response is a hard block. So if Gmail returns 4.7.27, traffic is being throttled because SPF is not acceptable yet. If it returns 5.7.27, Gmail is done waiting.

Google’s current guidance sits across its Email sender guidelines, the newer Email sender guidelines FAQ, and the live Gmail SMTP errors and codes reference. Those pages are worth checking directly because Google updates them.

The short mapping

Here is the practical interpretation:

• 4.7.27 / 5.7.27: SPF did not pass
• 4.7.30 / 5.7.30: DKIM did not pass
• 4.7.31 or 4.7.40 / 5.7.40: DMARC record missing, or DMARC record has no usable policy
• 4.7.32 / 5.7.32: From: domain is not aligned with authenticated SPF or DKIM domain
• 5.7.26: broader unauthenticated-sender block; often shows up when neither SPF nor DKIM gives Gmail what it needs

That 4.7.31 vs 4.7.40 detail trips people up. Google’s FAQ still references 4.7.31 for missing DMARC policy, while the current SMTP error list shows 4.7.40 and 5.7.40. Operationally, treat them as the same class of problem: Gmail is telling you the domain needs a real DMARC record.

What Gmail expects from bulk senders now

For senders delivering 5,000 or more messages a day to personal Gmail accounts, Google requires:

• SPF
• DKIM
• a DMARC record with at least p=none
• alignment of the visible From: domain with either SPF or DKIM
• TLS, sane DNS, and low spam rates

That alignment requirement is the part many teams underestimate. A message can have SPF=pass and DKIM=pass somewhere, and still fail the Gmail bulk-sender requirement if neither authenticated domain lines up with the From: header domain under DMARC rules. Google spells that out in its FAQ section on DMARC alignment.

If that needs a refresher, DMARC identifier alignment deep dive covers the mechanics in plain English.

4.7.27 and 5.7.27: SPF did not pass

Google’s wording here is direct: the message did not pass SPF authentication.

That does not always mean “no SPF record exists.” In practice, it can mean any of these:

• no SPF TXT record at the envelope-from domain
• the sending IP is not authorized by the SPF record
• multiple SPF TXT records caused SPF permerror
• the record exceeded SPF’s DNS lookup budget
• the wrong bounce domain is being used by the sender

SPF is defined in RFC 7208, and Gmail still evaluates it in the normal SMTP sense: against the 5321.MailFrom domain, not the visible From: header domain.

So this can happen:

From: billing@example.com
Return-Path: bounce@mailer.example.net
Authentication-Results: mx.google.com;
  spf=pass smtp.mailfrom=mailer.example.net;
  dkim=none;
  dmarc=fail header.from=example.com

SPF passed, but not for a domain aligned with example.com. Gmail may still complain later with 4.7.32 or 5.7.32 because DMARC alignment is the real requirement for bulk-sender mail.

Exact fixes for SPF errors

1. Publish exactly one SPF TXT record for the sending domain.
2. Make sure the SMTP envelope sender domain used by your platform is actually covered.
3. Add all legitimate outbound systems to SPF.
4. If SPF is returning permerror, simplify the record before doing anything else.
5. Retest with a real message and inspect Authentication-Results.

Example SPF record structure:

example.com. IN TXT "v=spf1 ip4:192.0.2.10 include:_spf.example.net -all"

If SPF complexity is the real culprit, SPF 10 DNS lookup limit explained is the post to keep open during cleanup.

4.7.30 and 5.7.30: DKIM did not pass

This one usually means Gmail saw a DKIM signature but could not validate it, or expected DKIM and effectively got no usable pass.

DKIM is defined in RFC 6376. In production, DKIM failures usually come from a short list:

• the selector DNS record is missing
• the public key is malformed in DNS
• the sender is signing with the wrong domain
• a gateway or downstream system modifies the message after signing
• the domain has DKIM configured in one platform but mail is really leaving through another

Example of what Gmail wants to be able to see:

DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=s1; ...
Authentication-Results: mx.google.com;
  dkim=pass header.d=example.com

Exact fixes for DKIM errors

1. Confirm the sending platform is signing every relevant mail stream.
2. Check that the selector in s= exists in DNS at selector._domainkey.example.com.
3. Verify the signing domain in d= is the domain you intend to align.
4. Make sure no relay, filter, or footer-injector rewrites the message body after signing.
5. Rotate away from broken or stale selectors rather than trying to rescue a half-migrated setup.

If Google Workspace is part of the path, Your Google Workspace DKIM setup may be broken is still a useful reality check.

4.7.31 / 4.7.40 and 5.7.40: DMARC record missing or incomplete

This is the easiest class of Gmail bulk-sender error to understand. Gmail is saying the domain in the visible From: header needs a DMARC record, and that record needs to specify a policy.

DMARC is defined in RFC 7489. For Gmail bulk-sender compliance, p=none is enough to meet the minimum DMARC publication requirement, as Google states in its sender guidelines.

Example minimum DMARC record:

_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"

Two common mistakes:

• publishing the record at example.com instead of _dmarc.example.com
• publishing v=DMARC1 without a usable p= value

Exact fixes for DMARC publication errors

1. Publish a TXT record at _dmarc.example.com.
2. Include v=DMARC1; p=none at minimum.
3. Add rua= so DMARC aggregate reporting starts immediately.
4. Wait for DNS propagation, then send a fresh test message.

If the domain has multiple services sending mail, do not jump straight to enforcement blindly. Start with monitoring, read the aggregate reports, then tighten later.

4.7.32 and 5.7.32: DMARC alignment failed

This is the one that causes the most confusion, because admins often say: “But SPF passed” or “But DKIM passed.”

Gmail is not asking whether some SPF or DKIM result passed somewhere. It is asking whether the domain in the visible From: header aligns with either:

• the SPF-authenticated 5321.MailFrom domain, or
• the DKIM signing domain in d=

DMARC passes if at least one of those is both passing and aligned, which is exactly how RFC 7489 section 4.1 describes it.

Example failing pattern:

From: alerts@example.com
Return-Path: bounce@mailer.example.net
DKIM-Signature: d=mailer.example.net; s=outbound1; ...
Authentication-Results: mx.google.com;
  spf=pass smtp.mailfrom=mailer.example.net;
  dkim=pass header.d=mailer.example.net;
  dmarc=fail header.from=example.com

Authentication passed. Alignment failed. Gmail still has a problem with it.

Exact fixes for alignment errors

1. Change the envelope-from domain so SPF authenticates an aligned domain, such as bounce@example.com or bounce.mail.example.com.
2. Or change DKIM signing so d=example.com or an aligned subdomain signs the mail.
3. Avoid mixing one provider’s bounce domain with another provider’s visible From: domain unless alignment has been designed intentionally.
4. Re-test with live headers, not just vendor dashboard screenshots.

For hands-on debugging, DMARC troubleshooting with real headers is the fastest way to see what Gmail is objecting to.

Where 5.7.x fits in

Google’s SMTP reference includes a wider set of 5.7.x blocks. Some are authentication-specific (5.7.27, 5.7.30, 5.7.32, 5.7.40), and some are broader trust or policy failures such as 5.7.26.

The useful rule is simple:

• if the code mentions SPF, fix SPF first
• if it mentions DKIM, fix DKIM first
• if it mentions DMARC record or policy, publish or correct DMARC
• if it mentions alignment, inspect From:, Return-Path, and DKIM d= together

Do not collapse all 5.7.x errors into “reputation issue.” Gmail does use reputation heavily, of course, but the authentication-related ones are often very concrete and very fixable.

A practical troubleshooting sequence

When Gmail starts returning these errors, this order usually saves time:

1. Read the full SMTP reply and keep the exact code.
2. Send one fresh test message to a Gmail mailbox.
3. Open the message headers and inspect Authentication-Results.
4. Confirm SPF pass/fail for the real envelope-from domain.
5. Confirm DKIM pass/fail for the actual signing domain.
6. Compare both against the visible From: domain.
7. Verify the domain publishes a DMARC record with a policy.

That sounds basic, but it avoids the classic trap of editing the website domain DNS while the actual mail is being sent by a different domain or provider path.

Bottom line

Gmail bulk-sender authentication errors are usually not mysterious. They are a map.

4.7.27 points to SPF. 4.7.30 points to DKIM. 4.7.31 or 4.7.40 points to DMARC publication. 4.7.32 points to alignment. And the 5.7.x versions mean Gmail has moved from warning to blocking.

Once those signals are read in the right order, the fixes are usually straightforward: publish DMARC, make SPF valid, make DKIM verify, and align at least one of them with the visible From: domain.