SMTP error 2.1.5 Destination address valid

What SMTP error 2.1.5 means

This is a success, not a fault. It confirms the address you sent to is a real, accepted recipient on the receiving system, and it is the code that goes with a 250 reply or a positive delivery notification. People meet it while reading logs, headers or a delivery receipt rather than in a bounce. It says the recipient was accepted; it does not say the message landed in an inbox and was read.

Address status
Sent by The receiving server, in a positive delivery report or in the SMTP conversation itself
Occasional

What SMTP error 2.1.5 Destination address valid actually means

During an SMTP conversation the recipient is named in a RCPT TO command, and the receiving server has to say whether it will take responsibility for that address. When it answers 250, this is the enhanced code attached to the answer. It is the exact opposite of an unknown recipient rejection, and useful evidence when somebody insists an address does not exist. What it does not describe is the journey after acceptance: filtering, transport rules, forwarding, the junk folder and the recipient's own inbox rules all come later. It also appears in a delivery status notification, which is where you meet it if a delivery receipt was requested and honoured.

This mailbox address as specified was valid. This status code should be used for positive delivery reports.
— RFC 3463

How 2.1.5 appears in a bounce

A server reporting this condition sends it alongside a three-digit reply code, and a bounce prints the two together. The registry lists 250 2.1.5 as the pairing for this status.

The leading 2 is the server's verdict rather than part of the code's identity: it marks this as a success notice rather than a failure.

What causes SMTP error 2.1.5 on a business phone system

A positive delivery notification requested by the senderWhere a sender asks for a delivery receipt and the receiving system supports it, the notification carries this code. A great many organisations disable receipts as policy, so their absence is not evidence of anything.
A successful RCPT TO in an SMTP session logReading a verbose sending log or a packet capture, this sits alongside the 250 as each recipient is accepted. On a message to several recipients it shows which of them the server took on, one line at a time.
Address verification by a gateway or list platformMarketing platforms and some filtering gateways open a connection, name the recipient and read the answer without sending anything. An accepted recipient produces this result, which is how list-cleaning tools decide an address is live.
Multi-recipient delivery where some addresses succeeded and others failedOne message to several recipients can produce a report combining this code for those accepted with a failure code for those refused. Reading only the failure lines gives a misleadingly bleak picture.

How to fix SMTP error 2.1.5

Treat it as evidence, not as something to repairThere is nothing to fix. If a monitoring tool has flagged it as an error, the tool is misreading the class digit. A leading 2 is a success in every enhanced status code.
Use it to settle whether an address existsWhen somebody claims a recipient is invalid and your logs carry this code against it, their server accepted that address at that moment. The investigation moves to what happened after acceptance.
Follow the message onward with a traceAcceptance is the start of the story on the receiving side. Ask the recipient organisation to run a message trace, showing whether filtering quarantined it, a transport rule redirected it, or an inbox rule filed it somewhere unexpected.
Check the junk folder and any quarantine before escalatingThe most common sequel to an accepted recipient and a missing message is the junk folder or the hosted quarantine. Both are a thirty-second check and they close a large share of these cases.

Fixing the underlying problem

This page explains the code. These guides walk through the fix in detail.

Questions about SMTP error 2.1.5

Does this prove the recipient received my email?

It proves their server agreed to take responsibility for the address. Everything deciding whether a human sees it happens next: content filtering, transport rules, forwarding, the junk folder and their own rules. Accepted and read are two very different claims, and this supports only the first.

Why is a success code showing up in my mail logs at all?

Because delivery status codes are not only for failures. The scheme covers success, temporary failure and permanent failure, and the leading digit says which. Verbose logging records the successful ones too, which is what you want when you need to prove a message was accepted.

Can I use this to check whether an address is valid before sending?

Technically possible and generally a bad idea. Many platforms accept every recipient at the door and decide later, so the answer is unreliable, and a pattern of connections naming recipients without ever sending looks like address harvesting and will damage your reputation.

Related SMTP status codes

Source. SMTP error 2.1.5 Destination address valid is defined in RFC 3463 and registered in the IANA SMTP Enhanced Status Codes registry. The causes and fixes above are drawn from our own experience supporting UK business email systems.

All Email delivery & SMTP codes