Implementing Sender Policy Framework (SPF) is another mechanism to authenticate your domain as a legitimate mail sender and that means lowering your SPAM score in antispam mechanisms.

It is done on the DNS server, by insrerting a TXT record on the base domain with the apropriate SPF data, such as:

v=spf1 a mx ip4:1.2.3.5 ip6:2b00:4200:1:2::5c mx:postman.mydomain.net -all

This is the SPF record of the server posman.mydomain.net. In plain words, it advises other mail servers that the given domain can be used for mx (mail relaying) activity from the given ipv4 and ipv6 addresses. Since there are no subnet masks, the default subnet is /32 for ipv4 and /128 for ipv6.
Kindly replace the server domain and the ipv4 and ipv6 addresses according to Your needs. If you don’t plan using ipv6 yet, just leave out the whone [ip6:xxxx:xxxx:x:x:xx] block.

For more details, there is a good explanation of the SPF records and mechanism here.

Ok, so what next? Does SPF advise the server that is receiving the mail what to do with it? Not at all. It will just lower (or rise) your SPAM score if the destination mail server has an antispam engine. I
If you really want to advise the destination mail server what to do with your mail, and mails that seem to come from your servers but are false, you’ll also have to create a DMARC record in the domain, which is decribed here, but before that you’ll need to implement digital signing of your relayed emails with OpenDKIM, decribed here.