Sendmail Failures

A program on your server can send mail by handing it to the system sendmail command; PHP's mail(), a contact form, and a cron job usually work this way. The message passes two checks before it can leave:

1. the panel checks the sender, and
2. the outgoing mail filter checks the message itself.

If either refuses, nothing leaves and nothing tells the program why: mail() returns, and the message never arrives. Sendmail Failures records those refusals, so a send that disappeared becomes something you can read and repair.

This page covers only the direct sendmail path

Mail over authenticated SMTP submission, from a mail client or an application that signs in with an app password on port 587 or 465, is governed by the credential. These rules don't limit it, and it never appears here.

Why the panel refuses a send

A script on your account can send only as a real address on a domain where you turned email on.

Why the rule exists

Mail leaving your server has to go out as a genuine address on one of your own domains, so the panel can sign it and it passes authentication at the receiving end (see Sender verification). The panel can't sign a message from somebody else's domain, from an address that doesn't exist, or from no address at all, so it refuses the message rather than send an unsigned one that fails somewhere else.

Each entry names the reason, and the reason tells you the fix:

Reason	The fix
The sender's domain is not one of yours	Send as an address on a domain where email is on, or turn email on for that domain.
That address does not exist on your account	The domain is yours and email is on, but no mailbox, alias, forwarder, group, or send-only address has that name. The usual cause is an application that makes up its own sender, e.g. wordpress@yourdomain. Create the address (a send-only address is the best choice for an application), or send from one you already have.
No sender address was given	A web script sent mail with no From address, the default of PHP's mail(). Set an explicit From on one of your domains.
The address is not valid	The panel couldn't read the From value as an email address.
The account has no mail-enabled domain at all	Nothing to send as yet. Add a Mail service to one of your domains first.
The message was refused as spam	The sender was fine, but the outgoing filter decided the message itself is spam. See below.
You reached the outgoing-mail rate limit of your account	About how much you sent, not who you sent as. Every send is refused until the limit recovers on its own. If a legitimate workload needs more, ask your provider. See Quotas and limits.

note

The rate limit and "no mail-enabled domain" belong to the account, not to one address. Their entries show No specific sender, and one day's attempts become one row for the whole account.

Why the filter refused a message as spam

A spam refusal is the one reason where the sender was accepted and the message refused. It uses the same kind of score Spam filter describes, applied to outgoing mail.

Why the panel filters outgoing mail

A compromised script sends spam as your domain, and that damages the domain's reputation everywhere the spam reaches.

The entry's detail view carries the filter's report:

• the spam score the message reached, and the threshold it had to stay under;
• what the filter marked: the checks that raised the score, each with its contribution and, where the filter describes it, a plain-words explanation;
• the filter reply, exactly as it came: the refusal the mail system produced.

Most refusals are the sum of small problems

A missing Date header, a subject in capital letters, HTML with no plain-text part. Usually no single check causes the refusal, and that list is where the fix is.

Mail from an application often has this problem, because a program builds the message by hand; setting the headers a real mail client sets is often enough to bring the score back under the threshold. Where the content is fine, the problem is usually authentication: check the SPF, DKIM, and DMARC records of the sending domain. See Sender verification.

WordPress comment mail must go to an address on this server

One refusal is our own rule, not a spam score, and it causes most of the WordPress mail refused here. We refuse a new-comment notification and a comment awaiting moderation notice when it goes to a mailbox this server doesn't deliver to.

The fix: set the site's notification address to an address on one of your own domains. WordPress sends both messages to the administration email under Settings → General, or to the post author's address. The same mail then passes unchanged.

Why

That mail carries the comment body, the commenter's name, and the URL they gave, all written by a stranger. Relayed to an external provider, it would be our server delivering that stranger's text to them, and comment spam that travels this way is one of the fastest ways to damage a sending reputation. A message to a mailbox here never leaves the server, so it isn't refused.

A forward doesn't avoid the rule

The forwarded copy leaves the server the same way, and the filter judges it the same way. Read the mail in webmail or in a mail client instead.

The rule affects only those two kinds of comment mail. A WordPress registration, password-reset, or recovery message concerns the security of an account; you can legitimately need it at an external address, so it is never refused for this reason.

Some refusals have no detail

They stop before the filter scores the message. The common one is the GTUBE test string, which every spam filter has to treat as spam, so the entry says that and nothing about the real content. When there's no score and the panel doesn't recognize the reason, it shows the filter's reply as it came.

How the panel groups the entries

The log doesn't keep one row per attempt; a broken job that tries every minute would fill the page. The panel keeps one entry per sender and reason, per day:

• Another attempt the same day raises the entry's attempt count and moves its "last attempt" time forward.
• A new day starts a new entry if the problem continues.
• An entry is kept for 100 days.

The detail view shows the attempt count and the first and last time. Where known, it also shows the program's request URL and the system user it ran as, plus the domains you can send as.

The panel tells you once a day

You don't have to watch this page. When a new problem appears on a day, the panel also delivers a short notice to your System Mailbox, from the panel itself rather than one of your domains, describing what was blocked and how to fix it. For a spam refusal it also carries the score and the checks that marked the message.

At most one notice per problem per day, so a job that runs continuously produces one notice, not thousands.

When the panel permits a send

A permitted send isn't recorded here. The mail goes out and appears on the Email Traffic Log as application-generated email, with the rest of your mail.

This page holds only refusals. A refused message was never queued, so it has no delivery record in the traffic log.