{"id":494,"date":"2024-02-22T15:06:07","date_gmt":"2024-02-22T14:06:07","guid":{"rendered":"https:\/\/zupertails.be\/wur\/?p=494"},"modified":"2025-05-26T15:50:21","modified_gmt":"2025-05-26T13:50:21","slug":"sending-m365-mail-from-your-all-in-one-scanner-printer","status":"publish","type":"post","link":"https:\/\/zupertails.be\/wur\/?p=494","title":{"rendered":"Sending M365 mail from your all-in-one scanner\/printer"},"content":{"rendered":"

DISCLAIMER : as of sep 2025 the method described below will no longer work according to https:\/\/learn.microsoft.com\/en-us\/exchange\/mail-flow-best-practices\/how-to-set-up-a-multifunction-device-or-application-to-send-email-using-microsoft-365-or-office-365<\/h2>\n

 <\/p>\n

Precursor<\/h2>\n

Imagine the following : you recently migrated your mail platform from the “classic” POP\/IMAP mailbox setup towards Microsoft 356’s mail solution.<\/p>\n

If you’ve done the M365 setup correctly and migrated everything towards your new cloud environment (see tons of previous posts \ud83d\ude09<\/a>) you’ll soon run into some issues when trying to send an e-mail from your super-cool all-in-one printer\/scanner\/copy\/fax machine, which is hooked up to the network and ready to send scanned documents in your (domain) name.<\/p>\n

\"\"<\/p>\n

One of these issues being that you receive a NDR from your recipient relating to something like “Error 550 5.7.1 The user or domain that you are sending to (or from) has a policy that prohibited the mail that you sent<\/strong>” or anything basically that falls back to “we don’t trust this e-mail, because you smell of spam\/phishing\/malconfigured SMTP\/…<\/strong>”<\/p>\n

Your printer – in this example – still has port 25<\/strong> and (for instance) uit.telenet.be<\/strong> as outgoing mail server (yes, I’m Belgian – hence the .be TLD on my site)<\/em><\/p>\n

(PS : don’t want to read this entire story ? CTRL-F your way to “How do I set this thing up ?”)<\/h6>\n

Behind the scenes<\/h2>\n

What happened behind the scenes before and after your migration, concerning mail flow ?<\/p>\n

Before your migration<\/strong>,<\/h4>\n

you used to have and old-school mail provider that allowed a lot.
\nYour recipients didn’t care much or already added your scanned mails with PDF’s in them in their white<\/del> allow-list.
\nMaybe your mails got through, maybe they didn’t.<\/p>\n

Your outgoing mail provider (let’s say it’s Telenet nv<\/em> for the sake of the already mentioned example above) doesn’t really care what you send over their mail server, as long as you send it from an IP address on their network.<\/p>\n

(a small note : at the time of this writing Telenet no longer accepts anonymous port 25; they need authentication through an @telenet.be address and use port 587 with TLS encryption)
\n(another small sidenote : Proximus still allows anonymous port 25 at this time *cough*)<\/h6>\n

Whatever the case, it would allow senders to send any mail they want from any e-mail address they want, as long as they use their own internet provider’s mail address.<\/p>\n

After migrating to M365,<\/h4>\n

Microsoft kind of enforces you to add certain DNS records<\/a>, before 100% completing the setup wizard of their Online Exchange offer.
\n\u2705 green ticks tick my own boxes as well, so as an OCD-enjoying IT guy, I can’t not<\/em> complete this wizard :p<\/p>\n

One of these records you have to create is an SPF record, which partly regulates the mail flow for your domain by defining. (more on the SPF record on [this page]<\/a>)
\nMicrosoft is also kind enough to allow you to send over their own SMTP servers (good guy MS !!!) and provides certain regulations in order to be able to do so.<\/p>\n

Server\/Smart Host<\/strong>: smtp.office365.com
\nPort<\/strong>: 587
\nTLS\/Start TLS<\/strong>: Enabled
\nUsername\/Email address and password<\/strong>: pretty obvi what this is….<\/p>\n

In a perfect world, you’d be able to just enter these settings in your super-duper all-in-one printer and you’d be good to go. \ud83d\udc4c<\/p>\n

HOWEVER…<\/strong><\/p>\n

On the dreaded day of June 30, 2023 Microsoft disabled out-of-the-box support for a tiny little protocol we know as TLS<\/strong><\/em>.
\nSpecifically, they disabled support for TLS 1.0 and 1.1 (fear not).
\nA lot of these printers use this “older” protocol and – as you might already guess – this complicates the entire sending-of-mail process.<\/p>\n

\"\"<\/p>\n

Never fear, though !<\/p>\n

Microsoft built in a backdoor\/workaround in their own security enforcement and still allows you to send mails like you would in “days of olden”.<\/p>\n

 <\/p>\n

How do I set this thing up ?<\/h2>\n

We’ll take this random internet screenshot from the mail settings tab in an OKI printer as an example :<\/p>\n

\"\"<\/p>\n

Following all instructions you find on the internet, this would be the way to go.
\nAnd it is.<\/p>\n

Using these settings in 2024 will result in a “cannot send mail” error on the printer.<\/p>\n

Did you misconfigure something on this printer ?
\nNO.<\/p>\n

Here’s what you need to change on the Microsoft side :<\/p>\n