Message not delivered: the recipient's server refused your message

Gmail puts Message not delivered at the top of nearly every bounce it writes, and the heading says nothing about the cause. The reason sits lower down, after The response from the remote server was:, as a code the other server sent back. Find that line first, because every fix on this page starts from it.

Is the message lost? Yes, for that recipient. Nothing arrived, and Gmail won't retry a permanent refusal. Fix the cause and send it again.

Where the reply is

Open the notice. Under the heading, Gmail writes a sentence of its own, usually that your message couldn't be delivered because the remote server is misconfigured. Ignore it. Gmail writes that for every refusal and it's rarely the actual cause. Scroll to the block that starts like this:

That reply came from the recipient's server, and Gmail quotes it. The first three digits are the class. A 5 means refused for good. A 4 means try later. The dotted number after it says what kind of thing went wrong, and the text after that usually says it in words.

On a phone, tap the three dots on the notice and choose Show original if the block is folded away. The raw notice has the same reply under Diagnostic-Code.

Fixes, by reply

Each of these has its own page with the exact strings and the full fix.

• 550-5.7.26, unauthenticated, or SPF or DKIM did not pass. The recipient uses Gmail, and Gmail found no SPF pass and no DKIM pass for the domain in your From address. You fix it in your DNS, and it's the case the rest of this page covers. 550-5.7.26 has both wordings.
• 550 5.7.1 with the word DMARC. Your domain publishes a DMARC policy of reject, and this message failed it. Same fix as above, and the policy is doing what you told it to. Rejected per DMARC policy.
• 550 5.1.1, does not exist, or user unknown. The address is wrong or the mailbox is gone. Check the spelling against what the person gave you. No DNS change helps. 550 5.1.1.
• 550 5.2.1, inactive or disabled. The mailbox exists and isn't accepting mail. Only their admin can change that. 550 5.2.1.
• 552 or 5.2.2, quota or storage. The mailbox is full. Wait a day or reach the person another way.
• 554 5.7.1, or any 5.7.1 without DMARC in it. The receiver's spam filter or a rule the recipient's admin set refused it. 554 5.7.1 and Message blocked cover the variants.
• 421, 450, 451, or anything starting 4. That's a delay. Gmail keeps retrying for a while and may deliver yet. If it never does, you get a second notice. 421-4.7.28 is Gmail's own rate limit.

What matters is whether the reply is an address error or a policy error. The status code shows which, and the hard or soft label doesn't. Hard bounce vs soft bounce explains why.

Unauthenticated mail

Most people who land here sent from a company domain, through Gmail, Outlook or a sending service, and a Gmail recipient bounced it with 5.7.26. Google requires every message it accepts to pass SPF or DKIM for the domain in the From address. Yours passed neither.

You can check each of these causes in a few minutes.

1. The sending service isn't in your SPF record. Whatever sent this message, Google Workspace, Microsoft 365, a CRM, a newsletter tool, has to appear in the SPF record at your domain. Look it up:
   dig +short TXT example.com | grep v=spf1
   One line comes back. If the service's include isn't in it, add it. If two lines come back, that's a separate failure, and two SPF records break both.
2. DKIM isn't turned on for that service. SPF breaks whenever mail is forwarded, so Google's requirement is really about DKIM. Every service has a switch for it, usually under a name like authenticate this domain, and it hands you a CNAME or TXT record to publish. Publish it and turn the switch on. The DKIM checker confirms the key is visible once you know the selector.
3. The From domain doesn't match either one. SPF passing for the service's own domain doesn't count. It has to pass for a domain that matches your From address, or DKIM has to be signed with your domain. Alignment is the rule, and the common miss is a service signing with its own domain by default.

Then send one message to a Gmail address you control and open it with Show original. The line that starts Authentication-Results should say spf=pass or dkim=pass against your domain. If it does, send the rest.

A personal Gmail account sending as another domain

Gmail lets you send from a custom address with Send mail as. If that address's domain has no SPF record covering Google, or covers it but the recipient enforces DMARC strictly, the bounce comes back to your Gmail inbox as Message not delivered. The fix is the same DNS work, at the domain in the address you're sending as. If you don't control that domain, ask whoever does, or send from your Gmail address instead.

Bounces for mail you didn't send

A bounce quoting a message you don't recognize is backscatter. Someone put your address in the return path of their spam, a receiver refused it, and the refusal came to you. Your account wasn't used. Check Sent to be sure, and if it's empty of the message, delete the notice. A DMARC policy of p=reject on your domain makes forging your address in the visible From much less useful to them.

Silent failures

One recipient bounced this message. The same misconfiguration was failing at every Gmail recipient, and most receivers file a failing message in spam without telling you. The DMARC aggregate reports receivers send list every server that sent as your domain and whether it passed. We read those reports, and our weekly digest lists each failing sender, and on a paid plan we email you the day an unfamiliar one first fails. Your first domain is free.