Is it common for ERP systems to halt when email delivery fails?

You’re not crazy for thinking this way; it’s a design flaw that’s surprisingly common! A well-built ERP should treat email as a non-blocking action. Ideally, the financial transactions should process first, and any notifications should just be queued up to send later.

In theory, good ERP systems should not depend on external SMTP servers for critical functions. Often, they should instead implement a reliable SMTP relay on-site to ensure high availability. Failing that, they should manage email as a best-effort process, where the ERP continues without waiting for email delivery confirmation.

From my experience, ERP systems typically need everything to be functioning perfectly or nothing works at all. Sure, some systems have ways to queue non-critical tasks like emails, but most importantly, if a notification fails, it could mark the whole transaction as incomplete. Older systems are especially prone to this kind of issue.

Yes, this is quite common in the ERP world. The logic often dictates that if any part of a process fails, the entire transaction gets halted. This can be due to poor design choices, though it does vary by company needs. In some cases, it could be designed to allow email failures without stopping other tasks. But whether that’s a good approach really hinges on the business process in place.
If you'd like, I can go into more detail about possible solutions.

You’ve got to wonder about the reliability of that SMTP server! How often does it actually go down? Are there no backups in place? You shouldn't have to stop financial operations just because of a mail server issue.