If what you mention does turn out to be an issue, or you decide it's a worthwhile tradeoff to not have to care about IP reputation, you can choose to route all or a subset (depending on destination domain) of your outgoing mail through a provider like mailroute/mailgun/sendgrid/fastmail/posteo. Or even gmail/AWS. You can still self-host the rest even if you don't want to hother with outgoing SMTP, which you can always add later should uou choose to.
> If you stay on top of all the best-practices for running your own mail server, your hidden cost is the mind-share that that takes.
Are you actually speaking from experience here? Over the past 20-30 years it's been like, what, 4-5 new things to learn?
This even works if you want a mostly-free setup: you have MX forwarding via some provider (Cloudflare, your registrar, etc) going to a personal address, and SES operates as your outbound SPF that works with Outlook/Gmail in terms of allowing you to set your domain email(s) as aliases within their interface.
Im sure just running Mail in a Box on linode would 100% flag it.
I KNOW google would because half the time i socks through one of my linodes (that i have used and owned the IP for years on) i get thrown through all sorts of captchas on services. INCLUDING signing into my own gsuite from it (despite an established history of just doing it).
Unfortunately the big players own mail, they do what they want. In fact having a domain registered with one will do better for your mail reputation than most would care to admit.
Just look at how MS uses SMTPS on port 25, sure they COULD use 587 or 465, but they dont:
https://docs.microsoft.com/en-us/exchange/mail-flow-best-pra...
I'm not rejecting the concern or the ambiguous worry about arbitrary judgement, but the surveillance web's captchas are much more draconian than spam filters.
But having managed email across all three providers. Microsoft does just ignore rfc’s and basic standards pretty regularly and relies heavily on “AI”.
Google less so.
And when it works it works great. But once you get deliverability issues it’s a pain to resolve with them. Especially if you have to engage support.
If i'm running an email inbox, responding to support regarding email deliverability is my lowest priority primarily because, if I respond once, it becomes an attack vector for dedicated spammers to try to extract information about the spam detection systems.
Frankly you are more likely to make exceptions and monitor internally for deliverability from a google, or outlook.com or comcast.net than for some random xyz.email domain.
And blocking swaths of those has a bigger impact. Frankly though, imho, you should respond to users that report deliverability issues on your domain and tweak your spam filters accordingly. Just ignoring a users saying "i am not getting expected emails from this listserve" is a great way to encourage your users to employ shadow IT and just use personal accounts.
Obscurity isnt security, even with spam mitigations. Things like SPF, DKIM, DMARC along with some user impersonation filtering (including spoofing from fields) is basic spam 101 and will catch 99% of your actual security related phishing.And the largest ones (dmarc) can be probed publicly anyhow since almost all of it relies on DNS txt records.