Error Messages

The receiving server checked your domain's SPF record and did not find the sending IP in it. Because your record ends in -all, that is an explicit rejection.

Your SPF record exceeds the limit of 10 DNS-querying mechanisms. The consequence is not “partially valid” but: SPF counts as unevaluable — for all your mail, including from your main server.

DMARC passes only when SPF or DKIM passes and the domain it checked aligns with the domain in the From: header. That second condition — alignment — is almost always the reason for this message.

This message says something very specific: the key was found, the signature is formally fine — but the message body is no longer the same as when it was signed. Something along the way touched it.

The receiver read the signature, looked for the matching public key in DNS — and found nothing. The fault is almost always in DNS, not in the mail server.

This wording comes almost exclusively from Microsoft — Exchange Online and Outlook.com. Substantively it is an SPF hard fail; the 5.7.23 number is Microsoft's own flavour of it.

Microsoft's phrasing for a DMARC rejection. The key word is verification: it is not SPF or DKIM alone that failed, but their alignment with the domain in the From: header.

This message does not mean your policy struck. It means the receiving server found your DMARC record but could not evaluate it. The record itself is broken.

The server logged you in successfully and still rejects: the account you identified with is not allowed to use the address in the From header. That is a permissions question, not an authentication question.

Per RFC 7208 temperror means the check was not performable, not negative. Somewhere in the resolution chain DNS gave no usable answer — a different problem from a malformed record.

STARTTLS upgrades an existing plaintext connection on port 25 to an encrypted one. If that transition fails, delivery aborts — even though the server is reachable and DNS resolves correctly.

In SMTP a failed certificate check is often inconsequential — most servers still encrypt opportunistically. The moment MTA-STS or DANE is involved, however, it turns into a hard rejection.

The server cuts the dialogue short before it takes credentials or a sender: no encryption has been negotiated on this connection, and without it nothing proceeds here.

The server advertised STARTTLS among its capabilities and then refused the negotiation. This is not a mismatch between two sides but a local problem on the answering server.

The message usually names the list that triggered it. That is the most valuable piece of information in it — because lists differ enormously in how much they matter.

The first digit decides: 4xx is temporary, the message is not lost. Your server will try again. A persistent 421 is still a warning sign — it is practically always about reputation.

Codes 5.7.606 through 5.7.614 come from Microsoft's own block list. It is not publicly queryable — so an IP can be blocked here while every public DNSBL reports it clean.

Greylisting refuses every unknown sender once and lets them through on the second attempt. A real mail server retries automatically, many spam tools do not. A single delay is therefore entirely normal.

Microsoft accepts no mail at all from this address. Unlike a listing, this is rarely about your sending behaviour and usually about the address range you sit in.

Unlike a blacklist block, this rejection is about the specific message. Sending IP and authentication may be flawless — what was objected to is the content itself.

The message is bigger than the file size of the attachments suggests. Attachments are re-encoded for transport and grow by roughly a third in the process — the cause of most surprise about this error.

This block targets an attachment, not the message body and not your reputation. It applies regardless of whether anything malicious was found — the file type alone is enough.

This rejection almost exclusively hits self-hosted mail servers. The receiver looks the sending IP up in reverse and finds no name — or one that does not confirm going forward.

The classic Postfix restriction reject_unknown_client_hostname. Unlike 550 5.7.25 this code is temporary — the far side keeps retrying and the mail sits in the queue instead of bouncing immediately.

A mail server accepts messages in only two cases: for its own recipients, or from authenticated senders. This message means neither applies — and usually that is not a fault but correct behaviour.

This rejection is a statement about the recipient side, not about your reputation. The accepting server is saying: no mailbox is set up here for this address.

This message almost always comes from Exchange Online and is deliberately uninformative: it does not reveal whether the mailbox exists. That is what makes the diagnosis unusual — you have to narrow it down from outside.

This message appears at submission, not at delivery — your program logs in to an outgoing server and is turned away. In most cases the password is correct and still wrong.