Getting our emails accepted

We want to ensure our emails gets delivered into inboxes rather than junk folders, without relying on recipients to actively whitelist our from address. The three protocols to implement are SPF, DKIM and DMARC. They allow recipient admins to check text records in our DNS and ensure email from our domain comply with commitments we make about them. Here I'll give examples of what the text records should look like, the format to use for them if your DNS server uses tinyDNS and the linux command to check the record is correct. You can glean the same lines in bind9 format from here

SPF
Since all mail should originate from the mydomain.com domain's server we can recommend that mail from ip address other than ours should be rejected.

v=spf1 ip4:x.x.x.x ip6:x:x:x:x::/64 -all

The line in tinyDNS format (\072 is the octal code for :) for this is and the command line check:-

'mydomain.com: v=spf1 ip4\072x.x.x.x ip6\072x\072x\072x\072x\072x\072x -all

dig mydomain.org TXT +short

DKIM


This technology allows recipient servers to check that email has not been altered in transit. The local mail exchanger encrypts the email with the private key - which is created as described for
exim4 - the corresponding public key is entered into the domain's DNS record from where it can be accessed by the receiving mail exchanger.

The first and last lines (starting -----BEGIN and -----END) and the carriage returns are removed from the public key; this linux command line will do it for you:-

awk 'NR>1{a[++k]=$0}END{for(i=1;i<k;i++){printf("%s", a[i])}; printf("\n")}' dkim-public.pem
So the text record should look something like this.
"v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCeUPRas5QlGku49gBF9edwR7hirzPgzHDT5uiS+2pjbtyh6qrk4CwquSRcyHpdWVPIyx1V32bmCsVAeGF56Zb+vHQlWzQY/Sl/viANHtTbN2zFm16FatkBTW+mFRmLkJpNANgqd/cSzZJzXmnyjdEYjGeLhToImSv+Bqok/KSbuQIDAQAB"

The domain must be of the form _domainkey.mydomain.com and the text record must start with a selector which can be anything - I use the date. The text record should be placed immediately after the SPF record.

So in tinyDNS format the record and the command line check (\040 is the octal representation of a space; some online record builders have \272 instead of \352):-

:201912._domainkey.mydomain.com:16:\352v=DKIM1;\040k=rsa;\040p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCeUPRas5QlGku49gBF9edwR7hirzPgzHDT5uiS+2pjbtyh6qrk4CwquSRcyHpdWVPIyx1V32bmCsVAeGF56Zb+vHQlWzQY/Sl/viANHtTbN2zFm16FatkBTW+mFRmLkJpNANgqd/cSzZJzXmnyjdEYjGeLhToImSv+Bqok/KSbuQIDAQAB:86400

dig 201912._domainkey.mydomain.com TXT +short

DMARC
DMARC was introduced to prevent a spammer spoofing mail from a domain that has a DKIM record simply by not including any DKIM signing, In effect, it ensures that there are satisfactory SPF and DKIM records if the domain's admin claims they should be present.

DMARC policy must be one of none, quarantine, reject and optionally there may be individual control of SPF and DKIM handling, either strict or relaxed.

It is also possible to request that implementing recipients send you a report in XML format, either as a digest or of individual failures. In the following example all of the last three fields could simply be ommitted

v=DMARC1; p=quarantine; adkim=s; aspf=s ; rua=mailto:eve@mydomain.com;

rua requests reports in a digest as oppossed to ruf (individual failure reports) and =s, which recommends strict checking,could be replaced with =r. I find the reports to be comparable to spam in annoyance and not useful. .

The domain must be of the form _dmarc.mydomain.com, so I sugest a record as below, with it's tinyDNS version and command line check:-

v=DMARC1; p=reject; adkim=s; aspf=s

'_dmarc.mydomain.com:v=DMARC1; p=reject; adkim=s; aspf=s

dig _dmarc.mydomain.com TXT +short

Testing

There are a number of sites online that will help you check your settings, but the best test in my opinion is an email to a gmail account. This is particularly relevant with DKIM as online checks can only tell you if the DNS is correct and do not check that the mail exchanger is correctly hashing and encrypting the messages it sends. Select the message (hopefully in the inbox!) and click Show original from the More menu to the right.