Bounce and error codes

Message blocked: what Gmail is telling you, and what to change

Last updated 2026-08-21

Gmail prints Message blocked above the refusal a mail server returned. It uses that heading for a missing DKIM key and for a filter that scored the message as spam. An administrator at the recipient's organization can trigger the same heading with one rule. Read the line in the technical details before you edit a record, because several of the causes on this page are not yours to fix in DNS.

Message blocked is a wrapper, not a reason

You sent the message from Gmail or Google Workspace, so Gmail wrote the notice. Google publishes no wording for the heading itself. The copies people paste into Google's own help forum open like this, with your recipient's address in place of the example:

Some copies drop the address and read "Your message has been blocked". Google's help pages document the sender name and the subject line of that notice. Treat the heading as variable. Skip it and read the refusal underneath. The notice arrives from Mail Delivery Subsystem <mailer-daemon@googlemail.com>, and the anatomy of that notice is its own page.

Two different mail systems write the line under that wrapper. The system that wrote yours decides whether you talk to Google or to the recipient's admin. Google does not document which of its components composes the notice, and the split follows from relaying. Google's servers refuse the message when the recipient sits on Gmail or Workspace. They also refuse it when Google will not carry the message at all, as it does with a blocked attachment type. For any other recipient, Gmail hands the message on, and the refusal belongs to the recipient's mail system.

gsmtp means Google, gcdp means an admin

Google adds gsmtp to every error its own servers return. It adds gcdp to an error that came from a custom rule a Google Workspace administrator created. Google's own example of the second one:

Read the end of your line before you touch anything else:

• - gsmtp and nothing else: Google refused the message, so the rest of this page applies.
• - gcdp: an administrator at the recipient's organization wrote the rule that refused you. You cannot lift it from your own DNS. Ask your contact there to send the block to their Workspace admin.
• Neither tag: Google attaches these tags to its own errors only, so an untagged line almost always came from the recipient's mail server. Its text names the reason. Follow that server's instructions.

Match the code to the owner of the fix

The 3-part number is the enhanced status code, and Google's Gmail SMTP errors and codes lists the text it pairs with each one. These 10 are the codes this page walks through.

Status code	What it means	Who fixes it
5.7.26	The sender is unauthenticated, or the domain's DMARC policy refused it.	You, in DNS and at the sending platform
5.7.27	The message did not pass SPF authentication.	You, in your SPF record
5.7.30	The message did not pass DKIM authentication.	You, at the sending platform
5.7.32	The From: header is not aligned with the SPF or DKIM organizational domain.	You, by aligning the sender
4.7.32	The same alignment failure, rate limited instead of blocked.	You, by aligning the sender
5.7.40	The sending domain has no DMARC record, or no policy in it.	You, in DNS
5.7.25	The sending IP has no PTR record, or the forward entry does not match.	Whoever runs the sending IP
5.7.29	The message was not sent over a TLS connection.	Whoever runs the sending server
5.7.1	Likely unsolicited, low reputation, rate limited, or a policy prohibits the mail.	You, or the recipient's admin
5.7.0	The content presents a potential security issue.	You, by removing the attachment or content

Google lists 5.7.32 against SMTP code 421 while its own text says the message was blocked. That reads like a slip in the documentation. Trust the sentence in your bounce over the number in the doc. A bad address is not on this list. Google answers that one with 550 5.1.1, and Gmail heads the notice "Address not found".

Authentication codes: fix DNS, then send again

Five of those codes send you to your DNS records, to the platform that sent the message, or to both. Google publishes this wording for 5.7.26:

Both checks failed for the domain in the brackets. Read the records your domain publishes today:

The first must return one string that starts v=spf1. That record has to cover the IP printed in the bounce. The second must return one string that starts v=DMARC1. SPF allows 10 terms that cause a DNS lookup. RFC 7208 tells a checker to return permerror past that, so a record needing an eleventh authorises nothing. Our SPF checker resolves every include and counts them for you. The DMARC checker reads the policy back as receivers see it.

Codes 5.7.27 and 5.7.30 each name a single check instead. For the DKIM one, take the s= and d= values from the DKIM-Signature: header of a message the same system sent. Our DKIM checker tells you whether that key resolves. A message carrying no such header tells you the platform never started signing. Turn signing on in the sending application, because no record you publish does it for you.

Code 5.7.32 names alignment. A check passed for a domain that does not match the address your recipient sees in the From: line. That mismatch is the failure people hit after publishing all three records correctly. The alignment guide covers the platform settings that close it.

Google pairs 5.7.26 with a second sentence too:

That one is your own policy at work. It refused a message that put your domain in the visible From: address without an aligned pass behind it. The 550-5.7.26 page separates the two variants in detail. 550 5.7.1 rejected per DMARC policy covers the same failure at other receivers.

Code 5.7.40 means Google found no DMARC record on the sending domain. Publishing your first record is a one-line TXT change, and a policy of p=none does not affect delivery.

5.7.1 for spam: no DNS record clears it

Google's table lists 20 different sentences against 5.7.1. Three of them tell you whether Gmail judged your content or your reputation:

Your three records can all pass, but these lines still come back. Google checks authentication on the message in front of it, and it builds a reputation from your whole sending history. Correct records do not buy you out of a bad one.

Google's page on fixing bounced or rejected email lists three changes for the content case. Drop links and text that ask the reader for personal information. Put a large recipient list into a Google Group and mail the group address instead. If you forward mail into Gmail, filter spam before it leaves you. Google warns that a spam report on a message your domain forwarded makes your later messages more likely to be marked as spam.

A 5.7.1 line can also be your own sending limit. Google lists 550 5.7.1 This email has been rate limited. for that case, and Gmail phrases the notice as "You have reached a limit for sending mail". Google's Gmail sending limits carry the current numbers. When I last checked, a Workspace user could send 2,000 messages a day to 3,000 external addresses. Any one message could reach 500 external recipients. A personal Gmail account hit the wall at 500 emails in a day. Google resets the limit within 24 hours, and it recommends a Google Group in place of a long recipient list.

For the reputation case, Google's free Postmaster Tools is the only place Google publishes a reputation for your domain. Add the domain you authenticate with, verify it with a DNS record, and read the spam rate and reputation dashboards. Postmaster Tools hides a day whose message count falls below Google's display threshold, so a small sender sees empty charts.

Google's sender guidelines carry the current thresholds. As of mid-2026 they ask every sender to keep the spam rate reported in Postmaster Tools below 0.3%. Google tells senders above 5,000 messages a day to Gmail accounts to stay below 0.10% and never to reach 0.3%. Their marketing mail also has to carry one-click unsubscribe.

If the refusal came from a server other than Google's and names a blocklist, open the URL in that line first. Spamhaus runs a free lookup for an IP or a domain, and its listing pages carry the removal steps.

Recipient rules: only their admin lifts these

Two lines name a rule as the cause. One is any error tagged gcdp. The other is Google's policy wording:

A Google Workspace administrator can add addresses and whole domains to a blocked senders list. They can also edit the notice those senders get back. That is why some of these rejections read like a sentence a person wrote. Every message from you then bounces at the edge. Only that administrator can lift it.

Reach your contact by phone or at another address. Ask them to check the blocked senders setting in their Admin console, and send them the whole bounce so they can search for their own rejection text.

A single Gmail user can block you too. Google returns no bounce for that, and it routes your later mail to their Spam folder.

4.7.x means your server retries

A reply that starts with 4 is transient in SMTP. RFC 5321 defines a 4yz reply as a temporary error condition, where the action may be requested again. Your sending server queues the message and tries again later, and Gmail mails a delay notice while it does. Gmail's temporary block for volume is 421 4.7.28. The 421 4.7.28 page names the fix for each variant of it. Google pairs 4.7.32 with the alignment sentence from 5.7.32, so a 4.7.x line can still be asking you to align the From: header. Resending the same batch into a rate limit extends the limit.

Retry with one message

Fix the cause the line named. Wait for the old TTL on any record you edited to expire, then send one message to a mailbox you control at gmail.com. That TTL decides when resolvers see your edit. If it lands, you fixed the block you were hitting. If a second Message blocked notice comes back, compare its status code to the first one. A code that changed means you cleared one cause and hit another. A code that stayed the same means the fix has not taken yet.

Find the senders you have not tested

One delivered message proves one sending path. Most domains have several: the CRM, the payroll app a contractor connected two years ago, the ticketing system that mails on your behalf. Any one of them can produce the next bounce, in the week its volume rises. You find them from aggregate reports rather than from your Sent folder. Every receiver that participates counts the messages it saw from each IP using your domain. The report says whether those messages aligned.

Cloudflare's DMARC Management charts those reports for free if your DNS already lives at Cloudflare. Use it. Postmark's DMARC Digests mail a summary once a week, and when I last checked the free tier reported 10 sending sources and 7 days of history.

DomainCanary is our product, so this paragraph is a pitch and you should read it as one. You proved one sender works today, and the next system to appear on your domain and fail DMARC will not write to tell you. Our paid plans mail you the day its first failing report lands, instead of holding that news for the next Monday digest, and one domain sends at most one alert a day. Pro covers 10 domains for $19 a month, and all of them arrive in a single weekly email with a section each. Your first domain is free, and the alert on the next failing sender arrives with the paid plan. Aggregate reports total messages by sending IP and carry no bounce notices, so we cannot see the Gmail notice you have open today.