The email authentication technologies we’re about to implement are, according to the authentication authorities, all you need to be regarded as being from your domain when you send email, and someone else not being from your domain. Effect: your emails can be considered trustworthy by email receivers who use these technologies. If they don’t use these technologies, they can’t tell.
At the very least, Google will be less likely to think your email is spam.
PTR record
A PTR record can be obtained from your host’s nameserver – it’s a reverse DNS record for your IP address. If the PTR record points at ec2-23-65-53-221.ap-southeast-2.compute.amazonaws.com rather than example.com (your domain), and you’re claiming to be sending mail from example.com, what’s the email recipient meant to think?
host 23.65.53.221
will tell you what the host for that IP is. Lodge a ticket with your hosting provider and get that PTR record changed to example.com. This might take about a day.
SPF record
Create a Sender Policy Framework record on your nameserver:
TXT @ "v=spf1 a mx -all"
This says “for my domain, I will only send email from IP addresses listed on the nameserver”. Nameserver changes take time to propagate.
After your nameserver changes have propagated, you can go to https://dmarcian.com/spf-survey/ to check out if you got it right.
DKIM
DomainKeys Identified Mail is where things get more involved. We’re doing this on a Debian Linux, like Ubuntu for exim4. We’re making our signing key 2048 bits, which is long enough to make life slightly unpleasant for us. Fortunately for you I’ve written a bash script that outputs the TXT record we need to create on the nameserver – because some nameservers (I’m looking at you, Gandi) can’t hold “long” strings – it’s broken into “small” strings:
sudo apt install openssl cd /etc/exim4 sudo openssl genrsa -out dkim.private 2048 sudo openssl rsa -in dkim.private -out dkim.public -pubout -outform PEM echo $(echo $(date -u +%Y%m%d && echo '.domainkey.example.com') | sed -e 's/[ ]//g' && echo $(echo ' TXT "v=DKIM1; p="' && echo $(grep 'PUBLIC KEY' -v dkim.public) | sed -e 's/[ ]//g' | fold -w200 | sed -e 's/\(.*\)/"\1"/g'))
which gives something like
20170419._domainkey TXT “v=DKIM1; p=” “MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvCNqU0Njd4YQ4e89T3FNc+uyOS2JwUqynGk7uwcSYHjIE2MGRuTxi56s4JgPKSnCVlBkJlUnXQHXFp2UGnLm8SADtjRMfWwpNxz6TmzXBpMnNZV1zvuoBBdcxh0Qg1TtCSACtWM6ehml0BmOHVA8Ippqj9iRlP2HMjuVMxZXewN9eJl”
“c6zsyOwQPvVKpJ+Rdvr+pPkDztAVTw7mNSeyy+TL6O/3L9sl7A19Yx8jLHKuGUh9LutVuv1VP16e7GwlnA3Zqn5C1jyY5Qvr2SEHZMcE3VzD7XKZtZWbpkGh+A5S15NrOH4k9tbVfNbjft6Y1jUJRTT+4DD0ZEVlr4zO+WQIDAQAB”
That all goes into one nameserver TXT record, spaces and all. The world will join up the ” ” and get one big string. Note the bold number up there? That’s the selector. That a number needs to get larger with each new key. Periodically you’re going to have to reissue your key because security. You know what gets larger as time goes by? The date. Use the date. If you screw up, use tomorrow’s date, etc.
Once you’ve got our public key out to the public via our public nameserver, we need to get exim to sign the payloads:
sudo nano conf.d/main/01_exim4-config_listmacrosdefs
After the line CONFDIR = /etc/exim4, add:
#DKIM loading
DKIM_CANON = relaxed
DKIM_DOMAIN = ${sender_address_domain}
DKIM_PRIVATE_KEY = CONFDIR/dkim.private
DKIM_SELECTOR = 20170419
and reload the mail server
sudo service exim4 restart
After an appropriate delay for nameserver propagation, use https://protodave.com/tools/dkim-key-checker/?selector=20170419&domain=example.com to check your work.
If that works out, mailto:check-auth@verifier.port25.com from example.com to ensure everything checks out:
echo -e "Test my DKIM plz\nMsg Body\n.\n\n" | mail -v check-auth@verifier.port25.com
DMARC
Domain-based Message Authentication, Reporting and Conformance is where the wheels can come off if you screwed anything up. We’re going to set things up so that when you screw it up, computers scold you rather than putting your emails in the bin.
You will need to create two dmarc reporting accounts. Servers will email you a (surprisingly detailed) report card on how you’re doing with your implementation. It’s best if these accounts are on the same domain, because technically you need to be or it’ll be ignored (Google will happily mail reports off-domain even if the other domain hasn’t said that’s okay). Yours are dmarc_failures@example.com and dmarc_summary@example.com, according to the following nameserver entry:
_dmarc.example.com. 1800 IN TXT "v=DMARC1;p=none;pct=100;ruf=mailto:dmarc_failures@example.com;rua=mailto:dmarc_summary@example.com"
none is the consequence for screwing up. none is where we’ll start at, and see what the reporting records say to us. After a while, you’ll be comfortable that everything is ticking along nicely, and you’ll up the consequent to quarantine (shove it in spam) or reject (burn it).
After your nameserver changes have propagated, you can go to https://dmarcian.com/dmarc-inspector/ to check out if you got it right.
As a human, to read the records sent to you, upload the files to https://dmarcian.com/dmarc-xml/
