cons:
(..)
If you set up your mail server correctly only a very few providers block you by default, but usually offer a way to whitelist your server. And MTAs which come with your OS might be not the best choice for an email server, since they often have all features enabled (-> security) and come with limited/strange/cumbersome configuration templates.
You *WILL* certainly need background on so called MX records....
reason why you **WILL** mostly need to run your DNS server...
A steep step but after that there is no coming back.
Once you have deployed the tools a couple times is piece of cake..
The existence of the domain name is orthogonal to hosting your own mail...
I would certainly advise that anyone that cares about their e-mail address own their domain name themselves, and not use a 'free' or otherwise 3rd-party domain. If your e-mail address is tied to a particular provider, so too are you. They may later change their terms, decide to sunset the service, go out of business etc. and then you will have a difficult decision to make. If you own the domain name yourself, you can easily move providers as you choose, without affecting your reachability, even if you don't self-host.
As far as hosting it yourself, there are some advantages, such as being able to investigate delivery failures yourself, and knowing that your e-mail isn't being mined or shared en masse with law enforcement without your consent, and flexibility to run scripts against your mail or whatever else you might want. For most people these days though I would suggest you just pay a nominal fee to have your mail hosted by a company that focuses on doing that. It isn't that hard to set up a properly secure mail server, but if you don't know what you're doing, and even if you do, it's a significant amount of effort to do it properly vs. paying Fastmail (which I heartily recommend) or similar $5/month. I host my own because I have the server for other reasons, and because of inertia after doing so for 20 years, but I would just pay someone if not for that.
@Ed.Kloonk The biggest advantage of using a mail host server is their secure socket connection. If you wanted to secure your own email server, you would need to buy or at least 'fake' your own server certificate. Another advantage is, not requiring DNS forwarding to your own 'domestic' IP address.
Return-Path: <messages@ncas.us-cert.gov>
Received: from mailer086149.service.govdelivery.com (mailer086149.service.govdelivery.com [69.5.86.149])
by <MYMAILSERVER> (8.15.2/8.15.2/Debian-8+deb9u1) with ESMTPS id 10DLGN08009920
(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO)
for <MYMAILACCOUNT>; Wed, 13 Jan 2021 21:16:30 GMT
Getting a free valid SSL certificate from LetsEncrypt has been trivial to do for several years. You don't need some other service provider to make use of their "secure socket connection". As it is the vast majority of email travels unencrypted, not touching an SSL socket at all (although that's getting better). Even when you do get a secured SMTP connection, 99% of the time the server at the remote end is using a bullshit self-signed certificate - including from organisations that ought to know better and use a proper traceable SSL certificate. Vis, email received from US CERT today:
Getting a free valid SSL certificate from LetsEncrypt has been trivial to do for several years. You don't need some other service provider to make use of their "secure socket connection". As it is the vast majority of email travels unencrypted, not touching an SSL socket at all (although that's getting better). Even when you do get a secured SMTP connection, 99% of the time the server at the remote end is using a bullshit self-signed certificate - including from organisations that ought to know better and use a proper traceable SSL certificate. Vis, email received from US CERT today:
On the mail platform I administer at least, of about 90,000 messages today, only about 6,000 were delivered to us unencrypted. The vast majority of mailboxes are on large mail providers that are all doing opportunistic TLS these days. Also, unless you explicitly configure your server to request them, client certificates won't be sent (to which almost all SMTP servers in the wild wouldn't have a certificate to send in answer), so you wouldn't expect an inbound connection to ever be verified, since certificates are typically only exchanged server -> client.
Received: from mail1.bemta25.messagelabs.com (mail1.bemta25.messagelabs.com [195.245.230.4])
by <MYMAILSERVER> (8.15.2/8.15.2/Debian-8) with ESMTPS id wA2FGSFq005671
(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=OK)
for <MYEMAILADDRESS>; Fri, 2 Nov 2018 15:16:30 GMT
Received: from mail-yb1-xb32.google.com (mail-yb1-xb32.google.com [IPv6:2607:f8b0:4864:20:0:0:0:b32])
by <MYMAILSERVER> (8.15.2/8.15.2/Debian-8) with ESMTPS id w9GCxl8X018260
(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=OK)
for <MYEMAILADDRESS>; Tue, 16 Oct 2018 13:59:49 +0100
Received: from smtpi.msn.com (ch1gmehub14.msn.com [207.46.200.24])
by <MYMAILSERVER> (8.15.2/8.15.2/Debian-8) with ESMTPS id 036J29w7020047
(version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA256 bits=128 verify=OK)
for <MYEMAILADDRESS>; Mon, 6 Apr 2020 20:02:12 +0100
Getting a verify=OK tells you that the remote server is indeed who it claims to be and that you're not getting MITMed and intrinsically means that the far end SMTP server (acting as client) had to present a certificate to my SMTP server to be verified. Opportunistic encryption with self-signed certificates, rather than CA signed certificates, tells you nothing. I could, if I wish, configure my server to always require a particular certificate, or a certificate with a particular root CA, for traffic from Messagelabs, Google, Microsoft (yes, it surprised me too) and the other handful of people who do this properly, and refuse connections if they appeared to be being MITMed, but it's really not worth the bother. I do have rules set up for some colleagues/partners who run TLS (strictly STARTLS) properly on their servers to require a correct certificate before accepting the connection (or more accurately, it's set up to reject the connection if it gets a hooky certificate).
If your e-mail address is tied to a particular provider, so too are you. They may later change their terms, decide to sunset the service, go out of business etc. and then you will have a difficult decision to make. If you own the domain name yourself, you can easily move providers as you choose, without affecting your reachability, even if you don't self-host.
...knowing that your e-mail isn't being mined or shared en masse with law enforcement without your consent
This is one of those things like...people squirreling all their data away in an external HDD in their closet (and/or a safe deposit box) because they don't trust Microsoft or AWS to keep their data safe. It's more work and in the majority of cases, ultimately still less secure. There's definitely an argument here when it comes to the fly-by-night or smaller providers. But the big behemoths that basically run the internet? They aren't just going to "go away." It's such a weird argument IMO. "What if they just shut it off for fun!" I dunno, what if Chinese hackers brick your closet server?
Getting a verify=OK tells you that the remote server is indeed who it claims to be and that you're not getting MITMed and intrinsically means that the far end SMTP server (acting as client) had to present a certificate to my SMTP server to be verified. Opportunistic encryption with self-signed certificates, rather than CA signed certificates, tells you nothing. I could, if I wish, configure my server to always require a particular certificate, or a certificate with a particular root CA, for traffic from Messagelabs, Google, Microsoft (yes, it surprised me too) and the other handful of people who do this properly, and refuse connections if they appeared to be being MITMed, but it's really not worth the bother. I do have rules set up for some colleagues/partners who run TLS (strictly STARTLS) properly on their servers to require a correct certificate before accepting the connection (or more accurately, it's set up to reject the connection if it gets a hooky certificate).
Even if you request them, all it tells you is whether or not the cert chains up to an authority you trust. But you don't really care about that with e-mail, since it is the sender and recipient addresses that you would care about verifying the SMTP server you are talking to has some sort of authority to handle, but there is no existing mechanism to do that. There is nothing stopping a spoofed server from presenting a valid, CA-signed certificate which you will accept, and a hypothetical MITM can just as easily forge SPF or PTR which you might propose using to try to validate the identity of the server against the sending domain. Server name doesn't appear to the user as part of the identity of the message, though, so it's kind of irrelevant whether its identity is established or not; it would be far easier to just use a different 'unprivileged' server name in your 'attack', which you can produce valid certificates for, and from the MUA side it will look effectively identical.
I wouldn't recommend to run a mail server at home if your internet access has dynamic IP addresses. Most mail servers verify the reverse mapping and many also block prefixes used for dynamic address pools, because they are the common source of bot generated SPAM. In that case your mail server could only receive email from the internet and needs a smarthost or mail relay for sending. Another solution would be a tunnel to a server with a fixed IP address.
You seem to know of SPF but apparently not DNSEC, which makes SPF or PTR forgery rather hard to successfully do and people together enough to deploy CA backed certificates are also together enough to inplement DNSSEC. You're effectively arguing against using STARTLS properly because it doesn't offer end-to-end authenticity guarantees between two users - which is true. You're ignoring defence in depth, which STARTLS is a useful part of. If you don't bother to use S/MIME or PGP, which most people don't, opportunistic encryption with a self-signed certificate offers a certain amount of probabilistic privacy protection and no authenticity protection worth mentioning. Using STARTLS with proper CA backed PKI rather than essentially meaningless self signed certificates offers more privacy and authenticity guarantees.
Yes, the CA backed PKI is only as trustworthy as the CA is, but I'll bet you regularly hand over financial information and more on the strength of a CA backed certificate verifying the authenticity of a web site. The guarantees of authenticity and privacy of server to server traffic over SMTP using CA backed certificates are exactly the same as those you get visiting a secure website over HTTPS, it's the same certificates, it's the same TLS protocol. In both cases you're better off with an encrypted channel over a plaintext one, and better off still with a pukka CA backed certificate over a self-signed one.