SMTP Settings to enable other app (Acronis TI) to send email via M365

[Mike_Stanley_MASCS]

Hi all,

I have recently moved from M365 Personal to Business.  I also use Acronis True Image which needs the following SMTP settings to send notifications by email:

Server settings:

Outgoing mail server (SMTP) name

Port

Encryption 

SMTP authorisation:

Username and password

Optional - Log on to incoming mail server:

POP3 server and Port

I have found various (conflicting) settings on the web (including adding Authenticated SMTP in the M365 Mail settings for the user)  but none work.

Can anyone help?

[#2]

Port: The port number is the communication endpoint on the server. For secure SMTP connections (using TLS/SSL), the standard port is 587.
Encryption: Encryption ensures that your email communication is secure. For Microsoft 365, TLS (Transport Layer Security) encryption is commonly used.

[#3 · Accepted solution]

Thanks but I have just discovered that it isn't actually possible at present. It seems that "Microsoft is stopping the Basic Authentication for Microsoft 365" per Acronis Development team who say they are planning to support specifying any SMTP server to send emails in the future.

[#4]

@Mike_Stanley_MASCS 

SMTP still working but POP:

https://learn.microsoft.com/en-us/exchange/clients-and-mobile-in-exchange-online/deprecation-of-basi...

[#5]

I work mainly with M365 Enterprise but hopefully at least some of the following is also applicable to M365 Business.

If you are sending only to email addresses in your domain and if your Internet service provider (ISP) does not block outgoing port 25 (most business-class ISPs allow it by default or upon request), then you should be able to use the same SMTP server that's configured in your MX record. You would use port 25 and no authentication. It would be like any other email server on the Internet except for the following accomodations:

• If the From address also uses your domain, you will need to do one or more of the folllowing:
  • Add an exception to allow spoofing that address from your IP address.
  • If M365 Business allows it, configure a connector for it in Exchange Online, which you probably want to do anyway to ensure TLS is enforced. To prevent others from using it to spam or phish you, limit connection to it by, for exqmple, allowing only your IP address.
  • Create a mail flow rule to have those emails bypass spam filtering. I recommend multiple conditions such as the sender's From address, a unique header that Acronis TI might include in the email, or the hostname of the sending conputer if it's included in the headers. If you use the Outlook app for your M365 email, the Outlook add-in Message Header Analyzer by Stephen Griffin makes it easy to view the headers. You can also see the Internet headers by look8ng at the Properties of the email.
• If the From address does not use your domain, you will likely need to have it bypass spam filtering.

If you plan on configuring other apps or devices in the future to send emails to yourself, you may want to set up a local SMTP relay to relay emails to M365. Allow it to send emails to the Internet/M365 but otherwise make sure to not allow any incoming connections to it from the Internet; you do not want to accidentally set up a public open relay. Low volume SMTP relaying is very light on resources so the server can be set up using an old computer or in a virtual machine. You can use Windows Server and IIS's SMTP server or, if licensing costs are an issue, use Linux with an open source email server.

[#6]

Thank you. I have been able to make this work with the address from the MX record and Port 25 as you suggested.
Initially emails were not being delivered, and were shown in the message trace as "Resolved" rather than "Delivered" - unsure what this is trying to tell me! However, I created a rule to forward any messages with the "Acronis True Image notification" in the subject to my email address even through that was where they were already address to and this seems to work. I'm not sure why but I suppose I should be happy with that! Thank you for your help.

[#7]

I have one small point remaining. Emails are arriving correctly but are flagged (i) We could not verify the identity of the sender. I have to change the settings to make M365 recognise these emails as OK but with no success. Not a huge problem but if you can suggest anything I would be appreciative.

[#8]

@Mike_Stanley_MASCS It says that because it can’t verify SPF, DKIM, and/or DMARC. If the From address uses your domain name and you have an SPF record configured in DNS for your domain, you can add the external sending IP address(es) to your SPF record. Just keep in mind that you will need to update your SPF record if the IP address ever changes.

If you don’t have an SPF record or can’t update it, you may be able to update the spoofing configuration in Microsoft 365, but I haven’t had to do that myself in some time so am not sure what steps are involved. You can also try adding the From address to your Safe Senders list in Outlook but, if I recall correctly, it probably won’t help.

[#9]

Thanks. TBH I'm straying a bit beyond my technical knowledge. In your first para are you referring to settings at my ISP where I set up the DNS settings or within M365? Wherever this is to be set there won't be an issue with the senders IP addresses as that is fixed.
What I have done is add the senders email address for these emails in "Anti-spam inbound policy - Allowed and blocked senders and domains - Manage allowed senders" but that hasn't made any difference. Is that what you are referring to?

[#10]

I would try either updating your SPF record or updating Microsoft 365 first. If updating just one of them doesn't work, then update the other as well. Keep in mind that DNS and Microsoft 365 changes may take up to 24 hours to take effect, although typically a couple hours is enough.

In my first paragraph, I'm referring to the SPF record that should be set in DNS for your domain. Usually, the DNS name servers for a domain are set by your domain registrar (e.g., GoDaddy) to their DNS servers. The SPF record is a TXT apex record. (An apex record is at the root of your domain. DNS editing interfaces usually use @ for the hostname to denote apex records.) If Microsoft 365 is your only email provider, the SPF record is normally set to "v=spf1 include:spf.protection.outlook.com -all". Assuming your sending IP address is an IPv4 address, you would add ip4:x.x.x.x to your SPF record somewhere between the v=spf1 and the all. For example, if your IP address is 198.51.100.65, you could update your SPF record to "v=spf1 include:spf.protection.outlook.com ip4:198.51.100.65 -all". If you have a range of IPv4 addresses that the email can come from, you would enter the range in (classless) CIDR notation. For example, if the address range is 198.51.100.65 to 198.51.100.70 with a subnet mask of 255.255.255.248, that would have 29 mask bits and the SPF record could be updated to "v=spf1 include:spf.protection.outlook.com ip4:198.51.100.64/29 -all". Keep the range as small as possible. Using the same example, if the email can only come from 198.51.100.65 or 198.51.100.66 (e.g., the machines running Acronis True Image use only those two external IPs for NAT and the other IP addresses assigned to you are unused or used for other purposes), you could set your SPF record to "v=spf1 include:spf.protection.outlook.com ip4:198.51.100.64/30 -all". If the emails come from more than one IP address and they are not in the same subnet, enter them separately. Example: "v=spf1 include:spf.protection.outlook.com ip4:198.51.100.65 ip4:203.0.113.36 -all".

A few pointers for updating your SPF record:

• Some DNS providers have you enter the quotes (") at the beginning and end while others don't.
• The SPF record always starts with v=spf1 and ends with all.
• Be sure to keep the symbol before the all the same as it was (e.g., -all, ~all).
• The SPF record can be longer than 255 characters but each string must be 255 characters or less. You shouldn't run into this but, if you do, your DNS provider should have instructions on how to enter multiple strings in one TXT record. The tools below check the line length and will warn you if too long.
• After updating your SPF record, verify it with an online tool such as MxToolBox's SPF Record Lookup or dmarcian's SPF Surveyor.

As for allowing the email address in Microsoft 365, you can leave the email address in the Anti-spam inbound policy but, as of September 2022, emails from senders in the allow list that are from your domain must pass email authentication checks (SPF, DKIM, and/or DMARC). Updating your SPF record may be enough but, if it's not, or if you don't want to update your SPF record, add the email address and IP address to the Tenant Allow/Block Lists page. On that page, go to the Spoofed senders tab and add a new entry as follows:

• In the Add domain pairs box, add the sending email address and IP address formatted like AcronisTrueImage@yourdomain.com, 198.51.100.65. If there is more than one IP address, enter a block of IP addresses in CIDR notation like AcronisTrueImage@yourdomain.com, 198.51.100.64/30, or, if they are not in the same subnet, add multiple lines.
• Set Spoof type to Internal (assuming the email address uses your domain).
• Set Action to Allow.

Remember to update SPF and/or the Tenant Allow/Block Lists page if your sending IP address(es) ever change or the emails stop being sent (e.g., you switch to a different backup product).

[#11]

Thank you for such detailed information. I had made many of these settings already other than those in your last paragraph. Strangely they had no effect at first, hence my reply on 28th April and that was the case until 6th May when (without me having made any further changes) the issue disappeared! It almost seems as through M365 has "learnt" that these emails are alright, whether or not that makes any sense!
Anyway it's now sorted but I will save your suggestions for future reference.
Thank you for your interest and assistance.