5 min read

Emails going to spam? 3 things you need to do

Emails going to spam? 3 things you need to do

Have you been hearing from your users that the emails you carefully crafted about the upcoming product lunch went unopened, how about those emails you sent to clients and never heard back? This might just be that those emails weren't as marvellous as you thought but we see a considerable amount of emails go directly to spam, especially in the cases where the email was being sent by a third-party tool like Mailchimp or Hubspot.

First off, let's address why these tools exist.

When you're sending an email to another user online, this email contains information about who it's going to, who it was sent from, and what server/service it was sent using. Malicious users will mislead users by injecting the from fields to match users or domains that they don't actually have access to. These emails can often appear authentic coming from Microsoft or a colleague while asking you to enter sensitive information in a compromised website.

To prevent these spammers from getting into your mailbox request, email providers such as Gmail and Outlook have had to get very clever in the way they authenticate inbound emails. The email servers look at a number of factors to select which emails are delivered and which are sent to spam but in this article, we're going to look at 3 tools that will improve your probability of making it to the inbox.

Sender Policy Framework (SPF)

An SPF record is a text(TXT) record that is added to your domain name system(DNS) to provide clear direction to email services about where an email can originate from. The text record will include a list of all authorized hostnames and IP addresses that are allowed to send emails on behalf of the domain name.

Here's the basic markup if you're using Google Workplace for your email and no other email services.

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

Now here's a more realistic example of an SPF record that includes the Google Workplace, the website's IP address, and a couple of third party services.

v=spf1 mx ip4:127.0.0.1 include:_spf.google.com include:spf.mandrillapp.com -all

This may look a little confusing but let's break down the options being used.

v=spf1 is the version of the Sender Policy Framework being used.
ip4: would normally be the static IP address of your website
mx indicates to authorize the current MX records used on the doman.
include: can be repeated for each one of the 3rd party services you'll need.
-all tells the service to fail or reject emails coming from services that are not listed in the record.

There are some free tools like SPF Wizard or SPF Generator to help you get the right syntax but the bigger question you're probably asking is how do you find the right hostnames for the include for each one of your services.  

You can probably find most of the answers by simply searching online and finding technical documents from the services themselves or posts by other users but I found that looking in your emails was faster for me.

Here's an example of the email header information available by clicking the dropdown at the top of a message in my Gmail where you can see that they are sending email via post.xero.com which is what I would add to my includes.

Screenshot of email message from Xero displaying post.xero.com as the mailed-by header

Add your new TXT record to your DNS and in a couple of hours, you will be one step closer to better email deliverability.  

DomainKey Identified Mail (DKIM)

DKIM takes email authentication further. While setting up your SPF records was fairly straightforward because all of the information was accessible to you, DKIM records require your email server or service to provide you with an encrypted key. These keys will need to be configured for each one of the services individually and create an even higher level of security which recipient's inboxes will interpret as a more trusted email.

For example, let's configure Google Workspace email (click here for Google's technical document).

Head over to Google's Admin dashboard and open up the Apps > Google Workspace > Gmail and then click on Authenticate Email.

Screenshot of the Google Admin portal viewing the DKIM authentication key

From here you'll want to press Generate New Record and set the key to 1024 length. This is more than enough for our security purposes and will reduce the chance of length issues when you add the record to your DNS.

Follow the steps adding the txt record named google._domainkey and paste in your long key value. Once this is done, click the start authentication and in a couple of hours the key pair will validate and you've now configured DKIM for Google Workspace.

You will find that many of the services you use to send email may not have the option to configure DKIM. Ideally, we'd be able to configure this additional layer of security for every tool and service we use but as long as we've done our SPF record correctly, the emails should start delivering with more consistency.

Domain-based Message Authentication, Reporting, and Conformance (DMARC)

You might be wondering at this point what happens if you have set up everything and you send an email that came from a service you forgot to add to the SPF. Maybe there was a typo or incorrect hostname. DMARC is a standard that allows you to configure what happens when there is a failure and where to send your failure report to diagnose the issue.

All DMARC information will be stored in a TXT record named _dmarc.

Let's take a look at an example the syntax.  

v=DMARC1;p=reject;sp=reject;pct=100;adkim=s;aspf=s;rua=mailto:michael@michaelwood.ca;ruf=mailto:michael@michaelwood.ca;ri=86400;fo=1

v=DMARC1 is the version of DMARC we're using.
p=reject and sp=reject are the policies that the server should reject email that fails.
pct=100 is the percentage of emails that are subject to the policy. 100 means every failure will send a failure report.
adkim=s sets the policy as strict ensuring domains are exact. Using r for relaxed will allow partial domains to be accepted.
rua and ruf set the email address for the reports to be sent.
ri=86400 sets the reporting interval in seconds which allows the service to consolidate multiple reports.
fo=1 tells the service to report failures if SPF or DKIM don't pass. Use s for SPF only or d for DKIM only.

Easy DMARC has a free tool available to generate the syntax which makes the format easy.

Staying Out of Spam for Good


There are too many reasons to list as to why you still may end up in someone's spam but this article was focused on the technical configurations to improve your chances. Spam filters are getting smarter and smarter every day so to keep your email ending up in your audience's inbox the most important variable is the quality of your messages. Emails that users enjoy and take the time to read, reply, or engage with will always perform better. Your domain name will need consistent good behaviour to earn the trust of spam filters so you don't end up being part of the problem.