Email was never designed to be secure, anyone can use your domain to send an email, “spoofing” as it is known. This can be useful to make sure your receive email if you are using a cloud hosting service, or it can be a complete nightmare; nefarious persons may spoof your domain to trick your organisation’s staff (or your partners) to open and download software or reveal information.
However there are techniques that can help you secure your email more, giving you and who you communicate with more confidence when they see one of your emails. These techniques are SPF, DKIM and DMARC.
SPF (Sender Policy Framework) is a DNS text entry which shows a list of servers that should be considered allowed to send mail for a specific domain. Incidentally the fact that SPF is a DNS entry can also considered a way to enforce the fact that the list is authoritative for the domain, since the owners/administrators are the only people allowed to add/change that domain zone’s records (i.e. you!). Let’s say you have an email server in your office, all email you send comes from one IPv4 address (globally routed) in which case your SPF record would just contain that one IP, and you could set it to hardfail stance. Anyone getting an email appearing to be from your domain, but not from this IP address could reasonably assume based on your SPF record that the source of the email is not legitimate.
DKIM (DomainKeys Identified Mail) should be instead considered a method to verify that the messages’ content are trustworthy, meaning that they weren’t changed from the moment the message left the initial mail server and that the source is valid. This additional layer of “trustability” is achieved by an implementation of the standard public/private key signing process. Once again the owners of the domain add a DNS record with the public DKIM key which will be used by receivers to verify that the message DKIM signature is correct, while on the sender side the server will sign the entitled mail messages with the corresponding private key. Anyone receiving an email from this domain can see the DKIM signature (signed using the private key) and can validate its legitimacy with the public key published in the domain DNS record; if its valid the email can be safely assumed to have come from a legitimate source and un-tampered with, i.e. the public key wouldn’t be able to verify the signature if it hadn’t been signed by the complimentary private key of the domain owner or had been changed along the way.
DMARC (Domain-based Message Authentication, Reporting and Conformance) empowers SPF and DKIM by stating a clear policy (or posture) to recipients which should be used in conjunction with the aforementioned SPF and DKIM techniques and provides a mechanism for recipients to report to the domain owner usage of their domain legitimate or otherwise to aid in improving security and compliance of email usage. (citation)
DMARC sets a posture of None (Reporting Only), Quarantine or Reject to those receiving email from the domain in how to interpret a failure of one or both of the SPF and DKIM mechanisms. A message turning up at a recipient’s server where the SPF and/or DKIM mechanisms have failed to verify the message successfully, is then where the DMARC record comes into play.
The DMARC posture as dictated by the sender, tells/advises the recipient how to treat the message, either None (and report) which means accept, although the recipient would normally exercise some caution. Or it tells/advises the recipient they should Quarantine the message perhaps into a Spam folder for the end user to make their own determination, or finally if set to Reject it can tell/advise the recipient to just drop the message outright as failure to validate SPF or DKIM means the message is untrustworthy.
Essentially the SPF is a DNS record saying which IP addresses we will send our email from, the DKIM is a record with a key (of which only we have the private key part) so only we can send messages with a valid signature for our domain and the DMARC tells a supporting receiving email infrastructure how to interpret the SPF and DKIM in the event of failing one or both of them; it can also give statistics of if our domain is being spoofed.
Setup SPF, DMARC and DKIM for GMail
I’ll explain how you can implement a SPF, DKIM and DMARC record for your email domain(s), bear in mind that it is best to start with a simple and non-service affecting posture on your records and then once you are sure on the legitimate use of your email domain work to harden the posture of these records from there.
The instructions below are based on adding these techniques for Gmail. But you can use these same steps for any other supplier of email (or your own internal) you just need to adjust the content of the records accordingly. Your email supplier can provide you with the settings you need to use.
Also bear in mind that SPF and DMARC are just DNS setting changes they require no server side configuration, but DKIM involves changes to your email server (or email provider) to append a key to every email you send. You should check support of your email provider for this.
Bear in mind that SPF and DKIM are the authentication methods, DMARC is the security stance you are telling recipients of email purporting to be from your domain to take, this can be None (i.e. just report), Quarantine (i.e. if its not authenticated or fails authentication treat it as suspicious) or Reject (i.e. if it is not authenticated or fails authentication just delete it).
What this means is that to pass authentication you only need SPF or DKIM to pass authentication, in an ideal world you’d have both pass for every message you send and that should be your goal, but if only one passes that is good enough, you should be careful though on the implementation to not go direct to Reject on your DMARC before you are ready.
Google provider a useful tool: https://toolbox.googleapps.com/apps/checkmx/ to assist but there are loads of other free ones out there.
Setting up a SPF Record
Logon to your DNS management and add a TXT record for the domain as follows:
v=spf1 include:_spf.google.com ~allThe record just says to include _spf.google.com here Google keep their list of servers sending email up to date, if you have your own email server, you’d replace this with the IP address(es) that you use to send using the IPv4 tag. Refer to the https://mxtoolbox.com/spf.aspx for details, there’s lots of free SPF record generators to help you build this up. More information here: https://support.google.com/a/answer/10685031
The ~all defines the “fail state” the possible options are as follows:
- ?all = Neutral, don’t use in production it says I don’t know if these are my sending servers. Just to check your syntax of the record is correct really.
- ~all = Softfail, says to the recipient server, this is probably all the correct servers, so treat as Quarantine.
- -all = Hardfail, says to the recipient server, these are only the IP addresses we send email from, treat anything else as Reject.
That’s it, wait a day or so for DNS and that record will be there and working.
Setting up a DKIM Record
Here you have three steps to do, this can take a couple of days to complete as you’ll be waiting for DNS to propagate ideally.
Step 1 – Set Google to generate you a DKIM key
Sign in to your Google Workspace Admin console, then select Apps -> Google Workspace -> Gmail -> Authenticate email
Select your domain from the drop-down list and click the Generate new record button.
Copy the generated text.
You can’t click “Start Authentication” yet, you need to wait for the DNS changes to complete first!
Step 2 – Add the DKIM record with the key to your domain
Logon to your DNS provider.
Create another TXT record as follows, put in place the key after the “p=” as what is generated for you.
google._domainkey.<yourdomain>
TXT
v=DKIM1; k=rsa; p=<big long string key>Note that unlike the SPF record, you need to add the google._domainkey bit in the “host name” field. The “google” bit is a selector, this allows you to have multiple keys published and allows you to identify them. Again using a tool like: https://www.dmarcanalyzer.com/dkim/dkim-checker/ can help you check its correct.
Step 3 – Set Google to use this for sending (once the DNS has propagated)
Finally within the Google menu you generated the key click on “Start Authentication”, if all is well with your DNS configuration, this will accept without an error message. Now you’ll be sending emails with the DKIM key applied! Harrah!
Setup the DMARC Record
DMARC is a DNS record with two parts. Domain-based Message Authentication, Reporting and Conformance – record.
Because DMARC is built on both SPF and DKIM technologies, you will need to ensure you have completed SPF and DKIM before applying this record, well completed if you intend to use anything but the “None” posture.
A DMARC record has many settings, you use refer to https://mxtoolbox.com/dmarc/details/what-is-a-dmarc-record for full details.
DMARC provides a place you can put in settings for reporting, you require an email mailbox for collecting these alternatively you can use a paid-service to collect these messages for you, these can give you really nice views of where your email is being used that you don’t get looking through loads of XML in a mailbox.
If you don’t want a paid for service and are happy to go through the emails, just create an email alias, and then a filter on your email mailbox, or if you have spare licences, create a mailbox user to receive these reports directly.
Google provide some really good information on this here: https://support.google.com/a/answer/10032473 but I give you three examples below for three possible stages:
None – Reporting Posture
Just reports back to the designated email address how messages are being used, doesn’t instruct the recipients server to do anything different.
_dmarc.<yourdomain>
TXT
v=DMARC1; p=none; rua=mailto:dmarc@collectservice.comQuarantine – Quarantine Posture
Reports back and tells the recipient’s server to quarantine 100% of email that fails authentication, you can adjust this percentage with the “pct=” tag see the link above for more details. You’d want to increment this up to 100%.
_dmarc.<yourdomain>
TXT
v=DMARC1; p=quarantine; rua=mailto:dmarc@collectservice.comReject – Reject Posture
Reports back and tells the recipient’s server to reject 100% of email that fails authentication, you can adjust this percentage with the “pct=” tag see the link above for more details. You’d want to increment this up to 100%.
_dmarc.<yourdomain>
TXT
v=DMARC1; p=reject; rua=mailto:dmarc@collectservice.comAlso although not ideal, the “rua” and “ruf” reporting fields are optional, so you could leave this out, its just not recommended because you can’t see where any issues might be emerging from!
Check all is good with: https://www.dmarcanalyzer.com/dmarc/dmarc-record-check/ and you’re ready.
Conclusion
That’s it, once everything is in place you’ll be all set to have a well secured email domain. If you have a dynamic environment make sure you periodically check the DMARC reporting for sources of email, if someone brings live a new SaaS service and the SPF record, DKIM configuration or DMARC record are not updated accordingly you may find email delivery problems emerge as these messages are incorrectly seen as problematic.
