Set up emails that don’t get blocked

I’ve recently had to fix some security issues with emails I’ve set up on my custom domain, so that they were received correctly by recipients and not getting blocked.

In finding the answers that allowed me to resolve my issues, I thought this information could be helpful for someone else who is blocked by this.

There is definitely a lot more to this topic than what I’m covering in this short post, but I’ve also included some reference links that could be helpful in helping you set up emails that don’t get blocked!

The three key methods to ensure your emails are authenticated correctly for your intended recipients are:

SPF

SPF stands for Sender Policy Framework, it is a form of email authentication that determines what email servers are allowed to send on behalf of your domain.

Oversimplified diagram of how SPF authentication works.

A receiver of an email will check to see if an SPF record is present, if an SPF is not present – or there is an issue with the SPF – then your email may be blocked.

An issue I found with SPF records was that too many dns lookups were being detected from the record (the limit is 10). Possible solutions are cleaning up your required domains, or creating a subdomain for emails that require certain SPF records.

An SPF DNS record is categorised under a TXT type, using the root domain (@) to target the whole domain, or you can also target a subdomain if needed.

An example of how this looks whilst including Google email servers are:

Name: @

v=spf1 include:_spf.google.com ~all

Full details of SPF syntax can be found here, but breaking this example down:

• v=spf1 : declares the version of SPF that is being used
• include: _spf.google.com : declares the entry for what ip addresses it should look up (in this example, we are allowing ip’s related to google to be looked up and authorised to send on behalf of our domain)
• ~all: declares the result of what should happen if the condition is not met, in this case the use of tilde character indicates a ‘soft fail’ – this will allow the emails to send but will mark it as being in ‘transition’

An example of multiple entries is noted as follows:

Name: @

v=spf1 include:shops.shopify.com include:_spf.google.com include:smtp.shopify.com ~all

If you are looking for a way to test your SPF email records, this tool could be really helpful for you.

DKIM

DKIM stands for Domain Keys Identified Mail and is a form of email authentication that is generated by and authenticated with your SMTP provider. In my case, I have a custom domain created with Gmail, so google generate a DKIM record for me to use on my domain.

Oversimplified diagram of how DKIM works.

This can take the form of a TXT (sometime it can also be a CNAME) record and looks as follows:

Name: google._domainkey

v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC1TaNgLlSyQMNWVLNLvyY/neDgaL2oqQE8T5illKqCgDtFHc8eHVAU+nlcaGmrKmDMw9dbgiGk1ocgZ56NR4ycfUHwQhvQPMUZw0cveel/8EAGoi/UyPmqfcPibytH81NFtTMAxUeM4Op8A6iHkvAMj5qLf4YRNsTkKAV

A tutorial for generating DKIM with Gmail is here, breaking this example down shows:

• v=DKIM1 : shows the version of DKIM being used
• k=rsa: K indicates key type, the default value is rsa which must be supported by both signers and verifiers
• p=MIGfM…: P indicates the public key and will show an autogenerated key (digital signature), which in my case was auto generated by Google

DMARC

DMARC stands for Domain-based Message Authentication Reporting and Conformance.

Oversimplified diagram of how DMARC works.

This specification tells the world how to handle unauthorised mail being sent with your domain and also enables reporting of what emails claim to have been sent from your domain.

This is useful because it gives you the control to determine what happens to emails that should be rejected and gives you visibility on these emails via a report.

As well as helping prevent phishing / spoof emails being sent from your email address, just having a DMARC record can result in a positive reputation bump.

An example of DMARC TXT record being used is as follows:

Name: _dmarc

v=DMARC1; p=reject; rua=mailto:[e-mail]

A further explanation of DMARC is located here, breaking this example down:

• v=DMARC1 : shows the version of DMARC being used
• p=reject : declares that all unauthorised emails should not get delivered to the recipient
• rua =mailto:[e-mail]: declares a list of emails that should receive a report on what emails are claiming to be sent from this domain

I hope this post was helpful in your journey to ensure your emails are not getting blocked by your recipients!

The last few posts I’ve done have been heavy on Devops content – I’ve got a bit more Devops to get out of my system – but there will be some other cool stuff coming soon