Mailer-Daemon Emails Explained: What Gmail's Bounce Means and How to Fix Every Error (2026)

Last updated: October 2026 · Bounce examples re-checked against Gmail on October 5, 2026

You sent an email, and a minute later a message from Mail Delivery Subsystem <[email protected]> landed in your inbox. Or worse: you’re getting these bounces for emails you never sent.

This guide answers the three things people actually want to know when that happens:

1. Is this message real, or is it a scam?
2. What does the error code inside it mean?
3. What exactly should you do to fix it?

Every bounce example below is a real Gmail bounce from our own team’s inbox (we changed the recipient addresses for privacy). No mock-ups from five years ago, no guesswork.

What is [email protected], and is it legit?

Yes, [email protected] is a real Google address. It’s the automated sender Gmail uses to tell you a message couldn’t be delivered. Gmail shows it with the display name Mail Delivery Subsystem, and the subject line is almost always one of these two:

• Delivery Status Notification (Failure) — Gmail has given up. The message will not be delivered.
• Delivery Status Notification (Delay) — Gmail hit a temporary problem and is still retrying.

Why “googlemail.com” and not “gmail.com”? Googlemail was the name Gmail used in the UK and Germany in its early years, when the Gmail trademark wasn’t available there. Google kept the domain, and its bounce system still sends from it today. So the odd-looking domain is not, by itself, a sign of a scam.

A “mailer-daemon” is simply the program on a mail server that handles delivery. When delivery fails, it writes back to the sender with the reason. Yahoo, Outlook and every other provider has one too. They just use different names, such as Microsoft Outlook or [email protected].

The real question is not “is the address real?” It’s “did I actually send the email this bounce is about?” That’s what separates a normal bounce from spoofing or phishing.

Is this bounce real or a scam? A 30-second check

Over the past year, Reddit’s r/GMail and Google’s own help community have filled up with people asking about mailer-daemon messages they didn’t expect. There are three very different situations hiding behind the same sender name. Here’s how to tell them apart.

Situation 1: A normal bounce (you sent the email)

You’ll find the original email in your Sent folder, the recipient in the bounce matches who you emailed, and the bounce includes a “The response was:” section with a code like 550 5.1.1. This is Gmail doing its job. Jump to the error codes section below to fix it.

Situation 2: Backscatter (someone faked your address)

You get bounces for emails that are not in your Sent folder, often to strangers or in languages you don’t speak. This is called backscatter. A spammer put your address in the “From” or “Return-Path” field of their spam. When their spam bounced, the bounce came to you.

Backscatter does not mean your account is hacked. Spammers don’t need your password to forge a From address, the same way anyone can write any return address on an envelope. Here’s what to do:

1. Check your Sent folder. If the bounced message isn’t there, it didn’t come from your account.
2. Check recent sign-ins. Go to your Google Account → Security → Your devices and Recent security activity. Look for logins you don’t recognize.
3. Turn on 2-Step Verification if it isn’t on already. It costs nothing and stops most account takeovers.
4. Don’t click anything inside the bounce. A backscatter bounce often quotes the spammer’s original message, links and all.
5. Mark them as spam and wait. Backscatter waves usually stop within a few days once the spam run ends.
6. If you own the domain ([email protected], not @gmail.com), publish a DMARC record with p=quarantine or p=reject. That tells receiving servers to drop mail that fakes your domain, so it never bounces back to you in the first place.

When it is a compromise: if the bounced emails are in your Sent folder and you didn’t write them, someone has access to your account. Change your password from a clean device, sign out of all other sessions, turn on 2-Step Verification, and check Gmail’s Filters and Blocked Addresses and Forwarding settings. Attackers often add a forwarding rule or a filter that hides replies.

Situation 3: A fake bounce (phishing)

These look like bounces but are actually phishing emails. They don’t come from [email protected], even if the display name says “Mail Delivery System” or “Mailbox Administrator.”

The five red flags in the example above:

1. The sender address isn’t Google’s. It’s a random domain made to sound official.
2. The subject is vague and urgent (“Important Message Delivery Notice”) instead of “Delivery Status Notification.”
3. There’s a deadline or a threat (“verify within 7 days or messages will be deleted”).
4. There are buttons asking you to act (“Release messages”, “Verify account”). Real Gmail bounces have one “Learn more” link to support.google.com, and that’s it.
5. There are no technical details. A real bounce always names the failed recipient and includes a server response.

Gmail never asks you to log in, verify, or “release” anything from a bounce message. If one does, delete it and report it as phishing.

How to read a Gmail bounce message

Once you know the bounce is real, everything you need is in five places. Here’s a real one from October 2026:

1. Sender — Mail Delivery Subsystem <[email protected]>. This confirms it’s a genuine Gmail bounce.
2. Heading — Gmail’s plain-English summary. You’ll see one of five: Address not found, Message blocked, Delivery incomplete, Message not delivered, or a Google Groups notice.
3. The failed recipient — the exact address that bounced. Check it for typos first; most bounces end right here.
4. The response — the reply from the receiving server, with the SMTP code (550) and the enhanced status code (5.1.1). This is the part that tells you why.
5. Technical details — Status: repeats the code, and Action: says whether Gmail has given up (failed) or is still trying (delayed).

The one rule worth memorizing: if the code starts with 4, the problem is temporary and Gmail is retrying. If it starts with 5, it’s permanent, and sending the same email again will get the same result.

The middle number narrows it down:

Code pattern	What it’s about	Usually fixed by
x.1.x	The address (recipient or domain doesn’t exist)	You — correct or remove the address
x.2.x	The mailbox (inactive, full, disabled)	The recipient, or you remove them
x.4.x	Routing/network (DNS, timeouts, server unreachable)	The recipient’s IT, or time
x.7.x	Security and policy (authentication, spam filters, blocks)	You, if you’re a sender with your own domain

Gmail bounce messages and how to fix each one

Below are the bounces you’re most likely to see, starting with the most common. Each one shows the real message, what caused it, and the fix.

1. “Address not found” — 550 5.1.1 The email account that you tried to reach does not exist

This is the same bounce shown in the annotated example above: the heading is Address not found, and the response starts with 550 5.1.1.

What it means: The receiving server checked, and there’s no mailbox with that name. This is a hard bounce.

Common causes:

• A typo (jon@ instead of john@, gmial.com, a trailing space or period)
• The person left the company and their mailbox was deleted
• The address was guessed, scraped, or bought, and never existed

How to fix it:

1. Re-read the address in the bounce character by character. Look for doubled letters, swapped letters, and a missing or extra dot.
2. Check the address against an email signature, LinkedIn profile or company website, or just ask the person for their current address.
3. If you send newsletters or campaigns, remove the address from your list immediately. Retrying a 5.1.1 address doesn’t help and hurts your sender reputation.

A variation you’ll see: sometimes the same “Address not found” bounce arrives without the 550 5.1.1 prefix. The response just says “The email account that you tried to reach does not exist,” and the technical details show Status: 5.1.3. We saw this when the recipient’s domain was also hosted on Google Workspace. It means the same thing, and the fix is the same.

Something we noticed: one of our “Address not found” bounces came from replying to an email that urgently asked us for a “quick task” over WhatsApp. The sender’s Gmail account no longer existed a few days later. If your reply to an unexpected, urgent request bounces like this, the account was very likely removed for abuse. Treat the original email as a scam.

2. “Address not found” — 550 5.2.1 The email account that you tried to reach is inactive

This bounce has the same Address not found heading as 5.1.1. Only the server response is different:

550 5.2.1 The email account that you tried to reach is inactive. For more information, go to https://support.google.com/mail/?p=DisabledUser - gsmtp

What it means: The address exists, but the account has been disabled or abandoned. Google disables accounts that go unused for a long time and suspends accounts that break its policies.

How to fix it: You can’t fix this from your side. Reach the person another way and ask for a current address. For marketing lists, treat 5.2.1 exactly like 5.1.1 and suppress it.

3. “Address not found” — the domain couldn’t be found (5.1.2, NXDOMAIN)

What it means: Everything after the @ doesn’t exist on the internet. Gmail looked up the domain’s mail server (its MX record) and DNS answered NXDOMAIN, meaning “no such domain.”

Common causes: a typo in the domain (studoi for studio, .co for .com), or a company that let its domain expire.

How to fix it: Fix the spelling. If the domain is spelled correctly, search for the company: it may have rebranded or shut down. Look up its new domain or contact information.

4. “Message blocked” — 550 5.7.1 The user or domain … has a policy that prohibited the mail

What it means: The address is fine, but the receiving organization’s admin has set a rule that rejected your email. Notice the label: “The response from the recipient enterprise administrator was.” That tells you the block came from the recipient’s company settings, not from Gmail judging you.

Common causes:

• The address only accepts mail from inside its organization (common for support@ or team@ group addresses)
• Your domain or address is on the recipient’s block list
• The organization blocks attachments, links or file types that your email contained

How to fix it: Use the organization’s website contact form or another listed address. If you need to reach this exact address, ask your contact there to have their IT team allow your domain.

Note: 550 5.7.1 also appears when Gmail itself rejects a message as likely spam or for low sender reputation. In that case the wording mentions “unsolicited mail” or “reputation” instead of “enterprise administrator.” That version is covered under bulk-sender errors below.

Seeing 550 5.7.1 from Outlook or Microsoft 365 instead of Gmail? See why Microsoft blocks your email with 550 5.7.1.

5. “Message blocked” — 550 5.4.1 Recipient address rejected: Access denied

This is the most misread bounce in this guide. Gmail labels it “Message blocked,” so most people assume their domain has landed on a blocklist. It hasn’t.

Look at the server name in the response: it ends in outlook.com. That means the recipient’s company uses Microsoft 365. Microsoft’s own documentation explains that 5.4.1 “Access denied” comes from a feature called directory-based edge blocking, which rejects mail when the recipient address is not valid in that organization.

In plain English: on Microsoft 365, “Message blocked — 550 5.4.1” usually means “this address doesn’t exist.”

How to fix it: Treat it like 550 5.1.1. Check the spelling, then confirm the person’s current address. Only if you’re certain the address is correct should you ask the recipient to have their IT team check their directory sync.

6. “Delivery incomplete” — temporary failure, Gmail is retrying (4xx)

What it means: Something went wrong, but it might fix itself. The subject line says (Delay) instead of (Failure), the technical details say Action: delayed, and the status code starts with 4.

You don’t need to resend. Gmail keeps trying automatically and tells you how long it will keep trying (“Gmail will retry for 45 more hours”). In the example above, Gmail kept retrying for about 72 hours in total from the original send before it gave up.

Common 4xx causes:

• 4.4.3 / DNS SERVFAIL — the recipient’s DNS is broken or misconfigured
• 421 4.7.0 or 451 4.3.0 — the receiving server is overloaded or temporarily refusing connections
• 452 4.2.2 — the recipient’s inbox is full (see #8 below)
• 421 4.7.28 and other 4.7.x codes — Gmail is rate-limiting a sender for unusual volume or missing authentication (see the bulk-sender section)

What to do: Wait. If the message is urgent, contact the person another way. If you get delays for every address at one company, its mail server is likely down, so tell them.

7. “Message not delivered” — the retries ran out

What it means: This is how a “Delivery incomplete” story usually ends. Gmail retried for the full window, the problem never cleared, and it has now given up. In our case the recipient’s domain DNS stayed broken for three days. The domain turned out to be a throwaway one, which is a good hint that the address wasn’t worth chasing.

What to do: Contact the recipient by phone or another channel, or let them know their domain’s DNS needs attention. If this is a list contact, remove them.

8. “Recipient inbox full” — 452 4.2.2 or 552 5.2.2

What it means: The recipient’s mailbox has no space left. Gmail returns 452 4.2.2 (temporary, so it retries) when a Gmail inbox is out of storage, and 552 5.2.2 (permanent) when the inbox is full and the account looks inactive.

How to fix it: On 4.2.2, wait and let Gmail retry, or tell the person their storage is full. On 5.2.2, treat the address as abandoned and suppress it. A mailbox that stays full for weeks is a mailbox nobody reads.

9. Google Groups — “the group you tried to contact may not exist”

This bounce looks different from the others. It starts with “Hello [your address], We’re writing to let you know that the group you tried to contact (support) may not exist, or you may not have permission to post messages to the group.”

What it means: The address you emailed is a Google Group (shared inboxes like sales@ or support@ often are), and either the group was deleted or it only accepts messages from members or people inside the organization.

How to fix it: Use the company’s contact form or find a named person’s address.

Bulk-sender bounces: 550 5.7.26, 421 4.7.28 and Gmail’s authentication codes

If you send email from your own domain, through a newsletter tool, CRM or website, this section matters most. Gmail requires every sender to authenticate with SPF or DKIM. Senders of 5,000+ messages a day to Gmail must have SPF, DKIM and DMARC, a one-click unsubscribe, and a spam complaint rate below 0.3%. Starting November 2025, Gmail moved from warning non-compliant senders to rejecting their mail outright, with 4.7.x codes for temporary rate-limiting and 5.7.x codes for permanent blocks.

Google has since split its old catch-all codes into specific ones, so the code now tells you exactly which check failed:

How to fix Gmail authentication bounces

1. Check SPF. Your domain needs one SPF TXT record that includes every service that sends for you (Google Workspace, your email platform, your CRM). Two SPF records on one domain will fail.
2. Turn on DKIM in every sending service, and publish the DNS records each one gives you.
3. Publish DMARC. Start with v=DMARC1; p=none; rua=mailto:[email protected] so you can monitor without blocking, then tighten the policy later.
4. Make sure the visible From domain aligns with the domain that passes SPF or DKIM. This is the part most people miss when they send through a third-party tool on a shared domain.
5. Check your spam rate in Google Postmaster Tools. Above 0.3%, authentication alone won’t save you.

Once your records are fixed, most temporary 4.7.x rate limits clear by themselves within a day or two of sending clean, authenticated mail. 5.7.x rejections stop as soon as the failing check passes.

For a full walkthrough, see our guide to Gmail and Yahoo’s 2026 sender requirements.

Gmail bounce error codes: the complete cheat sheet

Bookmark this table. It covers every code we’ve discussed, plus the less common ones from Google’s official SMTP error list.

What 82 real bounces in our own inbox taught us

To write this guide, we didn’t just read documentation. We went through every bounce our marketing team’s Gmail inbox received between April 2025 and October 2026: 82 bounces, mostly from partnership and outreach emails sent one at a time.

Here’s what they broke down to:

Gmail heading	Count	Share
Address not found (5.1.1 / 5.1.3)	70	85%
Google Group not found / no permission	3	4%
Message blocked (5.7.1 policy / 5.4.1 Microsoft 365)	2	2%
Address not found — account inactive (5.2.1)	2	2%
Delivery incomplete (4xx, retrying)	2	2%
Message not delivered (after retries)	2	2%
Address not found — domain doesn’t exist (5.1.2)	1	1%

Shares are rounded, so they add to slightly more than 100%.

Three takeaways from our bounce data

1. Almost every bounce was a bad address, not a bad email. 85% were “Address not found,” and the Microsoft 365 “Message blocked” bounce (5.4.1) turned out to be an invalid address too. Not one bounce was an authentication failure. Our domain’s SPF, DKIM and DMARC were already in place. That pattern is typical: if your authentication is set up properly, the bounces you’ll see are almost all list-quality problems.

2. Guessed addresses bounce. Many of our 5.1.1 bounces came from [email protected] addresses that looked right but didn’t exist. Pattern guessing gets you a bounce rather than a reply.

3. Bounces arrive in seconds. Most of the 5.1.1 bounces landed 10 to 15 seconds after sending. If you’re watching for a bounce, you’ll know almost immediately. A temporary delay is the exception: Gmail’s “Delivery incomplete” notice in our sample came the next day.

What we changed: we now run outreach addresses through an email verifier before sending, the same step we recommend to customers before every campaign. For one-to-one email, a bounce is an annoyance. For a 10,000-contact campaign, an 85% bad-address share of your bounces is the difference between a clean sender reputation and a damaged one.

How to stop getting mailer-daemon emails

How you stop them depends on which of the three situations you’re in.

If they’re bounces for emails you did send: fix or remove the bad address using the sections above. The bounces stop when you stop emailing addresses that don’t work.

When they’re backscatter (emails you didn’t send):

1. Confirm the messages aren’t in your Sent folder.
2. Secure your account: new password, 2-Step Verification, review recent security activity.
3. Mark the bounces as spam. Gmail learns from this.
4. If the bounces are for your own custom domain, publish a DMARC record with p=reject once SPF and DKIM are passing.
5. Avoid creating a filter that auto-deletes every mailer-daemon message. You’ll miss real bounces for emails you did send. If you must filter, filter on a phrase that only appears in the backscatter, such as the spammer’s subject line.

For fake bounces (phishing): don’t click, report as phishing, delete. Already clicked and entered your password? Change it right away and check your account’s security activity.

For businesses: keep bounces from hurting your sender reputation

Mailbox providers watch your bounce rate. Keep hard bounces under 2% of every send. Repeatedly emailing addresses that return 5.1.1 tells Gmail you aren’t maintaining your list, and your good emails start landing in spam.

What works, in order of impact:

1. Verify addresses before you import them. Bulk-verifying a list removes the addresses that would return 5.1.1, 5.1.2 and 5.2.1 before you send a single email.
2. Use double opt-in on signup forms so typos never reach your list.
3. Suppress hard bounces automatically after the first 5.x.x bounce, and soft bounces after repeated 4.x.x failures.
4. Authenticate your sending domain with SPF, DKIM and DMARC so you never see a 5.7.26.
5. Re-verify old segments before reactivating contacts you haven’t emailed in six months or more.

Where Mailercloud fits: Mailercloud’s Email Verifier checks each address against the recipient’s mail server and sorts your list into Deliverable, Invalid and Risky. Credits start at $5 per 1,000 and don’t expire, and active Mailercloud subscribers get 100 free credits. On the sending side, Mailercloud automatically suppresses hard bounces and walks you through domain authentication when you add a custom sending domain. One honest limitation: Mailercloud’s library of third-party integrations is smaller than Mailchimp’s or HubSpot’s, so check that your CRM or store platform connects before you migrate.

FAQ: Mailer-Daemon Emails and Gmail Bounces

Summary

A message from Mail Delivery Subsystem <[email protected]> is Gmail’s real bounce notice. First, check your Sent folder to rule out backscatter and phishing. Then read the code: 4.x.x means wait, 5.x.x means fix. In practice, most bounces are “Address not found” (550 5.1.1), and the fix is a corrected or removed address. If you send campaigns from your own domain, authenticate it with SPF, DKIM and DMARC, verify your list before you send, and suppress hard bounces automatically.

Sending to a list and seeing too many bounces? Try Mailercloud free: 1,000 contacts on the free plan, with domain authentication, automatic bounce suppression and email verification built in.