"This is an automated message, please do not reply" is a decision, not a default. Most transactional email providers make it the path of least resistance -- send-only APIs have nowhere for a reply to land, so the easiest thing to do is tell customers not to send one.
What a no-reply address actually costs you
- Lost customer replies. A customer who hits reply on an order confirmation to ask "can I change the delivery address?" gets nothing back -- or a bounce. That's a support request you never see, not one that disappeared.
- Confused support tickets. The same customer eventually finds a contact form or a different email address, and now your support team is reconstructing context that was already sitting in the original thread.
- Missed delivery-failure signals. When a no-reply address doesn't exist at all, bounce and out-of-office replies can go nowhere useful, instead of surfacing a real delivery problem.
The fix isn't "reply-to your support inbox"
Setting a Reply-To header to point at a shared support inbox is better than nothing, but it detaches the reply from the specific transactional context that triggered it -- the order, the invoice, the password reset -- unless something on the receiving end reconstructs that thread manually.
What MailKaka does instead
Every MailKaka domain gets a real shared mailbox by default. When a customer replies to a transactional email, the reply is received through the same domain, threaded, and visible to your team in the same product that sent the original message -- not routed to a separate inbox you have to check somewhere else.