Why does Gmail bounce my email with 550 5.7.27 or 421 4.7.27?
Gmail slowed down or blocked the message because SPF did not pass for it. Gmail asks large senders for SPF even when DKIM passes. The owner of the envelope sender's domain fixes it, usually by adding the sending server or service to the SPF record, or by mending a record that has errors.
The bounce
Google's list of Gmail SMTP errors gives two texts. Under 550 5.7.27:
This message was blocked because it didn't pass SPF authentication. Gmail requires bulk email senders to authenticate their email with SPF.
Authentication results: SPF with ip-address = did not pass
Under 421 4.7.27, the temporary form:
Your email has been rate limited because SPF authentication didn't pass for this message. Gmail requires all bulk email senders to authenticate their email with SPF.
Authentication results: SPF domain-name with IP address: ip-address = Did not pass.
The address in the bounce is the server that sent the message. In the 421 text, domain-name is the domain SPF checked.
What Gmail checked
Gmail's sender guidelines ask senders who send more than 5,000 messages per day to Gmail accounts to "Set up SPF and DKIM email authentication for your domain." Both, not one of the two. A message that passes DKIM still needs SPF.
SPF checks the domain of the envelope sender, the bounce domain, not the From address. Gmail looked up that domain's SPF record and asked whether the sending address is on it. "Did not pass" covers three cases:
- The server is not on the list. A new service, a changed provider or a server of your own sends mail that the record does not name.
- The record has an error. Two SPF records on one domain, a typing error, or an include that points nowhere make SPF return an error for every message.
- The record makes too many lookups. An SPF check may make at most 10 lookups in DNS. Past that, SPF returns an error. Each include costs at least one, so the count grows with every service you add.
Who has to fix it
The owner of the domain SPF checked.
- It is your domain. The mail uses a bounce address of yours, from your own server or a service set up with a custom bounce domain. Add the server or the service's include to your SPF record.
- It is the service's own domain. The service's bounce domain failed its own SPF check. That is the service's to fix. Tell its support the address from the bounce.
The records
A domain has one SPF record that lists every server and service that sends with it:
example.com TXT v=spf1 include:_spf.google.com include:_spf.newsletter.example -all
Add a new service's include to this record, rather than publishing a second one. If the record already makes many lookups, remove the services you no longer use first. Fix your SPF record shows how, and SPF has too many DNS lookups covers the limit. In Mailmoni, the DNS tab checks the record itself: it shows any error in it and how many lookups it makes.
What it looks like in your DMARC reports
In the aggregate reports for your domain, the source behind this bounce shows up as a row like this:
<row>
<source_ip>192.0.2.10</source_ip>
<count>40</count>
<policy_evaluated>
<disposition>none</disposition>
<dkim>pass</dkim>
<spf>fail</spf>
</policy_evaluated>
</row>
<identifiers>
<header_from>example.com</header_from>
</identifiers>
<auth_results>
<dkim>
<domain>example.com</domain>
<selector>s1</selector>
<result>pass</result>
</dkim>
<spf>
<domain>example.com</domain>
<result>fail</result>
</spf>
</auth_results>
DKIM passes and aligns, so DMARC passes, but SPF fails. A broken record shows permerror or temperror in place of fail under auth_results. The spf under policy_evaluated is "The result of the SPF DMARC Identifier Alignment test" (RFC 9990, section 3.1.1.9). For mail you send to Gmail directly, a failing SPF means the server or service is missing from the SPF record, or the record is broken.
In Mailmoni, a source like this passes DMARC, and its explanation says that SPF fails, which happens when mail is forwarded or when the service is missing from your SPF record.