Try Mailstand for free.
Merge mailboxes for better email outreach.
There’s no point painstakingly crafting an email drip campaign if those mini masterpieces end up spam filtered out of existence. You only have one chance to make a first impression when sending a cold email, so it pays to get it right.
Fortunately, there are authorization protocols to follow which will ensure that your messages have the best chance of getting through to their intended recipient.
These protocols are called Sender Policy Framework (SPF), DomainKeys Identified Mail (DKIM) and Domain-based Message Authentication, Reporting and Conformance (DMARC). They are methods for authenticating the domain from which the email issues and proving that you aren’t sending spam or making phishing attempts.
Although they perform basically the same function, SPF, DKIM and DMARC work in subtly different ways. Let’s break down those differences a little.
This is method for limiting the number and identity of domain IPs which can send emails via your domain. As domain owner, you can provide a record on the server which lists the IP addresses authorized to send emails on your behalf.
This method works similarly to SPF, but the information is provided as a TXT file on the domain panel. This prevents any possibility of tampering between source domain and recipient. It does so by effectively adding a digital signature to every email you send.
DMARC builds upon both SPF and DKIM, allowing you to specify parameters of authentication in terms of percentage of the message which will be checked, and what will be done with the message if authentication fails. You can also set levels of alignment between the various domain addresses you use in your message. This method gives you the highest degree of flexibility.
All three methods can be used in tandem to build the reputation of your email server, so that you maximize the number of emails you send which don’t get filtered out of inboxes.
The good news is that you don’t need extensive programming knowledge or ability to institute these protocols. There are tools which will walk you through the process, and it’s not too complex to follow for most people with a little technical ability. Below, we’ll explain in detail how to go about setting up these authentication methods.
First, a word of warning. It’s important to appreciate is that every email comes encoded with two “from addresses”. The first is the Mail From address, which specifies where non-delivery notices and other delivery reports should be sent. This is sometimes also known as the reverse-path address.
The second type of address identifies the individual account from which the email originates. It specifies the author of the email and is displayed as the From address in a recipient’s inbox.
The Mail From address is the one that SPF (when used singly) checks in the DNS record. It is also known as the RFC5321.MailFrom address. SPF allows for scenarios where the Mail From address and From address do not match (such as when you are using a third party email server).
We’ve probably all seen phishing emails in our spam folders – superficially they seem to be from banks, trusted corporations, or other reliable entities. However, if you look closely, they really originate from unknown individuals trying to defraud the recipient.
This possibility means that SPF should not be used without one or both other authentication methods below.
First gather up all the IP addresses from which you might want to send marketing messages. For a large corporation, this can be a significant undertaking. However, you can always add new addresses to the list as and when necessary. Remember that these are the servers sending the emails, not the individual user’s terminals.
You’ll need to set up an SPF record for each domain from which you send email, and for those from which you don’t. Why the latter? These domains can be spoofed by would be phishers, so it’s important to include them, to prevent this possibility.
An SPF record typically looks like this:
v=spf1 ip4:1.2.3.4 ip4:2.3.4.5 include:thirdparty.com -all
Each SPF record can be no longer than 255 characters long and you’ll need a separate one for domains which don’t send email, which will look a little like this:
v=spf1 –all
Let’s break down those elements a little.
v=spf1 This tag tells the server that an SPF record will follow.
Ip4: 1.2.3.4 (etc.) These are the IP addresses you want to authenticate (substitute the appropriate numbers for 1.2.3.4.)
include:thirdparty.com Add the include tag if you use a third party to send emails and want to ensure that their emails aren’t bounced.
-all This tag is used to specify that a hard fail protocol should be followed for emails which don’t pass authentication.
The end tag could also be a soft fail (~all) which indicates that an email is probably dubious in origin. Sometimes soft fails are used to divert suspicious emails to spam folders rather than reject them outright (the hard fail option). However, it’s generally regarded as safest to use a hard fail protocol.
Once you have your text string, you need to publish it to your DNS server. Your hosting or ISP provider should have a publishing this information. Otherwise, speak to your IT provider about how to do this.
You can test your SPF record with various checking tools such as Proofpoint or the free online domain checker at MX Toolbox. These tools will look up the SPF record for a specified domain and perform a series of checks to ensure it’s working properly. They will return a report highlighting any potential errors in your SPF record, so that you can perform any necessary fixes.
DKIM takes security one stage further, effectively allowing you to digitally sign each message you send, proving its authenticity. Setting up DKIM can be a little more complex. Below, we’ll explain how to go about it.
Obtain sign-in details from your domain provider and find out whether 2048- or 1024-bit DKIM keys are supported. The former is more secure and should be preferred. You’ll be able to specify key length in your admin console.
Add a TXT record to your domain provider’s management console. The DKIM TXT file will be much longer and more complex than the SPF record because it includes a matched set of long codes with letters and numbers which are wholly original to your domain. There are numerous tools to help you generate DKIM TXT files, fortunately.
Here is an example of the DKIM TXT format (courtesy of mailtrap.io):
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=asuswebstorage.com; s=default; t=1572282571; bh=NFzBvJ/pEmf+yUHDd/Y7dYNH9pE+Bx6o95KcxhwFL78=; h=From:To:Subject:From; b=QwgINKqwcBu3GbeWm2Be81qXks6Pq9yMmDZl9C6mT8moXVBeokpEmDN+0RyZFiOmNH30kbe6HbS2lY3b1Pf726UH/V/0VAH0nigTuir4TWdN/IUePV+goQdEJ2+sDQ1fHlVjyyJCRwCiFiZpBIjhTBNN0vrgNJZ/gSLLOvq6k3s=
Here's a brief explanation of what the various tags mean:
V=1 Indicates version number (always 1).
a= The algorithm used to create the DKIM record.
c= An algorithm for the header / body of the email.
d= The domain the emails originate from.
s= The DKIM selector
t= A timestamp creator
bh= The body header
h= The header list
b= The digital signature
Fortunately, most of these tags are standardized and your management console should only require you to specify two of them. These will be the authorized domain (d=) and the DKIM selector (s=). The domain is the From address not covered by the SPF protocol, which makes DKIM a complementary security method to SPF.
The DKIM selector simply specifies which pair of keys (public and private) will be generated for this domain. If you send emails from several domains, perhaps using one for marketing messages, and another for customer support communications, then name these separately using the DKIM selector. You could simply call one “marketing” and the other “support” for instance.
If your domain provider or ISP doesn’t have a facility to generate a DKIM TXT file for you, then there are a host of online tools which can help with this. These include Sparkpost’s DKIM Wizard and DKIM Record Generator from Easy DMARC.
Once you have a complete DKIM key, you’ll need to input this in your admin console of your domain provider. You’ll then need to turn on DKIM authentication and test whether it is working. Free tools to help you do that can be found online from several providers including Mimecast and Easy DMARC.
The third and final type of authentication to employ is DMARC. This will specify—much more effectively than the -all tag of SPIF—what should be done with unauthenticated emails. By using DMARC you can specify whether unauthenticated emails should be rejected outright, quarantined, or allowed. You can also specify an address to send delivery reports to, giving plenty of information which can help you block or report bad actors.
As with the above methods, you’ll need to add a TXT file to your domain provider’s admin console. DMARC is much more straightforward than SPIF however, consisting of the following (at minimum):
v=DMARC1; p=reject; pct=100; rua=mailto:you@exampledomain.com
Here are those tags explained:
V= Specifies which version of DMARC to use
p= protocol to follow if email can’t be authenticated
pct= percentage of emails from each domain to be checked
rua= email address to send fail reports to
P= can be set to “none” (monitor but take no action), “quarantine” (send suspicious emails to a spam folder) or “reject” (don’t deliver at all). The p= tag allows you to use different policies for different mail servers.
For example, a corporation’s top executives might have the highest level of security applied, with all unauthenticated emails rejected, while less senior staff throughout the company may have spam filters to quarantine failed emails, so that mistakenly rejected emails can still be found if needed.
Google Workspace recommends a slow rollout of DMARC, changing the p= setting according to what percentage of your emails are getting through. As they write, “Start with a none policy that only monitors email flow, and then eventually change to a policy that rejects all unauthenticated messages.
A none policy lets you start getting reports without the risk of your messages being rejected or sent to spam by receiving servers. You can also set your DMARC policy to apply only to a percentage of the messages sent from your organization. These two features let you deploy DMARC gradually, while remaining in control of your mail flow.”
Google recommend you monitor performance with p= set to “none” for one week, checking the reports you’ve received by specifying a report return address using rua=. After one week, you should review the DMARC report.
The DMARC report should contain:
You can monitor the number of emails getting bounced to spam folders as well as error messages received. This may help you to identify patterns and problematic servers or services.
After one week, Google recommend you change the p= setting to “quarantine” and set your rua= parameter to a small percentage (5% or 10%). The larger the enterprise or business, the smaller the percentage of emails you should check at this stage. Continue to monitor reports and make changes as requested.
The final stage of a DMARC rollout is to set p= to “reject” and either set the pct= tag to 100 or remove it completely (the default setting is 100%). Pct= is set to 100 in the most security conscious environments and will ensure that no bad actors can send spoof emails from any of your domains.
You should continue to monitor DMARC reports from time to time to ensure the DMARC settings are correctly set up and have not been tampered with.
While not mandatory to use both, it is highly recommended to combine these authentication methods to ensure that you minimize phishing / spoofing attacks, while maximizing email deliverability.
SPF and DKIM work best in tandem because they address separate vulnerabilities in the underlying Simple Message Transfer Protocol (SMTP) used by email systems. SPF ensures that emails can only be sent by specified servers (all of which have unique IP addresses). DKIM matches a public key to the private key held by the sender to ensure that the email has not been intercepted or altered on route between sender and recipient.
Therefore, to maintain the highest standards of email security, it’s well worth instituting both protocols.
DMARC is a third layer of security allowing for quarantining or rejection of messages which fail SPF or DKIM protocols. However, sometimes DMARC rejects emails which would pass both SPF and DKIM checks. Why would this be?
For DMARC to pass, the SPF or DKIM domains need to align with the body From address (5322.From). When you send your email, DKIM kicks in to sign your message using the d= and s= tags, where d= is the domain the email is sent from.
Meanwhile SPF encodes the return path, which is the address to which any reports or receipts should be sent. Finally, DMARC includes a Body From address. For DMARC to work, either the SPF return path and/or the DKIM d= address needs to match the DMARC Body From address.
If all three domains appear different, DMARC will fail. A simple fix is to change the body 5322.From address to match either of the DKIM or SPF domains. There’s a discussion page on Stack Exchange about this very topic.
Another reason why DMARC could fail, even when SPF and DKIM authentications succeed, is that one or both of your SPF or DKIM email identifiers are unaligned.
DMARC has optional tags aspf= and adkim=, which refer to the degree of identifier alignment which you wish to apply. Both tags can be set to values of S (strict) or R (relaxed).
Here’s an example of what is meant by strict or relaxed alignment:
STRICTLY ALIGNED
info@exampleaddress.com
Bill@exampleaddress.com
You can see that everything after the @ sign is identical in both cases.
RELAXED ALIGNMENT
info@mail.exampleaddress.com
Bill@reply.exampleaddress.com
Here the root domain (exampleaddress.com) is the same but the subdomain is different. Still, a relaxed alignment setting assumes they both originate from the same domain.
UNALIGNED
info@exampleaddress.com
mail@thirdpartyserver.com
Here, the two email addresses are clearly different domains. There may be legitimate reasons for this if, for example, you use a third-party provider to handle your email. Or you may be using a brand address which is a subsidiary of the umbrella organization, and thus they have different domains.
Here’s how the s= and r= tags effect the above examples:
S: Only strict alignment passes
R: strict or relaxed alignment passes
Here are some examples of passes and fails, related to the DMARC tags ASPF and ADKIM:
Either tag set to S
info@mail.exampleaddress.com
Bill@reply.exampleaddress.com
Result: FAIL
Either tag set to R
info@mail.exampleaddress.com
Bill@reply.exampleaddress.com
Result: PASS
Either tag set to R
info@exampleaddress.com
Bill@exampleaddress.com
Result: PASS
Tags not used
info@mail.exampleaddress.com
Bill@reply.exampleaddress.com
Result: PASS
If tags are not used, the default setting for both ASPF and ADKIM is relaxed.
Again, it’s worth checking the various email identifiers in both your SPF and DKIM DNS records, to see whether they comply with your DMARC alignment settings. You can then either change the DMARC alignment tags or ensure that the addresses align appropriately.
DKIM is an optional security protocol for email, therefore it is possible to send emails without using it. However, doing so carries with it several risks:
You can still use DMARC without DKIM, but this will result in the recipient server performing alignment checks on your SPF record only. You are effectively weakening the effectiveness of DMARC by only giving it one type of alignment check to perform.
The authentication protocols SPF, DKIM and DMARC were built upon one another as complementary systems, which provide a “belt and braces” approach to email security. While it is possible to send emails using only one or two of these protocols, it makes far more sense to use all three.
Think of email security protocols as a type of hygiene.
When washing your hands, you could certainly use cold water, which would be better than nothing. However, adding hot water and soap gives a far more thorough clean, removing more germs and reassuring you that you’ve done everything you can to remain hygienic.
Similarly, although SPF, DKIM and DMARC are all separately usable protocols, they work best in tandem, offering you the highest level of authentication. Most importantly, by instituting all three measures, you are protecting your corporate reputation against malicious third-party actors.
Here are some eye-opening statistics to finish with:
Gone are the days of sending a cold email and hoping. Businesses in 2022 are in a constant arms race against malicious criminals wanting to hijack their reputation for personal gain. Given how widespread phishing attempts are, it’s worth ensuring your email authentication protocols are in place and set to the highest security levels.