Perl Mail::Mailer From Address, being ignored?

While using Perl Mail::Mailer to send from an on-site application to our Microsoft 365 tenancy via SMTP, we had an oddity. We’d already setup the Microsoft 365 tenancy to have a receive connector which was autheniticating via the source address, i.e. our on-premise IP range.

When testing via a test Perl script which was the same as the configuration used within the on-site application we hit a problem with it sending. The example Perl script test-email.pl is as follows:

use Mail::Mailer;
my $m = Mail::Mailer->new( 'smtp', 'Server' => 'blah.mail.protection.outlook.com', 'Debug' => 1,
  'Hello' => 'mydomain.com');
$m->open({ 'From'    => 'tristan@mydomain.com',
           'Subject' => 'TEST EMAIL',
           'Reply-To' => 'tristan@mydomain.com',
           'To'      => 'recipient@anotherdomain.com' } );
print {$m} "This is a test";
$m->close;
print "$!\n";

If using telnet to send and manually typing in the email it worked fine. But via the Perl script the following error was being given by Microsoft’s server:

Net::SMTP=GLOB(0x55634f206978)<<< 451 4.4.62 Mail sent to the wrong Office 365 region. ATTR35. For more information please go to https://go.microsoft.com/fwlink/?linkid=865268 [No TLS] [CW2PEPF00                                          0056BA.GBRP265.PROD.OUTLOOK.COM 2025-04-30T10:52:28.302Z 08DD86E66AB3BF99]

After some troubleshooting and analysing the debug logs, we noticed the “MAIL FROM” was being ignored for some reason, it was defaulting to send from some default address for the host, rather than the FROM address we specified within the script.

*** ADDR>> root@server123.internal.mydomain.com at /usr/share/perl/5.34/Net/SMTP.pm line 298.
*** ADDR<< root@server123.internal.mydomain.com> at /usr/share/perl/5.34/Net/SMTP.pm line 316.
Net::SMTP=GLOB(0x55634f206978)>>> MAIL FROM:<root@server123.internal.testing.com>
Net::SMTP=GLOB(0x55634f206978)<<< 250 2.1.0 Sender OK
*** ADDR>> recipient@anotherdomain.com at /usr/share/perl/5.34/Net/SMTP.pm line 298.
Net::SMTP=GLOB(0x55634f206978)>>> RCPT TO:<recipient@anotherdomain.com>
Net::SMTP=GLOB(0x55634f206978)<<< 451 4.4.62 Mail sent to the wrong Office 365 region. ATTR35. For more information please go to https://go.microsoft.com/fwlink/?linkid=865268 [No TLS] [CW2PEPF00                                          0056BA.GBRP265.PROD.OUTLOOK.COM 2025-04-30T10:52:28.302Z 08DD86E66AB3BF99]
Net::SMTP=GLOB(0x55634f206978)>>> DATA
Net::SMTP=GLOB(0x55634f206978)<<< 503 5.5.2 Need rcpt command [CW2PEPF000056BA.GBRP265.PROD.OUTLOOK.COM 2025-04-30T10:52:28.308Z 08DD86E66AB3BF99]
Net::SMTP=GLOB(0x55634f206978)>>> Subject: TEST EMAIL
Net::SMTP=GLOB(0x55634f206978)>>> Reply-To: tristan@mydomain.com
Net::SMTP=GLOB(0x55634f206978)>>> From: tristan@mydomain.com
Net::SMTP=GLOB(0x55634f206978)>>> X-Mailer: Mail::Mailer[v2.21] Net::SMTP[v3.13]
Net::SMTP=GLOB(0x55634f206978)>>> To: recipient@anotherdomain.com
Net::SMTP=GLOB(0x55634f206978)>>> This is a test
Net::SMTP=GLOB(0x55634f206978)>>> .
Net::SMTP=GLOB(0x55634f206978)<<< 500 5.3.3 Unrecognized command 'Length: 8' [CW2PEPF000056BA.GBRP265.PROD.OUTLOOK.COM 2025-04-30T10:52:28.314Z 08DD86E66AB3BF99]
Net::SMTP=GLOB(0x55634f206978)>>> QUIT

So now we can see why the email submission is failing, the question was “why was Mail::Mailer ignoring the FROM address specified in the $m (message) object?”

The resolution was to add the “from” into the original creation of the $m (message) object, i.e. as below, so both including it within that line and in the body of the message so to speak.

use Mail::Mailer;
my $m = Mail::Mailer->new( 'smtp', 'Server' => 'blah.mail.protection.outlook.com', 'Debug' => 1,
  'Hello' => 'mydomain.com', 'From' => 'tristan@mydomain.com' );
$m->open({ 'From'    => 'tristan@mydomain.com',
           'Subject' => 'TEST EMAIL',
           'Reply-To' => 'tristan@mydomain.com',
           'To'      => 'recipient@anotherdomain.com' } );
print {$m} "This is a test";
$m->close;
print "$!\n";

Now when testing and using the debug logs, the MAIL FROM: is being used as specified, rather than the server default one (which Microsoft 365 rejects because it didn’t contain our valid sender domain) meaning the correct from address was used and the message was accepted as expected.