Mailer Daemon: What the Message Means and What to Do

A mailer daemon email is an automatic report from a mail server saying that a message sent from your address could not be delivered. Nobody typed it, and on its own it is no sign that your account has been hacked.

In Gmail it comes from Mail Delivery Subsystem, [email protected], often with the subject "Delivery status notification (failure)" (Gmail Help).

If the failed message looks unfamiliar, check your Sent folder first. If it is not there, the notice is usually backscatter from a forged address, so mark it as spam and do not click its links.

What is a mailer daemon?

A mailer daemon is the part of a mail server that delivers messages and reports the ones it cannot deliver. "Daemon" is the Unix word for a program that runs in the background.

The reports traditionally carry the sender name MAILER-DAEMON, in capitals. Request for Comments (RFC) 3464, the standard that defines them, uses a 1994 bounce as its example. That bounce was sent from "Mail Delivery Subsystem", the name Gmail still uses (RFC 3464, 2003).

The standard calls the report a delivery status notification (DSN). Microsoft calls it a non-delivery report (NDR), and most people say the email bounced back.

Senders who mail a whole list also watch the difference between hard and soft bounces and their bounce rate. For one email, reading the notice is enough.

How to read a mailer daemon message

Read the notice from the top. The first lines give the reason in words, and the block underneath names the failed address, the receiving mail transfer agent (MTA) and the code.

Most reports share a three-part layout from RFC 3464: a plain explanation, a status block and a copy of your original message or its headers. Each provider labels the notice in its own way:

• Gmail: the notice can land in Spam rather than the inbox, so check both folders.
• Outlook.com and Microsoft 365: a postmaster address such as [email protected] (Microsoft Support), with "Undeliverable:" in front of your subject (Microsoft KB 4294212). The code sits under "Diagnostic information for administrators" or, in the newer layout, "More info for email admins", beside a diagram of who has to fix the problem (Microsoft Learn, updated August 2026).
• Postfix, the open-source mail server: sender MAILER-DAEMON (Mail Delivery System), subject "Undelivered Mail Returned to Sender" (Postfix documentation).

Here is an example of that layout with made-up addresses. The .example ending is reserved for examples like this one.

From: Mail Delivery Subsystem <[email protected]>
To: [email protected]
Subject: Delivery Status Notification (Failure)

Your message to [email protected] could not be delivered.
The receiving server says this mailbox does not exist.

Reporting-MTA: dns; mail.example.co.uk

Final-Recipient: rfc822; [email protected]
Action: failed
Status: 5.1.1
Remote-MTA: dns; mx.supplier.example
Diagnostic-Code: smtp; 550 5.1.1 Recipient address rejected: user unknown
Last-Attempt-Date: Sat, 24 Oct 2026 09:12:41 +0100

[a copy of your original message, or its headers]

Line	What it tells you
From and Subject	Which server wrote the report. When the far end refuses, it is usually your own provider
First lines	The reason in plain words, often enough on its own
Final-Recipient	The address that failed. Check its spelling here, after the @ as well as before it
Action	"failed" means the server has stopped trying; "delayed" means it is still trying and the message may yet arrive
Status	The status code, here 5.1.1
Remote-MTA	The receiving server that refused the message
Diagnostic-Code	That server's own reply, word for word
Attached copy	What was sent. If you did not write it, see the section on messages you did not send

What the numbers in a bounce code mean

A bounce code has two parts. The first is a three-digit reply code such as 550, from SMTP, the protocol mail servers use to talk to each other. The second is a status code in three parts, such as 5.1.1.

In both, the first digit decides what happens next. A 4 marks a temporary problem that may clear if the same message is sent again. A 5 marks a permanent one that will keep failing until something changes (RFC 5321, section 4.2.1).

The middle number of the status code tells you where the problem sits (RFC 3463):

• 1: the address, for example a typo or a mailbox that never existed
• 2: the recipient's mailbox, such as one that is full or switched off
• 3: the receiving mail system
• 4: the network or the route between servers
• 5: the conversation between the two servers
• 6: the message content, such as its format
• 7: security or policy, from spam filters to failed sender checks

A "failed" notice can still carry a code that starts with 4. It means the server kept retrying a temporary fault and then gave up.

The SMTP standard expects a sender to keep trying for at least four to five days (RFC 5321, section 4.5.4.1). The RFC 3464 example is exactly this case: a 4.0.0 failure sent after five days.

Read the words beside the code as well as the digits, because providers do not all use codes the same way. In the standard, 5.2.2 means the recipient's mailbox is full. At Microsoft 365 it means your own account has gone over its sending limit, as the table below shows.

Common mailer daemon codes and what to do

Most notices carry one of a handful of codes. The meanings below come from Google's list of Gmail SMTP errors and Microsoft's NDR reference for Exchange Online.

Code	What the server is saying	What to do
550 5.1.1, or 5.1.10 at Microsoft	The address does not exist	Check the spelling, including the domain. In Outlook, delete the old suggestion from the To box before you retype it (Microsoft Support)
550 5.2.1	The mailbox exists but is inactive or switched off	Reach the person another way and ask for a current address
452 4.2.2, or 552 5.2.2 at Gmail	The recipient's storage is full (with 552 the account is also inactive)	Tell them, then resend once later. Sending again straight away fails the same way
552 5.3.4	The message is over Gmail's size limit	Remove the attachment and share a link to the file
4.4.7	Message expired: the retries ran out	Check the domain for typos. If it is right, the receiving server may be down, so try later
550 5.7.1	A policy or spam filter refused the message	One recipient: they may accept only approved senders, so ask them. Many recipients: look at your domain and its sender reputation
550 5.7.26 at Gmail; 5.7.23 or 5.7.509 at Microsoft	Your domain failed SPF, DKIM or DMARC (the policy that ties both checks to your domain)	Ask whoever manages your domain to fix the SPF, DKIM and DMARC records
5.1.8, 5.1.90 or 5.2.2 at Microsoft 365	Your own account is blocked or over its sending limit. Microsoft says this can mean it has been compromised	Treat it as a possible hacked account (see below) and tell whoever runs your email
"You've reached the limit for sending email" at Gmail	A personal Gmail account sent more than 500 emails in a day, or one email to more than 500 recipients	Wait. Gmail lets you send again within 24 hours

Microsoft 365 administrators can also paste a code into the NDR diagnostic in the admin centre, which runs tests and suggests a fix.

Mailer daemon emails about messages you did not send

A bounce for a message you did not send usually means a spammer put your address on their mail as the sender. In that case your account was not touched.

This is called backscatter. The spam reached a server that accepted it, found no such recipient and returned the report to the forged address (Microsoft Learn).

Gmail's advice is to report these notices as spam. The messages were created outside Gmail, so it cannot stop spammers using an address (Gmail Help).

Two other causes look similar at first, and the clues below tell them apart.

What you see	Most likely cause	What to do
Dozens of notices at once, for messages to strangers, none of them in your Sent folder	Backscatter	Leave your password as it is. The mail came from somewhere else
A notice that asks you to sign in, "release" held messages or open an attachment	Phishing made to look like a bounce	Do not click. Open your email from its usual address instead
Messages in Sent that nobody wrote, contacts reporting spam from you, or 5.1.8 from Microsoft 365	A compromised account	Change the password and check the account settings now

A genuine mailer daemon report explains a failure and quotes the receiving server. It has no reason to ask for your password.

In the UK, you can forward a suspect notice to [email protected], the reporting address of the National Cyber Security Centre (NCSC) (NCSC).

If the account itself was used, change the password from the provider's own site and turn on two-step verification. Then look for forwarding and inbox rules you did not create, which Microsoft lists among the signs of a compromised mailbox (Microsoft Learn).

Can you stop backscatter on your own domain?

You cannot stop a spammer typing your address, but on a domain you own you can make forged copies easy to refuse.

SPF and DKIM let a receiving server check that a message really comes from your domain. DMARC tells it what to do when that check fails.

With a DMARC policy of reject, a receiver that applies it refuses forged mail during the delivery conversation itself. The refusal goes back to the server that tried to send the message, which for spam is usually the spammer's own.

The current DMARC standard prefers this to accepting a forged message and reporting later. Those reports would go to the forged return address, which is how backscatter starts (RFC 9989, May 2026, section 7.2).

Your own policy is the p= tag in the _dmarc record of your domain, and tightening a DMARC policy from none to reject is safe once every real sender passes. Even then the odd notice can arrive, because large mail services cannot avoid sending some backscatter, as Microsoft notes.

On a free address such as @gmail.com, the domain belongs to Google, so there is no DMARC record for you to change.

How MailGraf handles campaign bounces

A campaign sent with MailGraf carries a return address on a bounce subdomain of your sending domain. Delivery reports go to that return address, as RFC 3464 requires, so the platform reads them and MailGraf files each one against the contact.

In the app, the campaign row on the contact's Activity tab then shows Bounced, with the code in its detail box. Whether the address is then blocked depends on the bounce type, under the rules for hard and soft bounces.

Delays get their own Delivery delayed rows, and a later row shows whether the email was delivered or bounced (Understand bounce codes).

Sent from an office mailbox, a newsletter can bring back a mailer daemon notice like the example above for each dead address on the list, and each one waits for you to remove that address by hand. Campaigns sent through MailGraf keep those reports out of your inbox, and the pricing page shows what the monthly plan includes.