I have my own domain since when I was about 15 years old and used that for a while on a digital ocean droplets. It's incredibly easy to set-up.
The only issue I had was that other people were not getting my mail and I sometimes it was not even reaching their spam folders. Probably because Google/Microsoft were blocking that IP range of Digital Oceans.
Nowadays I just pay for a personal Gsuite license and use Google Infrastructure.
Much simpler that way and I'm almost guaranteed that my mail will reach the recipients. You only need to set-up your DMARC / SPF records and point your MX records to the ones that Google provides.
If you put an address or domain in the safesenders list; they do literally nothing. Like you can just totally spoof the domain entirely.
However if you use transport rules as per their rec, there’s all sorts of stuff that will still get flagged, and you have to to reference ATP, anti-phishing, anti-spam policies. Much of which aren’t even in the Exchange admin panel, rather they are in “security” and buried in hamburger menus galore.
And what’s best. They don’t even have any documentation for how these modules interact or what order mail is processed in. I had a case open for months thst finally got escalated to someone that was able to explain the issues we had with specific list serves/domains getting flagged.
In the end my only option was to whitelist emails classes as phishing and route them to junk rather than keeping them in quarantine. Even though it was a 99% accuracy rate sans this single domain.
The guy was really only able to commiserate with me. We are but a number and not a big enough one to get Ms to change a thing. Their best recommendation was to deploy an edge device like proofpoint/proofpoint hosted and just handle it from there.
I get what they want to do. They are trying to make the crazy email RFCs easy for devops guys thst don’t give a damn about how e-mail works. But it’s still hard to keep up with as they constantly just move stuff around and change their own standards on a near monthly basis.
So even if its not listed on the domains MX record but you can suss out they are an office365 tenant receiving mail, you may be able to relay off it and spoof to high heavens (especially if the edge device reccomends you....ahem...whitelist your own domain and not use transport rules). In fact especially if you can do this.
For example i think MS forced proofpoint to change their config recommendations as an outcome.[1]
from the page on [1]:
"Due to major complaints, Proofpoint has opted to change change to the format of ensuring Proofpoint mail is not scored via the O365 system. This rule will allow external email to come in still, but will follow O365 scoring. This is to ensure no mail is lost."
[1] https://web.archive.org/web/20200807173336/https://help.proo...
It gives me all the flexibility I need with almost no work or maintenance.
There are enough mail providers that I could easily switch to that I don’t need a piece of software. Switching from gmail to yahoo, proton, apple, outlook, or juno is a simple domain adjustment and has me back receiving mail within the TTL period.
My understanding is that SPF makes forwarding like this no longer possible if the original sender's address is to be preserved.
Forwarding, on the other hand, made it possible to do a simple redirect of one address to another (eg. ~/.forward) but strict SPF rules will deny the forwarder as a valid source for the mails.
The goal is to get my personal domain to be my email domain for exactly this reason.
For my soon-to-be-born son, I'm registering him a personal domain immediately, and I'll turn it over to him when he's old enough to have email - save him some trouble.
I could go through the process again (not fun) with some ridiculously long .com/.net or other OG tld which are probably somewhat more resistant to rent seeking practices like this or I just suck it up and hope it remains pricey but not egregious.
EDIT: .ca is not particularly tech community related, but that doesn’t matter to me.
One thing I’m not sure of is what happens if I want to switch registrars in that time—will the full 10 years of ownership transfer to the new registrar?
If you switch registrars, your domain validity continues as before. Your registration information is with the registry for your TLD, not with the registrar alone. So your 10 years of (future) ownership will carry over. Two caveats to note. The first is that you can’t transfer a domain within 60 days of purchase or renewal. The second that I’ve seen is that a transfer to another registrar requires a one year renewal for the domain. So I’m guessing you may not be able to transfer a domain that’s already at 10 years (even taking into account 60 days after the renewal to keep it at 10 years). But if your domain is at nine years, you’d surely be able to transfer, and it would become 10 years at the time of transfer.
The expiry date never changes through all these actions.
This would be something that provides in a single package an SMTP server, an IMAP and POP server, pre-trained spam filtering, and maybe a web server with a web-based email client, and a simple setup program that asks a few basic questions such as your domain name and configures everything on your end and provides help for configuring things elsewhere (such as with DNS, such as telling you what to put in your SPF and DKIM and DMARC records).
This is meant as something to handle your mail during the time it takes you to find another provider. It is meant to be something you can quickly install on a VM somewhere, point your MX record at it, get a Let's Encrypt or similar certificate for it, and not be losing mail while you are between providers.
It should have a quick start guide that includes details on signing up and getting a Linux VM up at major inexpensive VM hosting places. Amazon Lightsail, Hetzner, and such.
It should make minimal assumptions about your Linux environment. Probably it should not use the SMTP, POP, and IMAP servers that are packaged by your Linux distributor. It should use minimal servers that are written specifically for the emergency mail kit.
[1] https://en.wikipedia.org/wiki/Survival_kit