One additional (non-security) feature that this guide missed is a reverse PTR record for your server's IP address. You'll have to set this on the side where you get your IP address from rather than in your own DNS, but lacking it will get your email classified as spam even if you implement all the other protocols. Basically, when your mail server says "EHLO mail.chamaris.tld", the other side will try to validate that the IP address you're connecting from actually points to mail.chamaris.tld.
Furthermore, you need to pick a host that takes action when their IP addresses appear on blacklists. Microsoft, particularly, uses UCEPROTECT as a blacklist source, and that particular company will blacklist and entire ASN if they receive too much spam from a particular IP address block (that doesn't get resolved in time).
Glad you're pointing it out. I still have problems, indeed, having my emails flagged as spam when sent to outlook.com. On gmail.com they go straight to the inbox.
If I understand correctly though, I should have to set a reverse PTR record in the case of setting up my own mail server, right? And I should configure it on the mailserver's side, correct? That's not my case though, I'm just using a custom domain with the MX records pointing to the mail service that I'm using.
I'll just wait a few days cause the domain is new and I guess that's the reason outlook.com flags it.
> Microsoft, particularly, uses UCEPROTECT as a blacklist source, and that particular company will blacklist and entire ASN if they receive too much spam from a particular IP address block (that doesn't get resolved in time)
Exactly: a non-blacklisted IP with good reputation, correct mailname and valid PTR record is the foundation, ideally augmented with SPF. I've been running an e-mail service without DKIM and DMARC for many years without any delivery issues, only adding those very recently.