Message blocked: a server refused the message you sent from Gmail

Gmail puts the heading Message blocked above any refusal from a mail server, whatever the cause. The SMTP reply under the heading says what the cause is, and several causes on this page have no DNS fix. A 5.7.26 means your authentication failed, and a 5.7.1 is about your sending. An admin rule at the recipient gets the same heading. Read that reply before you edit a record.

Did the recipient block you? Usually not. When a Gmail user blocks a sender, Google moves that sender's mail to Spam and returns no bounce.

1. Check how the reply line ends: gsmtp, gcdp or neither.
2. Read the enhanced status code on that line, such as 5.7.26.
3. Fix the cause that code gives, in DNS, at your sending platform, or through the recipient's admin.
4. Wait for the old TTL to expire, then send one message to a mailbox you control at gmail.com.

What the bounce says

You sent the message from Gmail or Google Workspace, so Gmail wrote the notice, and it uses this heading for every refusal. 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 how to read a Mail Delivery Subsystem notice has its own page.

The line under the heading comes from either Google's mail servers or the recipient's. If Google's servers wrote it, you deal with Google. If the recipient's server wrote it, you deal with the recipient's admin. Google doesn't document which of its components writes the notice, but relaying explains the split. Google's servers refuse the message when the recipient is on Gmail or Workspace. They also refuse it when Google won't carry the message at all, as with a blocked attachment type. For any other recipient, Gmail hands the message on, and the refusal comes from the recipient's mail system.

The gsmtp and gcdp tags

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. Here's Google's own example of a gcdp error:

Check how your line ends before you change anything:

• - 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 can't remove it by changing your 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 says why it refused you. Do what that text says.

Who fixes each code

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.

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 looks like a mistake in the documentation, so go by the sentence in your bounce. A bad address isn't in this table. Google returns 550 5.1.1 for that, and Gmail heads the notice "Address not found".

Authentication codes

For the authentication codes, you fix your DNS records, the platform that sent the message, or 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. Past that, RFC 7208 says a checker returns permerror, so a sender that the checker needs an eleventh lookup to find fails SPF. Our SPF checker resolves every include and counts them for you, and the DMARC checker reads the policy back as receivers see it.

Codes 5.7.27 and 5.7.30 are each about a single check. 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 shows whether that key resolves. If the message has no such header, the platform never started signing. Turn signing on in the sending application, because publishing a record won't turn it on.

Code 5.7.32 is about alignment. A check passed for a domain that does not match the address your recipient sees in the From: line. People hit this mismatch after publishing SPF, DKIM and DMARC correctly. The DMARC alignment guide has the platform settings that fix it.

Google pairs 5.7.26 with a second sentence too:

That one comes from your own DMARC policy. Google applied it and refused a message that put your domain in the visible From: address without an aligned pass behind it. The 550-5.7.26 page covers both versions 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

Google's table lists 20 different sentences for 5.7.1. These are the ones about your content or your reputation:

These lines can come back even when SPF, DKIM and DMARC all pass. Google checks authentication on each message, and it builds a reputation from your whole sending history. Correct records don't repair a bad reputation.

For the content case, Google's page on fixing bounced or rejected email suggests these changes:

• 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 page has 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 could send 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 leaves out 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 mentions 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

A rule at the recipient is the cause when the error is tagged gcdp, or when it carries 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's why some of these rejections sound like a person wrote them. Once you're on the list, every message from you bounces at the edge. Only that administrator can take you off.

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 delays

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 has the fix for each version of it. Google pairs 4.7.32 with the alignment sentence from 5.7.32, so a 4.7.x line can still mean you need to align the From: header. Resending the same batch into a rate limit extends the limit.

When to resend

Fix the cause the line gave. Wait for the old TTL on any record you edited to expire, then send one message to a mailbox you control at gmail.com. Resolvers keep serving the old record until that TTL runs out. If it arrives, you fixed the block you were hitting. If a second Message blocked notice comes back, compare its status code to the first one. If the code changed, you cleared one cause and hit another. If it stayed the same, the fix hasn't taken effect yet.

Other senders

One delivered message proves one sending path. Most domains have several, such as the CRM or the ticketing system that mails on your behalf. Any one of them can produce the next bounce, in the week its volume rises. Your Sent folder won't show them, so read your aggregate reports. 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 is already at Cloudflare. 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.

We built DomainCanary to catch the next failure. You've proved one sender works today, and nobody will tell you when the next system appears on your domain and fails DMARC. On a paid plan, we mail you the day its first failing report arrives, without waiting for the next Monday digest. We send at most one alert a day per domain. The Starter plan is $19 a month for 3 domains. On the Business plan, all your domains arrive in a single weekly email with a section each. Your first domain is free, and the alert on the next failing sender comes with the paid plan. Aggregate reports total messages by sending IP and don't include bounce notices, so we can't see the Gmail notice you have open today.