First, a little heads-up about the symptoms first. Fore some time, any outgoing mail to gmail.com addresses almost instantly resulted in a returned Delivery Failure Report-mail from Gmail with Permanent Error 550 5.7.26.

Obviously something was wrong with my mail setup, at least according to the latest Google-requirements.

It took a while before I got a hint that "I had to SPF-enable" the mail server. Unfortunately not many of the responses on Internet pointed in that direction when searching for Permanent Error 550 5.7.26, and it was first today I understood that the SPF-is actually set on my DNS!

Outgoing SPF records - in DNS

This means that I have one SPF record on my DNS, which will ensure that all outgoing mail coming from my domain vcode.no, actually is allowed to send mail.

In other words, when GMail receives an e-mail from bob@vcode.no, which of course resolves to an IP address of my domain, GMail checks the DNS setup to see if bob@vcode.no is allowed to send mail in the first place. If the DNS doesn't contain a valid SPF-record, then the mail is most probably a spam-mail !!!!

So, over to my ISP and configuration of the upcoming SPF record. That was pretty easy, since my ISP graciously has added a "Add SPF record", as marked with 1 below.

Clicking on the "Add SPF record", automatically added the TXT-record marked by 2 above. Note the a:www.vcode.no", that will automatically resolve to the read IP address. Cool!

There are several test-services out there, such as https://www.dmarcanalyzer.com/spf/checker/. Checking my vcode.no domain, I got this report indicating success:

Add the DMARC-record too

Just as the SPF-record in DNS is important, so are the DMARC-record. Below you see my DMARC-record for vcode.no:

Note that the sub-domain _dmarc has to be part of the record. Just as for the SPF-record, the type is TXT. The value is along these lines:

v=DMARC1; p=quarantine; rua=mailto:dmarc_aggregate_reports@vcode.no; ruf=mailto:dmarc_failure_report@vcode.no;

In essence, the DMARC-record tells the receiving mail servers how you want to deal with records failing the checks and where to send the reports. Just as for the SPF-check, several DMARC-record checkers exists, and the MimeCast-folks have one here: https://www.dmarcanalyzer.com/dmarc/dmarc-record-check/

It will retrieve the DMARC-record from the DNS and tell you what is eight and what is wrong.

Inbound SPF-checking

A completely other thing, is to check inbound mails for correct SPF-configuration. In other words, do the very same thing as GMail do with my outgoing mails to gmail.com.

Domino-servers easier than version 12.0.2 does not have this capability built in, meaning that older Domino-shops must do other tricks with proxy SMTP servers with SPF-abilities, work as a man-in-the-middle between the backend Domino mail server and the outside world. Search for stuff like Postfix and OpenDKIM for further reading.
You can also read more about HCL Domino 12.0.2 and how to enable SPF from Daniel Nasheds wonderful Domino-blog here.

At the time of writing I test out another tool called Positive Identity from Maysoft.com. By installing a Domino Extension Add-in to your Domino mail-server, which is very easy and automatically done for you, by the installer database provided by Maysoft, you end up with full SPF, DKIM and DMARC checks of any incoming mail to your server. Looking very good at the moment!

Hopefully this makes my Domino mail server somewhat more compliant for the time being. Good luck!