Two entirely different situations
The message always looks the same but means different things depending on direction:
- You send, a foreign server rejects. The address genuinely is unknown there — a typo, a closed mailbox, someone who left. Nothing on your side needs repair.
- Someone sends to you and gets the message from your own server. That is the interesting case: the address ought to exist, but your mail server does not know it. The cause is almost always a gap between what the MX accepts and what is supposed to be delivered afterwards.
When your own server rejects
The most common trigger is a migration or cutover. The MX record already points at the new target, but the mailbox has not been created there — or the reverse, where the old server still accepts mail thanks to DNS caching and no longer finds the mailbox.
Check in this order:
- Where does the MX actually point? What counts is not what you entered but what senders resolve right now. Old values linger in the network until the TTL expires.
- Does the target know the address? On Postfix that is the chain of
virtual_mailbox_maps,virtual_alias_mapsandlocal_recipient_maps. Without an entry there it rejects, even when the mailbox sits on disk. - Case, dots, plus signs. Some delivery paths treat
first.last@andfirstlast@as different addresses. Aliases cover that, provided they are maintained. - Directory synchronisation. In hosted environments the address list comes from a sync. If that is not running, a freshly created mailbox does not yet exist at the perimeter.
Why rejecting beats accepting silently
A server that accepts every address and only afterwards notices it cannot deliver has to generate a non-delivery report itself — addressed to a sender that, with spam, is forged. This backscatter puts your own IP on blacklists. Rejecting inside the dialogue, which is exactly what this 550 5.1.1 does, is therefore the desired behaviour.
Telling it apart from similar codes
450 4.1.1 is the same statement as a temporary rejection — the mail stays queued and is retried. 550 5.4.1 Access denied from Microsoft 365 looks similar but deliberately does not reveal whether the mailbox exists; the cause there is a different one.