Gmail rejection codes: what 550 5.7.26 and its cousins mean, and how to fix them

Why Gmail rejects more mail than it used to

Since 1 February 2024, Google has required everyone who sends to personal Gmail accounts to authenticate with SPF or DKIM, have valid forward and reverse DNS for the sending IP, use TLS, follow the message format standard (RFC 5322) and keep the reported spam rate below 0.3%. Bulk senders have more to do: SPF and DKIM, a DMARC record (p=none is enough), a From: domain aligned with SPF or DKIM, and one-click unsubscribe for marketing mail. Google counts you as a bulk sender once you have sent close to 5,000 messages in 24 hours to personal Gmail accounts, and all mail from the same primary domain counts, subdomains included. Once you are a bulk sender, you stay one.

For a while, mail that broke these rules mostly went to spam. Google's sender FAQ says that starting November 2025, Gmail is ramping up enforcement on non-compliant traffic, with temporary and permanent rejections. Google gives no exact day, and the ramp is gradual, so a domain that was fine last month can start getting bounces this month.

The rules apply to mail sent to personal Gmail accounts (gmail.com and googlemail.com). They don't govern mail sent to Google Workspace accounts. That doesn't let Microsoft 365 or Workspace senders off: if your company sends to personal Gmail addresses, the rules apply to you.

How to read the bounce

A Gmail bounce has two numbers before the text. The first is the three-digit SMTP reply code: 421 and 451 mean "try again later", 550 means "no". The second is the enhanced status code, such as 5.7.26. A code starting with 4 is temporary: Gmail rate-limits the message and your server retries. A code starting with 5 is permanent: the message is gone and the sender gets a bounce.

The temporary codes deserve as much attention as the permanent ones. A 4.7.x code is Gmail telling you what will become a 5.7.x code if nothing changes. Most authentication codes come in pairs, one temporary and one permanent, with the same cause and the same fix.

The bounce text usually names the domain and the sending IP that failed. Copy both. They are the fastest way to the culprit.

550 5.7.26: three different messages, three causes

5.7.26 is the code people search for most, and it hides three different problems. Read the text after the code to know which one you have.

The first says the sender is unauthenticated: neither SPF nor DKIM passed. This is the baseline rule for every sender, bulk or not. The service that sent the message isn't listed in your SPF record and doesn't sign with DKIM for your domain. The fix is to authorise that service: switch on DKIM signing with your own domain in the service's settings (it gives you one or more DNS records to publish), and add its SPF include if it sends with your domain as the envelope sender. The temporary version is 4.7.26 with the same wording about authentication.

The second says the MAIL FROM domain has an SPF record with a hard fail (-all), and the sending IP isn't in it. Here Gmail is simply obeying your own record. Either the IP belongs to a service you use and you forgot to add it, or something is sending with your envelope domain that shouldn't. Check the IP in the bounce against your SPF record. If the service is legitimate, add it. Loosening -all to ~all hides the symptom; adding the sender fixes it.

The third says the mail isn't accepted because of the domain's DMARC policy. This one is different: the message failed DMARC, and the domain owner has asked receivers to reject such mail. If that domain is yours and the mail was genuine, you have a legitimate sender that isn't aligned (see the alignment section below). If the mail wasn't yours, DMARC is doing exactly its job: someone tried to send as your domain and Gmail turned them away. There is a temporary twin here too: 4.7.26 saying the DMARC policy applies but a temporary DNS failure prevented authentication. That points at your DNS: check that your name servers answer reliably and, if you use DNSSEC, that the signatures are valid.

5.7.27 and 4.7.27: SPF didn't pass

These codes say the message failed SPF and that Gmail requires bulk senders to authenticate with SPF. The causes are the usual SPF ones. A new service isn't in the record. The record has more than 10 DNS lookups, so the whole check fails with an error even when the sender is listed. There are two SPF records on the same domain, which is invalid. Or the service sends with its own envelope domain and your record never gets checked at all.

Run your domain through the free SPF Surveyor at monitordmarc.eu/tools/spf-surveyor. It draws the include tree and counts the lookups, so you can see at once whether a service is missing or the record has grown past the limit. If you are over 10, remove includes for services you no longer use first, before reaching for flattening.

5.7.30 and 4.7.30: DKIM didn't pass

These say the message failed DKIM. Either the service doesn't sign at all, it signs with a key whose public half isn't published in your DNS, or the published key doesn't match after a rotation. Google requires DKIM keys of at least 1024 bits and recommends 2048.

Find the selector in the DKIM-Signature header of a test message (the s= value) and look it up with the free DKIM Inspector at monitordmarc.eu/tools/dkim-inspector. If nothing is published at that selector, the service's DNS records were never added, or were added at the wrong name. If you use Microsoft 365, DKIM for your own domain has to be switched on in the Defender portal and needs two CNAME records (selector1 and selector2); until then, mail from your custom domain isn't signed with your domain.

4.7.32 and 5.7.32: From: not aligned

These say the From: address isn't aligned with the domain that passed SPF or DKIM. Alignment is the heart of DMARC. It isn't enough that SPF passed for some domain; it has to pass for the domain in the From: line your recipients see, or for its parent organisational domain.

The classic case: your newsletter tool sends from news@yourshop.dk, SPF passes for the tool's own bounce domain, and DKIM is signed with the tool's domain. Everything passes, nothing aligns. The fix is the tool's "custom domain" or "domain authentication" setting, which makes it sign DKIM with your domain and, ideally, use a return-path on your domain too. Aligned DKIM is the more robust of the two, because it survives forwarding and SPF doesn't. Google currently requires one aligned method for bulk senders, recommends both, and says both will likely be required eventually.

Google's table lists 5.7.32 with a 421 reply code rather than 550. Treat it as the same problem as 4.7.32 and fix it the same way.

4.7.31: no DMARC record

This code appears in Google's sender FAQ: it means the sending domain has no DMARC record, or no policy in it. For bulk senders, a DMARC record is required, and a monitoring policy of p=none is enough to meet the rule.

A minimal record is a TXT record at _dmarc.yourdomain with v=DMARC1; p=none; and a rua address where receivers send their reports. The free DMARC Wizard at monitordmarc.eu/tools/dmarc-wizard builds one for you, and the DMARC Inspector at monitordmarc.eu/tools/dmarc-inspector checks what you have published, tag by tag. Don't stop at p=none forever, but don't rush past it either: the reports it brings in are how you find the senders you forgot.

The codes that aren't about authentication

4.7.23 and 5.7.25 mean the sending IP has no PTR (reverse DNS) record, or the PTR name doesn't point back to the same IP. This is set by whoever owns the IP: your hosting company, ISP or mail provider. If you run your own mail server, ask them to set it; if you use a big provider, it is almost never the cause.

4.7.29 and 5.7.29 mean the message wasn't sent over TLS. Modern providers do this by default. It mostly hits old servers, printers and scanners that send mail directly, and self-hosted scripts.

4.7.24 and 5.7.24 say the SPF record has "one or more suspicious entries". Google doesn't define what counts as suspicious. It pays to check the record for syntax errors, mechanisms nobody can explain, and very broad IP ranges, and to remove anything that isn't needed.

4.7.28 and 5.7.28 are about speed: Gmail has seen an unusual rate of mail from your IP. Google's advice for 4.7.28 is specific: stop sending for at least 10 minutes, resume on a single connection, and add connections one at a time. Google also warns against sudden spikes, noting that even doubling your volume can trigger rate limits. Worth knowing before Black Friday: ramp campaign volume up over days, not in one send.

How to find the sender that is failing

Start with the bounce. It names the IP and usually the domain. Look up who owns the IP (a reverse DNS lookup or WHOIS will usually name the provider), and you often have your answer in a minute: your invoicing system, the webshop platform, a CRM, a helpdesk tool, a scanner in the office.

If the bounces come back to someone else, ask them for the full text, or send a test from the suspect system to a personal Gmail address. In Gmail, "Show original" on the message shows whether SPF, DKIM and DMARC passed, and the Authentication-Results header shows the domain each one was checked against. That tells you not just what failed but which domain it failed for, which is what you need to fix alignment.

For the full picture, use your DMARC aggregate reports. Large mailbox providers, Gmail included, usually send one a day to the rua address in your DMARC record, listing every IP that sent mail as your domain and whether it passed. A sender you forgot shows up there days before its first bounce reaches you. The free XML-to-Human tool at monitordmarc.eu/tools/xml-to-human turns a report file into a readable table with the names of the sending sources.

A short fix order before the busy season

First, make sure every service that sends as your domain is known: mail platform, newsletter tool, webshop, invoicing, CRM, helpdesk. Second, turn on DKIM with your own domain in each of them. Third, check that SPF lists the ones that use your envelope domain and stays under 10 lookups. Fourth, publish a DMARC record with a rua address if you don't have one, starting at p=none. Fifth, read the reports for a couple of weeks and fix what shows up, then move towards quarantine and reject. Finally, keep an eye on Google Postmaster Tools, which shows your domain's spam rate and has a compliance status dashboard for the sender requirements.

The hard part isn't the first fix. It's noticing when something changes: a colleague adds a new tool, a provider rotates a key, someone edits the SPF record and pushes it to 11 lookups. MonitorBase re-checks your domains every day and alerts you when SPF, DKIM or DMARC changes or starts failing, and reads your DMARC reports for you, from €16/month ex. VAT on the Basic plan. It is run from Denmark, with all data stored and processed in Paris and no US sub-processors.

Check your domain now

Run the free domain health check at monitordmarc.eu. It checks SPF, DKIM, DMARC, MX, blacklists and more in one go, and tells you what to fix. No account, no e-mail address.

Sources

Google, Email sender guidelines FAQ, support.google.com/mail/answer/14229414 (accessed 20 October 2026): enforcement ramp starting November 2025, bulk sender definition, scope, alignment, the 4.7.31 code and the Postmaster Tools compliance dashboard.

Google, Gmail SMTP errors and codes, support.google.com/mail/answer/3726730 (accessed 20 October 2026): the wording of every code in this guide, including the three 5.7.26 variants and the 421 reply code listed with 5.7.32.

Google, Email sender guidelines, support.google.com/mail/answer/81126 (accessed 20 October 2026): requirements for all senders since 1 February 2024, bulk sender requirements, DKIM key length and the advice on rate limits.

Microsoft Learn, Set up DKIM to sign mail from your Microsoft 365 domain, learn.microsoft.com/en-us/defender-office-365/email-authentication-dkim-configure (updated 3 July 2026, accessed 20 October 2026).

Free tools that help

• SPF Surveyor: Visualize the full SPF include tree and count DNS lookups against the limit of 10.
• DKIM Inspector: Find published DKIM keys across common selectors and analyze key strength.