Email deliverability to Microsoft email servers
-
OK, sending emails to anyone that has a Microsoft business email service is becoming a real problem.
I'm just getting instant bounce-backs from anyone with a Microsoft business email server, and straight to Junk on @hotmail.com and @outlook.com servers.
Sending domain is 6 months old. Emails have been active and sending for months. Works fine to other non Microsoft/Google email servers.
SPF and DMARC all correct and passing all mxtools.com tests, with no blacklistings.
Only thing I can think to try now, because life will be 100 times easier if I can have this working all from a Cloudron server, without relays, is that the server it is on has a different domain from the sending domains.
Server: mail.example.com
Email sending from mailbox@clientdomain.com.
Part of me thinking to just move the client to a separate Cloudron instance to make the sendmail domain and email domain match. Migration time hassle, but if that works, at least there is a solution.
Having wasted so much time on researching options to solve, I've not had time to test, but does anyone know if when using a mail relay, that Cloudron retains a copy of the email send in the IMAP folder?
I'm reluctant to be forced to use a Google Workplace or Microsoft 365 account just to achieve email deliverability for every new domain, but it seems that is what they are trying to force by creating these issues for those not paying with time and money for their delivery and monitoring protection racket.
Anyone having any better luck with this?
-
It's a real pain, no matter if we are talking about gmail.com, outlook.com, ms365, gmx,... Worst is t-online, who blocks everything by default and requires manual white-listing.
Did you go through the process at https://sender.office.com/ ?
-
I have so many issues sending emails with MS domains too... It's a real pain.
The above link doesn't work for me, it's says my IP is fine and redirect to olcsupport.office.com
I got my IP whitelisted using that form several times before but every few months it starts getting blocked again.
-
Not sure on this one.
I guess I'd probably recommend relays (I know you said you don't want them, but...) as they are generally pretty cheap unless your client sends a ton of email. SES right now is $0.10/1000 emails + $0.12/GB for attachments. Which unless you are sending ridiculous amounts of email, will look like $1-2 a month probably. SES does get on a Spam Blacklist very occasionally, but it's on the lowest possible level (Reputation 99 rather than 100), so generally it does not effect deliverability.
When I've done non-relayed, things have generally been fine too though, at least with Gmail. And I was sending from a server host which has a poor reputation. However, the email volume was pretty low. Have not tried Hotmail yet... so will have to try it at some point.
-
@nichu42 They always say forward the bounce to delist@microsoft.com, which then bounces!
Just determined to solve this without being forced to use Google or Microsoft.
The harder they make it, the more valuable it is to find an alternative solution, as I just can't accept that there's only two companies in the world that will give deliverable sendmail for a new domain.
It's not a .com, .net, etc, either. SO I feel more obscure domains are also much harder to get accepted by their royal gatekeeping shenanigans.
-
@michaelpope It really isn't for volume sending, just a few dozen normal communications emails per day. Cost doesn't bother me, it's avoiding complexity, and a matter of principle now.
I hear on the X.com vine that even Zoho is having more deliverability issues now, as the screws tighten.
I've never had issues like this in the past. Gone over all the usual checks, and everything is perfectly setup and no blacklists.
Part of me is wondering if faking email headers to look like they are sent from an Exchange server would solve
I'll keep digging, and report back once solved. It's man vs universe now on this one.
Keep the ideas coming, I've an open mind on this one, but have to solve it now, as it wastes so much time not having reliable delivery for just mundane business emails.
Web Design https://www.evergreen.je
Development https://brandlight.org
Life https://marcusquinn.com -
Every now and again I have this issue too and it's always with M$ owned domains (outlook, hotmail, live).
In the past I've tried jumping through the various hoops at places like https://sendersupport.olc.protection.outlook.com/pm/troubleshooting.aspx generally all to no avail.
Most recently I've received emails bounces that look like this:
Intended Recipients: <>
somone@hotmail.com Failure Reason: Error: 550 5.7.1 Unfortunately, messages from [89.58.52.168] weren't sent. Please contact your Internet service provider since part of their network is on our block list (S3150). You can also refer your provider to . [DB3EUR04FT039.eop-eur04.prod.protection.outlook.com 2023-03-21T21:59:11.453Z 08DB29C1C7D2FFBB]
http://mail.live.com/mail/troubleshooting.aspx#errorsThe only thing that has ever worked for me (that is, until it happens again) is asking my VPS provider (in this case it was Netcup) to resolve the issue. They then ask some standard questions like this:
I will be happy to pass on your request to the relevant department in order to apply for delisting from the relevant provider. But first we need from you:
- your explicit confirmation that you do not send mass mails (this includes newsletters)
- a list of the sender domains
Please also check that the mail server settings are correct and the DNS records are set correctly. Otherwise, our efforts may be protracted or lead to a negative result.
And I then reply with my answers and then they contact M$ and M$ sorts it out. Until it happens again.
-
@jdaviescoates Yeah, that's the issue! I really want a permanent solution. Still researching.
In the meantime, have hooked up https://warmupinbox.com. So far it's showing 100% delivery and no spam, so it is all a mystery!
Web Design https://www.evergreen.je
Development https://brandlight.org
Life https://marcusquinn.com -
@marcusquinn said in Email deliverability to Microsoft email servers:
a permanent solution.
I think perhaps only a reputable relay like Postmark would do the job
(and even then, perhaps not)Either that or somehow obtaining a very large range of IP addresses which you can somehow ensure and totally clean and reputable.
I think the issue (as alluded to in the bounce email example I pasted above) is that "part of their network is on our block list" - and it's basically impossible to control the whole VPS provider' network - especially on the good value ones, someone somewhere is going to be spamming.
So not sure there is really a good permanent self hosting solution. Unless maybe people sell guaranteed clean IP ranges and you buy those and also colocate you're own physical machine in a highly reputable data centre or something
-
@jdaviescoates Yeah. Frustrating AF! Why can't we just have nice things and manage our own small corners of the internet any more?!?
-
I was just reading these:
https://postmarkapp.com/guides/how-to-improve-domain-reputation-for-better-email-deliverability
https://postmarkapp.com/dedicated-ips
https://postmarkapp.com/guides/dedicated-vs-shared-ips-for-email-when-to-use-each#what-to-know-about-shared-ip-addressesIt sounds like a "pristine shared IP pool will have the best results". But how to achieve/ do that when self-hosting and not using a relay?
-
@jdaviescoates For now, for this client, I'm just moving everything to Namecheap's Private Email Ultimate package. Will see how that does, build the reputation for the domain and emails with their premium servers and IP monitoring, and maybe migrate again later once I'm more confident that I can pivot around more easily.
Not ideal, but still better value and independence from Google / Microsoft. Going to keep researching this, so will share any findings here. Thanks all for your contributions, I love having a team of virtual system admins to bounce off, wouldn't get this much collaboration in many enterprises
-
@jdaviescoates A relay option I've been happy in the past with is Elastic Email. They do also offer dedicated IP addresses, but as others here say, you can get caught out with being a part of an IP range being relegated.
This is a very valuable area for business privacy, so definitely going to keep researching and testing solutions.
-
@jdaviescoates Interesting. Perhaps the issue is so few emails being sent from these Cloudron VPS dedicated IP addresses!
Web Design https://www.evergreen.je
Development https://brandlight.org
Life https://marcusquinn.com -
@here I've not used mail relays with a Cloudron email service setup before (only used them for email newsletter sending).
Anyone know if the sent mail is still stored on the IMAP server before it's sent to the relay to deliver?
Web Design https://www.evergreen.je
Development https://brandlight.org
Life https://marcusquinn.com -
Yeah, email now sending with no Microsoft bounce-backs, using Namecheap, so at least there's one reasonable option for others having issues to consider as an alternative to using Cloudron email services.
I do think I'll move this one back at some point, but going to test email relay on another domain, first.
It might just be that having a dedicated IP and low email volumes is just not going to achieve the same email deliverability as these services with shared IPs, as long as they are managing their IP reputation across all clients.
Let's see. Keep sharing the knowledge, we move a lot faster with many more R&D testing opportunities as a community!
-
@marcusquinn said in Email deliverability to Microsoft email servers:
Anyone know if the sent mail is still stored on the IMAP server before it's sent to the relay to deliver?
OK, thinking this through Sent email is being stored from the email client to the server using IMAP, and SMTP to Cloudron credentials then either sends it directly from the server IP, or relays, to whichever relay is setup.
I think the knowledge base here could do with something to explain that Sent emails will still be stored before relaying, here:
From what the relay options being compared, it seems that Elastic Email might remain my preferred for bang for bucks. It's pretty difficult to maintain decent online review ratings in an angry world, but these seem to be reassuring:
-
Found this very useful!
@girish @nebulon Recommend adding this mail-tester.com link to the support documents, and any email canned responses on deliverability, should help a lot for self-diagnosis, and I've now got 10/10 deliverability scores on all my Cloudrons from the couple of things I spotted from using this.
I still think more obscure domain extensions are going to take a while from new to be trusted.
I also found this free mail warmup tool, that will send and check 5 emails a day for deliverability, so it's worth anyone having issues with that to setup a separate email box on their Cloudron, just for having this continuous sending flow from their domain to increase the trust ranking of their server's dedicated IP address.
For higher volume sending, this one is the cheapest of the bunch that does the job for me:
Right, think that's a long thread and research but with some useful conclusions for me, and to share. My work here is done for the day (4:30am), the life of system admin, eh!
-
I worked at a company before who offered transactional email services for business customers (we‘re talking like 1-2 million mails per day, e.g. banks that send out notifications or password reset links etc.). Believe me, email reputation was a 24/7 job.
I would, therefore, rather rely on a pro for relaying email and keeping reputation.
And I don’t blame it so much on Microsoft/Google but all these little a**holes who sign up a VPS and start sending their shit. You just can’t have nice things anymore…. -
@necrevistonnezr Yeah, I learned a few things from the research, so it was a bit of commentary on that to see what other experience and successes we might find.
I think I misunderstood how the relaying was implemented, now I know that, and a couple of other things, much happier that there are solutions for all occasions. Hopefully some tips to hep others here, and additions to the documentation should help, too.
