Your MTA should announce itself and DNS should agree. So your MTA says: HELO smtp.example.co.uk
smtp.example.co.uk will resolve to an A record (say a.b.c.d) and a reverse lookup will also work:
d.c.b.a.in-addr.arpa PTR smtp.example.co.uk.
Remember this is all about reputation, so if you also DNSSEC sign example.co.uk, then you will look like you care about your domain reputation.
Then do SPF, DKIM and DMARC. Note how the example for SPF stops at ~all and not -all. The rest is also superficial.
Anyway, I run email systems that do the job properly and it is not trivial and certainly not formulaic. There is no shortcut to getting an IP address/range trusted.
The advice on that page is ... good as far as it goes but woefully inadequate for running an email system. It's a good start.
Don’t waste your time.
The reason for my comment is that we, the readers, are most likely gonna spend more time reading this post than the author(s) did writing it.
I'd like to add the following, which I continually reference and has led to repeatable success:
https://www.linuxbabe.com/mail-server/setting-up-dkim-and-sp...
And as far as confirming it works, I continually rely on sending to a gmail address.
Under the three dots is "view original" which gives you
SPF, DKIM, and DMARC results.
(edit:formatting)
Main domain has SPF set up correctly as per MS docs.
We have the CNAME set up for a like em1234 sub-domain as per SendGrid’s docs which their docs say should cover SPF even if the emails we send have a from address of our main domain (eg noreply@example.com), this is apparently because receiving servers are supposed to do SPF checks against the replyTo address which sendgrid does populate with an address on the subdomain.
This has worked fine for years, Gmail for example is happy and looking at mails from us says everything passes.
However, we recently onboarded a large corporate whose server was blocking the SendGrid emails because it was checking the SPF against the from header rather than the replyTo.
Only way to let the email through was to either add SendGrid SPF records to our main domain, or change the from address of the SendGrid emails, neither of which was 100% ideal.
Not going to try tell the client they’ve configured their server wrong, but have they?
You say that like its a problem.. its a formidable solution!
Has worked for me for many years now: Just fail2ban-style block (groups of) relays that attempt to send an unsubscribe-link destined for a mailbox that never ever subscribes to anything. Those malicious-compliance folks add these unsubscribe links everywhere because they determined that its a cheap method for reducing blocks. That makes them reliably stand out whenever they hit strictly human-to-human mailboxes that simply never have any reason to "unsubscribe". Its like a honeypot, and all it took was a strict policy about what a tiny fraction of mailboxes can and cannot be used for.