Sending an email - we don't really think about what it takes to make the email arrive at the destination. You type your text, enter the recipients address, add a concise subject, and hit send. But when moving from a consumer email address (provided by your internet service provider, or a Gmail, Yahoo, or Hotmail address), there are a number of things you need to do to ensure your message passes the spam verification. All to often, from small businesses or large corporations, I receive emails from servers that have been improperly configured. Here are the most frequent and severe errors, and what you can do to prevent them (if this is something you just want to have done, without having to bother how it is set up, feel free to skip the technical gobble-dee-gook to here).
Set up a policy to allow a mail server to send mail on your behalf
Sender Policy Framework, or SPF, is a mechanism to tell the world that an email server is allowed to send emails on your behalf. What does that mean? In personal emails your address is governed by the provider of the email (for example hotmail.com, gmail.com, yahoo.com, or yourisp.com - the part after the @ symbol). When you set up your business email, you send emails on behalf of yourdomain.com; you must tell the world that your mail server is allowed to send emails on that domain (@yourcompany.com).
How to set it up - In your email program, you will find a menu for deliverability or authentication, or search for SPF. There is typically a statement to add a TXT record to your DNS zone manager in your domain (this is different for each domain manager - in GoDaddy it is in Manage DNS Settings of your domain). The SPF record usually has a value like this:
v=spf1 include:yourmailserver.com -all
Note that the record ends with -all or ~all. The -all is a strict include, everything else is excluded causing a "hard fail" on SPF authentication if the mail server is not called out explicitly. A ~all will stamp a "soft fail" which may be allowed through in many mail servers.
Common mistake is made when business have multiple mail servers, and most businesses do, and not setting up the SPF records to reflect these mail servers correctly. There is a simple rule in SPF - there can only be one record per domain. That means that the single SPF record needs to encapsulate all mail servers used in your organisation (your general 1:1 email server, your bulk email campaign server, your accounting package if it sends invoices on behalf of your domain, etc). Two SPF records will result in total SPF failure on your domain. Here is how to include multiple servers in a single record:
host: @ (or yourdomain.com) value: v=spf1 include:yourmailserver.com include:yourbulkmailserver.com include:youraccountingmailserver.com -all
By adding the new servers in between the v=spf1 and -all (or ~all), you add the multiple mail servers into your single SPF record. To check your SPF settings, go to https://www.mxtoolbox.com and type in the search box on the site: spf:yourdomain.com. Note below the image of a typical SPF record for a Zoho One implementation - I have placed circles on the ~all and SoftFail consequence. If it was -all the result would be Fail instead of SoftFail.
Set up identification keys on your domain
DomainKeys Identified Mail, or DKIM, is the second part of your email deliverability plan. With SPF we told the world that a particular server is allowed to send emails on your domain's behalf - with DKIM we are specifying exactly what tenant of the server is allowed to send on your behalf. For example - Zoho Mail is used by many thousands of users, all with different domains. With SPF we established that Zoho Mail (zoho.com) can send emails. With DKIM we create a unique key for your domain and mail tenant combination.
How to set it up - just like SPF, DKIM is set up in your DNS Zone Manager, by adding a TXT record. Their are two main differences between DKIM and SPF records. First, each mail server will have its own unique DKIM entry (unlike SPF where the servers are added in the same entry), and second, the DKIM records are unique keys just for you. You should not share these. A DKIM record looks like this (note: some details have been altered to obscure the actual content).
host: #####_domainkey.yourdomain.com value: k=rsa; p=<your unique DomainKey string>
Note that in some domain managers (like GoDaddy) you do not add .yourdomain.com after domainkey in the host.
Replace the ##### with the actual numbers in your host settings, and <your unique DomainKey string> in the value - both provided in the deliverability or authenitication settins in your email server.
Common mistake is not configuring the DKIM at all, or configuring it incorrectly. As above, if in GoDaddy, for example, you add .yourdomain.com after the domainkey in the host, the entry will save in your DNS settings, but your authentication will fail. The string must be copied exactly as provided, it is case sensitive, and be careful of trailing spaces.
Going all the way with DMARC
Domain-based Message Authentication, Reporting & Conformance, or DMARC, is the final step in securing your domain from nefarious actors using it to spam and spoof. Unlike SPF and DKIM, it is an optional step. DMARC tells the recipient mail server how to act in case of failed SPF or DKIM verification. The policy also provides a daily report on activity for audit purposes.
How to set it up - DMARC is easy to configure - it is a single TXT entry in your DNS settings. The setting is always the same:
host: _dmarc.yourdomain.com value: v=DMARC1; p=<none/quarantine/reject>; rua=mailto:admin@yourdomain.com
Note again the .yourdomain.com is not always necessary - check your domain DNS settings. The policy (p=) is determined by three options how to handle emails that failed authentication: none, quarantine, and reject. The rua entry is used to send the daily report to. Replace admin@yourdomain.com with the email address of choice.
Common mistake is to set up a strict reject policy prior to testing the settings. It is recommended to start with a policy of "none" and audit the daily reports. If there are no failures on servers that should pass, you can move this to the quarantine policy. If you are confident about your email configurations, you can move it to the reject policy. Another mistake is to leave the DMARC policy on none indefinitely - this is the same as not publishing the DMARC at all (except for the daily report), or to leave DMARC on quarantine or reject when you have added a new mail server in your process. With every change in your mail server set up (i.e. you have added a new addition to your SPF record, and a new DKIM entry), you should go through the none, quarantine, reject steps again.
Too much? Let us handle this for you in Digital Business Services
If your eyes start glazing over the first paragraph describing SPF, then you are not alone. It is not as simple and straight-forward, if it were, then a lot more companies (of all sizes - I see plenty of examples where top tier multinationals, even in the information technology sector) get it wrong!
With Aurelian Group Digital Business Services, we take care of this for you. You only have to focus on the content of your message - we ensure the deliverability is not negatively impacted by incomplete or improper domain authentication.