Can smtp.mailfrom be different from return-path and can bounces be returned directly to sender?

Email marketer from Litmus explains the need for careful bounce management using the return-path. They indicate that large senders should set up a subdomain to receive bounces and feedback loop notifications and monitor these. This means the Return-Path is usually different from the From header.

Email marketer from SparkPost clarifies that the Return-Path, also known as the envelope sender or MAIL FROM, is where bounces and other delivery status notifications (DSNs) are sent. It's technically possible to set up the Return-Path differently, but this requires careful configuration and understanding of email authentication protocols.

Email marketer from StackOverflow indicates that bounces should go to the envelope sender (MAIL FROM) rather than the header FROM. It is generally bad practice for users to handle those bounces themselves. ESPs typically handle this better.

Email marketer from Mailjet notes that the 'Return-Path' is where bounce messages are sent, and it’s not necessarily the same as the 'From' address. Some email service providers (ESPs) manage bounces themselves using a custom Return-Path.

Email marketer from Super User points out that the Return-Path domain must pass SPF checks for proper authentication. If the MAIL FROM uses a different domain than the sending domain and SPF fails, it can lead to deliverability issues.

Marketer from Email Geeks shares an alternative is to send from your systems, and send the MX elsewhere. This means that if the 5321.From were "<http://myesp1.example.org|myesp1.example.org>" (with SPF setup appropriately), you could then change the MX to be anything you like, and it doesn't have to be your systems.

Marketer from Email Geeks explains the purpose of MAIL FROM (RFC5321) is to receive bounces, stating that if you want to get bounces, you must have your address issued in the MAIL FROM SMTP command.

Email marketer from Reddit explains that the MAIL FROM address is technically different from the 'From:' header. ESPs use this to manage bounces, feedback loops, and authentication. The 'From:' header is what recipients see.

Email marketer from Gmass shares that it is possible to set up a custom return path which will mean all bounce notifications and feedback loops will be sent to that address. Typically you want to create a dedicated address such as bounces@yourdomain.com and then monitor this address regularly.

Email marketer from SendGrid details that they handle bounce processing on behalf of users. Therefore, bounces are typically not forwarded directly to the sender's 'From' address but are processed by SendGrid's systems to improve deliverability for all users.

Marketer from Email Geeks confirms that "smtp.mailfrom" and "Return-path" are the same thing, referencing RFC5321.

Marketer from Email Geeks recommends to let the ESP process the bounce and find a way to also get them, one way or another. Most of clients wouldn't know what to do with NDRs, not to mention that most bounces are synchronous (made during the SMTP transaction) and not asynchronous (sent to the MAIL FROM: email address). So they get the information another way, be it by NDR that we generate (sent to a specific address of them), by csv files, API calls, webhooks ...

Expert from Word to the Wise explains that it's best practice to monitor your Return-Path for bounces and FBLs. If you're not doing it now, you could be missing a lot of insight into your program. Return-Path (MAIL FROM) should be a domain/subdomain you control so that you can monitor and act on any delivery problems.

Expert from Spam Resource points out that a good bounce management system is necessary to handle bounces correctly and ensure proper list hygiene. This usually involves having a separate MAIL FROM address to receive bounces.

Documentation from RFC Editor specifies that the receiving MTA must put in the Return-Path: header the information it received from the MAIL FROM: SMTP command. This means the Return-Path is intrinsically linked to the MAIL FROM.

Documentation from Oracle Help Center explains that it's possible to customize the Return-Path for bounce processing. This is beneficial for large senders who want to manage bounces on their own systems, however they recommend that users understand how this change may impact their deliverability and compliance.

Documentation from Amazon SES shares that they automatically handle bounces and complaints and provide you with notifications. They provide multiple methods to receive them including using Amazon Simple Notification Service (Amazon SNS). They don't directly bounce back to the original sender of the email.

Documentation from Microsoft Learn explains that the MAIL FROM address (specified during the SMTP conversation) is used for bounce messages. This is separate from the From: header in the email's content.

Documentation from DMARC.org notes that DMARC uses the MAIL FROM for bounce reporting. If the MAIL FROM domain doesn't align with the 'From:' header domain, DMARC authentication can fail, impacting deliverability.