SMTP Error 447

Is "SMTP Error 447" a real SMTP code?

Not as a raw reply code. The SMTP standard (RFC 5321) defines three-digit reply codes, and 447 is not one of them — the 4xx transient codes RFC 5321 itself defines are 421, 450, 451, 452, and 455 (454 is a separate SMTP AUTH extension code from RFC 4954). The string people read as "447" is almost always the enhanced status code 4.4.7 with the dots removed.

Enhanced status codes (RFC 3463) have the form class.subject.detail. Here:

• 4 = persistent transient failure
• .4 = "Network and Routing Status" (a delivery/routing problem)
• .7 = "Delivery time expired"

So when you see something like 400 4.4.7 message delayed or 550 4.4.7 Queue.Expired; message expired, the meaningful part is the 4.4.7, not "447."

What does 4.4.7 actually mean?

Per RFC 3463 §3.5, X.4.7 ("Delivery time expired") means:

"The message was considered too old by the rejecting system, either because it remained on that host too long or because the time-to-live value specified by the sender of the message was exceeded. If possible, the code for the actual problem found when delivery was attempted should be returned rather than this code."

In plain terms: your sending server kept retrying delivery because each attempt hit a temporary failure, and eventually the message sat in the queue past its expiration limit and was dropped. Microsoft 365 / Exchange Online, for example, retries delivery for about 24 hours before generating the 550 4.4.7 NDR.

Note: This is not a recipient-count limit. Hitting a server's max-recipients-per-message cap returns a different response (commonly 452 4.5.3 Too many recipients per RFC 3463). Don't troubleshoot 4.4.7 by batching recipients — that won't address an expired-queue/routing failure.

How do I fix SMTP Error 447 (4.4.7)?

Because 4.4.7 is the symptom of an underlying transient failure that never cleared, fix the root cause:

1. Read the full NDR / queue log. The real problem (DNS failure, connection timeout, recipient server 4xx throttling) is usually quoted alongside the 4.4.7. RFC 3463 itself says the original error should be preferred when available.
2. Verify the recipient domain's MX and DNS. A missing, wrong, or unresolvable MX record means your server can never connect. Confirm with nslookup -type=mx recipientdomain.com (or dig MX recipientdomain.com).
3. Check the recipient server's availability. If it was offline, full, greylisting, or rate-limiting your IP, every attempt returns a transient error until the queue expires. Retry once the remote host is healthy.
4. For Microsoft 365 / Exchange Online senders, follow Microsoft's 550 4.4.7 guidance:
5. Confirm your own domain's MX record is correct.
6. Ensure your SPF record (RFC 7208) lists all sending sources, so recipient servers don't soft-reject.
7. Test outbound mail with the Microsoft Remote Connectivity Analyzer (Outbound SMTP Email test).
8. In hybrid deployments, re-run the Hybrid Configuration Wizard if on-prem IPs/firewall rules changed.
9. On self-hosted Exchange / on-prem MTAs, check for a backed-up queue or Back Pressure (low disk/memory freezes outbound mail), restart the transport service, and review the queue in Queue Viewer. You can also lengthen the expiration timeout to buy retry time — but that masks the real failure, so fix items 2-4 first.

Sending through an API instead

If you send transactional or notification email through a provider (such as Courier routing to SendGrid, Amazon SES, Mailgun, or Microsoft 365), a 4.4.7 surfaces as a delayed/expired delivery event. Check the provider's message logs for the original transient error, verify the recipient domain resolves, and confirm your authentication (SPF/DKIM/DMARC) is aligned so downstream servers stop deferring your mail.