Message not delivered: read the line under it, then fix that

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 everything on this page works 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.

Find the reply line

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, not from Gmail. 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.

Match the reply to its fix

Each of these has its own page with the exact strings and the full fix. Here is enough to know which one you're on.

• 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. Your DNS is the fix, and it's the case the rest of this page covers. The 550-5.7.26 page 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. 554 5.7.1 and Message blocked cover the variants.
• 421, 450, 451, or anything starting 4. A delay, not a refusal. 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.

The split between the address errors and the policy errors is the one that matters. Hard bounce vs soft bounce explains why the hard or soft label doesn't tell you that, and the status code does.

Unauthenticated: the fix is in your DNS

This is the version most people land here with. You 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.

Three things cause that, and you can check all three 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.

Notices for mail you never sent

A bounce quoting a message you don't recognise 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.

After the fix: the bounces you won't see

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. Our weekly digest reads those reports and lists each failing sender, and on a paid plan we email you the day an unfamiliar one first fails. Your first domain is free.