A triangle of protection exists for your email, that of SPF, DKIM, and DMARC, but chances are you are not using them. By implementing this trio, you will prevent spammers sending emails on your behalf (a risk any company faces without knowing it) and at the same time as an added bonus, you will very likely lower your spam score for anyone receiving your emails – great news for marketers and folks running newsletters! These three methods add a layer of protection, validity and security to any email you send out. While the topics are technical, your web host or IT department will be able to implement these on your behalf.
What are they?
Each one of the pillars represent a different protection method for your emails, dealing with the content of your mail, validating the sender of the email, and ensuring that the receiving server honours the validations and takes action. SPF (Sender Policy Framework) and DKIM (DomainKeys Identified Mail) may be applied individually for a single layer of protection, while DMARC (Domain-based Message Authentication, Reporting, & Conformance) is applied “on top of” DKIM, SPF, or both for the highest level of validation and protection.
Sender Policy Framework (SPF)
Simply put, SPF deals with where the email originated from. It is a framework to put a policy in place to define who is allowed to send email from your domain. It is a validation that is hosted in the DNS records of your domain that states which servers on the web are allowed to send email for that domain. Often what will happen with spam is that spammers will appear to send from someone’s address, but in reality they are sending from a totally different server or range of compromised servers across the globe. What SPF does is add in a list of acceptable servers for your mail to originate from. You are not necessarily only protecting your reputation by using SPF, but you are protecting your recipients by giving them a mechanism (on their servers) to see that your email came from servers you are aware of and in control of.
For example, my SPF records state that email is only allowed to come from my Office365 servers, my Amazon Web Services servers (where the email from my website contact forms are sent from), Mailchimp (newsletters), and RocketSeed (my email branding tool). Any mails sent from any other sources should be rejected by the receiving server.
DomainKeys Identified Mail (DKIM)
While SPF deals with where the mail originated from, DKIM verifies the sender within the content of an email. It is a way for a receiving server to validate that the contents of the email have not been modified and that the sender is who they say they are. It uses certificates, similarly to HTTPS, to “sign” your emails invisibly in the background that it’s an original mail. Think of it like getting a stamp from a commissioner of oaths.
If your email is modified while in transit, or comes from a different server to yours, the stamp (the invisible signature) will be modified or not present, leading the receiving server to see that the mail is not what was sent originally or it is fraudulent. It’s a sort of three way match, where you have a “key” that is private that only your server or computer knows (which it signs your email with), and a mathematically linked “key” that is public – hosted in your DNS records. The receiving server will see the public key, verify that the two match, and if they do the mail is seen as genuine.
Domain-based Message Authentication, Reporting, & Conformance (DMARC)
Both of the above methods are great protection methods, however they do not take the next step to enable you as the domain owner to take control or to see how your mail is performing. You’re basically putting blind faith that the methods are working. DMARC changes this by adding reporting and a mechanism for you to instruct remote servers as to what they should do in the case of messages that don’t match SPF and DKIM.
DMARC basically serves as a cover letter to receiving servers to say “Hey, just so you know, I’m using SPF and DKIM, you better be sure to reject messages that don’t come from me. I also expect a daily report back to the email address firstname.lastname@example.org if someone sends mail to you.”
This adds a little more traffic to your emails, as you’ll receive reports from receiving servers about mails that were accepted or rejected, but these are easily taken care of with a mailbox rule. To give you an idea, I receive about 1 report a day for DMARC. These reports aren’t easily readable without tools, but there are a lot of these available online if you really want to monitor large swathes of mails. There are multiple options in DMARC, where you can be strict (any messages that don’t comply with SPF or DMARC are rejected) or lenient (just notify me if someone sends a mail that breaks the rules).
How does this affect my “spam score”?
The more checks and balances you have in place, the less likely your emails are going to be flagged as spam. Spam filters generally work on a scoring system, and the higher the score, the more likely your mail will go into someone’s spam folder. For example, the more links you have in an email, the higher the score may be.
Things like SPF and DKIM lower the score (sometimes dramatically), because it is much more likely that the emails are legitimate when coming from a validated source. I have had many clients whose newsletters and personal communications were going to spam by default, and a week after implementing SPF and DKIM they were all seen as legitimate (with some very relieved clients).
Help! How do I do this?
It is a very technical process to implement. If you have a dedicated IT department, they should be able to handle this for you. A reputable hosting company should be able to assist too, if you are using a shared hosting package.
If you are using multiple services, such as Mailchimp, landing page / lead generation tools, external mail services such as G Suite, Sendgrid and Office365, you may want to get a professional in to assist. Ross G Saunders consulting offers this service globally with rapid turnaround, as there is no requirement for face-to-face contact to implement these methods. Should you need assistance, please contact me for an estimate!
If you are feeling brave and wish to do this yourself or you have an IT professional to assist you, please read on for a much more technical dive into the implementation of these three mechanisms.
How do I implement them on my own or with my IT provider?
All of these mechanisms are reliant on the DNS of your domain – basically the “town council office” of your website, email, domain and hosting. DNS serves as a master record for all your hosting services, reference points, validations, and addresses of sites and services. In a lot of cases, you won’t have direct access to these and it will be up to your hosting provider or IT specialist to make the changes for you.
For DKIM, you will also need a mail service that complies with the standard, such as Office365, Google G-Suite, AWS Simple Email Service, or similar. If your email is hosted with your website, ask your web host for advice. Hetzner, the host that I use for clients in South Africa, simply need a request sent to their support team and DKIM will be enabled. If your host does not support DKIM or doesn’t know what it is, I would seriously consider moving providers!
The sections below will get pretty technical, you may want to involve IT from this point if modifying your DNS records is not your cup of tea. If you are going to modify your own records, be aware that you can break a whole host of things quite easily with an incorrect configuration!
SPF is the easiest of the three to implement, and consists of a single DNS TXT record. The record is formed in the following manner as an example:
v=spf1 a mx ip4:192.168.0.0/24 include:spf.protection.outlook.com -all
The v stands for SPF record version, in general this will be the same on all domains. The arguments after this (in bold) are used in conjunction with each other or individually, depending on your setup. I will cover the most common arguments below. The last portion, “all” is common on all records, and has its own power in its prefix, it is always the final statement in a record.
- a – Match against the A record in the DNS zone
- mx – Match against whatever the DNS zone’s MX record is.
- include: – Match against a DNS record as a sender, this can cascade down and often services will daisy chain SPF records together on their own domains.
- ip4: – Match against an IP address or address range as a sender
In the example above, the A record, MX record, IP address range 192.168.0.1 – 192.168.0.254, and all the SPF records located on spf.protection.outlook.com will be matched as verified senders from this particular domain. Each of these arguments are optional. Things like ip4:, include: and so on may be used multiple times after each other. For example:
v=spf1 mx include:amazonses.com include:spf.protection.outlook.com -all
In this example, both Amazon’s SES service and Office365 are included, while the A record and IP addresses have been excluded.
The -all at the end specifies how strictly remote servers should apply the rule. There are a few operators here, ?all, ~all, +all and -all.
- ~all – Soft fail – This means that any mail coming from a server other than those you’ve specified should be allowed to be delivered, but marked as spam.
- ?all – Don’t answer – There really is no point to this and it is often only enabled as a default before you’ve configured it.
- -all – Hard fail – Any mail coming from a server other than those specified should be rejected.
- +all – Pass – Used in very specific circumstances to work your rules in reverse in circumstances where you are working by exception. Avoid using this unless you REALLY know what you’re doing.
There are other switches and operators for SPF records, I’ll leave it up to you to read further if you need them (such as IPv6 and so on).
DKIM is a little more complicated to setup, and requires a server (or service) that supports it. Because of its complexity, there are a number of servers that do not support it, and a number of providers (cringe) that haven’t implemented it. DKIM works with DNS as well, and refers to “selectors”. Within the signature attached to a mail header, your domain name and selector number will be used. The selector is there to specify which certificate and server combination has been used to sign that particular email.
The header of the email will appear as follows:
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rossgsaunders.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=this-is-a-hash-of-the-message-body1234567890; b=this-is-a-really-long-signature-of-the-header-and-body-1234567890abcdefghijklmnopqrstuvwxyz;
The main items to look at here are the following arguments:
- d – The domain that sent the email
- s – The selector that contains the public key
- bh – a unique hash of the message body
- b – a unique signature of the headers and body
These arguments represent the backbone of DKIM. On your DNS side, you will have a DNS CNAME record for each selector specified under s for your domain d. In this example, it is using Office365’s servers under my domain, so my DNS records look similar to the following.
Hostname: selector1._domainkey Destination: selector1-rossgsaunders-com._domainkey.domainremoved.onmicrosoft.com.
Hostname: selector2._domainkey Destination: selector2-rossgsaunders-com._domainkey.domainremoved.onmicrosoft.com.
The destination server will be the sending server that is providing the public key in order for the receiving server to validate the signature. Your sending provider, such as Office365, Mailchimp, Rocketseed or similar will provide you with the hostname and destination that you need to insert. The selector will always be suffixed by ._domainkey within your DNS zone’s hostname – that is how the receiving server looks up the record.
Once you have SPF and/or DKIM set up, you want to setup DMARC to tighten things up. This is relatively easy to set up, and there are many record generators out there that can create this record for you. I am going to explain the background of the record, so that you can (hopefully) create it manually for yourself. It is quite easy in the end. Here is an example of a DMARC TXT record:
v=DMARC1; p=reject; sp=reject; rua=mailto:email@example.com; ruf=mailto:firstname.lastname@example.org!10m; rf=afrf; pct=100; ri=86400
This too uses arguments in the record in a similar way to SPF, I will detail these below. You basically just need to choose which suits your particular preference and level of control.
- v – Version – Identifies the DMARC record.
- p – Policy – The policy to apply to emails from this domain that fail validation, “none”, “quarantine”, or “reject”.
- sp – Sub-domain Policy – The policy to apply to emails from any sub-domains that fail validation, “none”, “quarantine”, or “reject”.
- rua – Receivers – List of recipients of XML reports.
- ruf – Forensic Receivers – List of recipients of Forensic reports.
- rf – Forensic Format – The reporting format for Forensic reports, can either be “afrf” or “iodef”. Most folks will use “afrf”, as this is a new standard supporting DMARC fully. “iodef” would generally only be used if you are feeding this information into an incident response tool that requires this format.
- pct – Percentage – Receivers should apply the policy to this percentage of mails that fail the DMARC test.
- ri – Reporting Interval – How often to send XML reports, in seconds. This will generally be 24 hours (86400 seconds), regardless of what this is set to, as it is up to the receiving party to define this.
Starting with a lenient policy (none) is valuable to check that all your services are working with DMARC. You will still receive reports and will be able to verify whether your checks are failing. If you set the policy to reject straight off the bat, you may end up with your email being rejected incorrectly due to a problematic configuration.
Struggling to implement?
If you find yourself struggling to implement this, please reach out for assistance. I am always happy to lend a hand to help folks take control of their security and privacy! With that, here endeth the (very long and technical) lesson!