Implementing SPF, DKIM, and DMARC
If you made it here, you might not be interested in the why’s of implementing the holy trinity – SPF, DKIM, and DMARC – of anti-email spoofing. However, if you’re still uncertain whether you should or shouldn’t, just do it! With the guide below, you’ll see it isn’t all that difficult and when used together, they provide great benefits like brand protection, reducing a phishing attack vector, less chance of your legitimate marketing emails ending up in spam, etc. It also makes you and your domain a better netizen!
Changelog
16Nov2017 – Original post
9Feb2018 – Added DMARC Analyzer as an alternative
This implementation guide assumes none of the various email anti-spam/anti-spoofing security measures – SPF, DKIM, and DMARC – are configured. Every domain can and should have these email protections implemented and not just email sending domains. If the implementer or IT department is unsure of the current domain configuration, please reference the testing guide (another post on this site) to establish the current settings. Nearly all configuration settings for the domain can be determined by examining the DNS records of the authoritative name servers. By using whois (or similar tests), the authoritative DNS servers can easily be identified. Also, note it is common for smaller environments to have SPF or even DKIM unknowingly implemented. The potential for unknown implementations is especially true in Microsoft Office 365 or Google G Suite email environments as both providers configure SPF and DKIM by default, although DKIM may not be enabled. Other, lesser-known hosting environments also add these features on new domains by default so this behavior is not exclusive to Microsoft or Google platforms.
While each environment is a little different, the implementation guide follows these three basic steps found below.
Implementing SPF -> Implementing DKIM -> Implementing DMARC
To yield the highest levels of effectiveness, these steps should occur in order starting with SPF. Although DKIM is not completely necessary to implement DMARC, it is strongly recommended before adding block capabilities to DMARC (Can I Use DMARC, 2016).
Implementing SPF
SPF is the first step in the journey to combat email forgery. SPF provides some level of protection by targeting sender address forgery. SPF is arguably the most effective and easiest component to implement. A simple DNS entry (TXT record) is needed for implementing SPF.
However, to determine the contents of the SPF-related DNS entry, one must first collect information from all the systems and devices that send email on behalf of the domain. Clearly, the mail servers are the most recognizable need. But what about contact forms on the company website? If an email lead arrives from the website for the sales department using sales@<yourdomain.com>, then the IP address or hostname for the web server will likely need to be added. Another common “gotcha” is email marketing campaign platforms such as MailChimp or Constant Contact. Fortunately, MailChimp has a nice tutorial on SPF/DKIM in relation to their service.
Another often overlooked mail sending device or system is the office scanner. These devices are well-known for sending scanned documents as attachments on behalf of the domain. In the case of the office scanner and possibly other systems (such as the website contact form), this might prove as an opportunity to clean up the sending configuration. For example, instead of the device acting as an SMTP server, perhaps it can instead act as an SMTP client. This simple change would eliminate the need to add the external IP address of the device altogether. The system would operate as a standard client similar to how a phone or email client would, which do not require entries in the SPF record.
Scanner SMTP Settings
There are numerous SPF resources to explain the formulation of the SPF string, but by far the easiest is to use SPF Wizard at the site below. The site does a great job explaining what each item means and walks through the entire process of building a TXT record. The SPF creation process is where the previous information gathering pays off.
As shown in the image below, simply answer the questions by typing in values and changing the dropdowns to configure the SPF record for the domain. Though not specified in the wizard, it is worth noting the SPF record cannot exceed 255 characters in length and it cannot have more than ten include statements.
SPF Wizard
For sites using cPanel, the control panel provides a nice interface to generate SPF records and add them. The SPF configuration is under Mail -> Email Authentication in the main cPanel interface.
cPanel – Email Authentication
cPanel – SPF Configuration
The cPanel interface can work well in many instances, although SPF Wizard is still recommended for more complex environments as it explains the options in more detail. For smaller environments, the SPF below (substituting the proper domain name) would work for most setups.
linuxincluded.com. IN TXT “v=spf1 mx a ~all”
This SPF record should be double and triple-checked to ensure no hosts or IP addresses are forgotten. If the SPF record is incomplete, it will likely result in valid emails getting rejected! Also, keep in mind that if those IP addresses or hostnames ever change, the DNS record will need to reflect those changes.
After generating the SPF records, the authoritative DNS server(s) need to have the TXT record added. The DNS entry below shows the SPF record added to the DNS server for the linuxincluded.com domain.
The organization should publish null records for domains that do not send mail. As shown below, the null SPF record simply lacks any records and has the hard fail (-) instead of the soft fail (~) or neutral (?) designations. Even when forwarding a website or domain, a null SPF record explicitly stating there are no authorized senders should be added to mitigate potential email spoofing.
blueteamninja.com. IN TXT “v=spf1 -all”
Records should be tested almost immediately for correctness using online tools such as MX Toolbox. Feedback from technical, non-IT users can also prove to be a valid source of input to ensure the additional record does not disrupt normal email flow. If you are looking for specific ways to test your SPF record, click here.
https://linuxincluded.com/testing-spf-dkim-and-dmarc/
Implementing DKIM
DKIM uses a private key to sign outgoing emails. Receiving email systems then verify the DKIM settings via public keys using DNS. Overall, the goal of DKIM is to allow a receiving email system to determine if an email is authentic.
As mentioned previously, along with SPF, new Office 365 and G Suite implementations have DKIM enabled by default.
Implementing DKIM on Gmail
To ensure DKIM is enabled on a G Suite domain, go to Apps -> G Suite -> Settings for Gmail. If “Authenticating email” is in green, then DKIM is properly configured for the domain. This simple test also verifies if the proper DNS records are in place and whether the public keys match.
If the implementer does not see “Authenticating email,” then DKIM can be enabled by clicking “Start Authentication” in the lower right-hand corner. If the authentication still does not properly start after several hours, then verify the domain key and selector match the TXT record on the authoritative DNS server.
Implementing DKIM on Office 365
To check if DKIM is enabled on an Office 365 email domain, go to Admin -> Exchange -> Protection -> DKIM. If “Sign messages for this domain with DKIM signatures” is set to “Disabled,” then DKIM is not configured on this domain.
Simply click “Enable” if the configuration settings such as DNS are in place. Microsoft does use a slightly different configuration for their DKIM implementation. Instead of requiring the customer to add TXT DNS entries, Microsoft instead uses CNAME records. The Microsoft TechNet documentation at the link below includes these settings and much more. This approach also provides a clever and slightly easier way to change DKIM keys in the future (discussed further in the rotating DKIM keys section below).
Implementing DKIM Using cPanel
On the same cPanel page (Email Authentication) as SPF, one can also find the DKIM settings. Clicking “enable” here verifies all other settings such as DNS are configured. If everything is configured, the status will switch to “Enabled and Active (DNS Check Passed).”
Implementing DKIM Manually
If the organization is not using one of the previously mentioned systems, DKIM can be implemented on nearly every modern MTA. Websites such as Socket Labs can help with generating public/private domain key pairs and the corresponding DNS entry.
https://www.socketlabs.com/domainkey-dkim-generation-wizard/
To avoid using a public website and exposing private keys on systems beyond the organization’s control, any Linux system with OpenSSL can generate public/private RSA 2048-bit key pairs using the two commands in blue below. Note: Though 1024-bit keys are acceptable, 2048-bit are widely accepted and are recommended to provide better security.
--- Create private key --- # openssl genrsa -out dkim_private.key 2048 Generating RSA private key, 2048 bit long modulus .....................................................+++ ............................................................................................+++ e is 65537 (0x010001) --- Create public key from the private key --- # openssl rsa -in dkim_private.key -pubout -out dkim_public.key writing RSA key --- Show newly created public and private keys --- # ls dkim_private.key dkim_public.key --- Show content of public key --- # cat dkim_public.key -----BEGIN PUBLIC KEY----- MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1n3IZLRxS9nGFnsBKwWd smT1vuMzta3QJVuh0vJtKEJO6TRAOswRQh7yYa4dJueTX8lrTNthtD1KtSK1EPyk T4NMXolZl5jZjgRdSQLhmBC2E6eddsP469J6PZRlm79peYDR3g7MBFPBOky2itw8 xVubI6qGuDlZyBkxurauHQqyEI9+FruIjlo7a6ML1CpE+ElRT3YdkQDAnG9j/sIG fbLnjWr6YvMQf1DuihAVlXK0o3aSU6F2sKoVwCQjul0GPGVxmTGMPumWCJccFj7J NKogCWO5p5moFbXAE1yKkKcxS9VOa6qFNs6xRzPyxCW7IHDIC9K7p6QXdQSZb3+k KwIDAQAB -----END PUBLIC KEY-----
The private key is the component that cryptographically signs all outgoing emails. Therefore, the private key needs to be configured on the MTA. Note: The private key should never be shared outside of the organization and it should be handled with the same care as a highly sensitive password. The public key is the piece that needs to be added to authoritative DNS for the domain. The manual keying process does not split the 2048-bit public key into manageable chunks. A manual process of dividing the DNS TXT records must be performed since DNS text fields cannot exceed 255 characters (Generating DKIM Key, 2017). Thus, the DKIM-related DNS entry for the public key above is the same as the entry below when using the selector of “dkim” and with a “split” of exactly 255 characters enforced.
Each outgoing email server should have their own DKIM-related DNS entries. For example, a separate DKIM selector would be used for an outgoing email marketing from MailChimp. The settings for these mail sending systems depends entirely on the sending system. Most services provide documentation on how to implement DKIM with their platform.
As with SPF, DNS records related to DKIM can be tested almost immediately using online tools such as MX Toolbox. If you are looking for more guidance when testing your DKIM configuration, click here.
https://linuxincluded.com/testing-spf-dkim-and-dmarc/
Emails originating from the domain should be tested shortly after initial DNS propagation, which often occurs within minutes but can take several hours. Each selector must be verified individually during the testing process. As with SPF, end-user feedback can valuable. Technical, non-IT users can be a valid source of input to ensure the additional record(s) do not disrupt normal email flow.
Rotating DKIM Keys
DKIM keys should be rotated on a regular basis. The recommended timeframe for key rotation is three months. In most cases, generating a new DKIM key and updating (or adding) the public DNS TXT is all that is necessary. However, this process should be handled carefully as improperly rotating keys can lead to email delivery failures.
As mentioned previously, Microsoft follows a slightly different DKIM implementation by using CNAME records instead of TXT records. Due to this implementation difference, organizations on the Office 365 platform do not need to make any DNS changes when rotating keys and the key rotation is seamless. Microsoft essentially creates a new “selector” (and key) and then removes the old “selector” (and key) after a week.
Implementing DMARC
DMARC utilizes SPF and DKIM to ensure legitimate email authenticates properly. DMARC can also ensure fraudulent emails attempting to spoof your domain are blocked. To pass DMARC checks, an email must pass SPF authentication and SPF alignment and/or DKIM authentication and DKIM alignment. DMARC ultimately allows the organization controlling the domain to decide how receiving email servers should handle messages that fail DMARC – monitor only, quarantine, or reject. Similar to SPF and DKIM, DMARC also leverages DNS for its functionality.
The DMARC implementation process is rather easy, although the full process can take some time to rollout properly. Before starting a DMARC implementation, the administrator must identify which email addresses will receive the daily XML reports. Using a standard email such as postmaster@<domain name> is perfectly acceptable for most domains.
Due to the nature of how DMARC works, the easiest way to start the process is by going through a wizard. The dmarcian website has a complete explanation of the settings to choose when creating a the DMARC DNS record.
https://dmarcian.com/dmarc-inspector/
Aside from the email address to send the reports to, the other key for the DMARC settings is the initial policy for the domain. This “p=” represents the policy setting and its initial value should be set to “none.” This value means do not quarantine or block any emails that fail the tests and instead, simply monitor the emails.
With the default wizard values, the DMARC record will look similar to the one below. This record is the initial DMARC record.
As with SPF and DKIM, the DMARC record should be added to the authoritative DNS for the domain.
Records can be tested almost immediately for correctness using online tools such as MX Toolbox. If you are looking for specific ways to test your DMARC configuration, click here.
https://linuxincluded.com/testing-spf-dkim-and-dmarc/
After adding the DNS record, participating email providers will send nightly XML reports to the specified email address as shown below.
The DMARC policy should become more and more restrictive as reports are received and verified to ensure legitimate email is not blocked. The standard progression should include monitoring, increasing levels of quarantine, followed by increasing levels of rejection.
The table below represents a somewhat conservative deployment suggested by Google (Add A DMARC Record).
| Step | Desired outcome | DMARC Policy Changes |
| 1 | Monitor all | p=none; |
| 2 | Quarantine 1% | p=quarantine; pct=1; |
| 3 | Quarantine 5% | p=quarantine; pct=5; |
| 4 | Quarantine 10% | p=quarantine; pct=10; |
| 5 | Quarantine 25% | p=quarantine; pct=25; |
| 6 | Quarantine 50% | p=quarantine; pct=50; |
| 7 | Quarantine all | p=quarantine; |
| 8 | Reject 1% | p=reject; pct=1; |
| 9 | Reject 5% | p=reject; pct=5; |
| 10 | Reject 10% | p=reject; pct=10; |
| 11 | Reject 25% | p=reject; pct=25; |
| 12 | Reject 50% | p=reject; pct=50; |
| 13 | Reject all | p=reject; |
To ensure legitimate email continues flowing without interruption, a complete DMARC deployment can take months. The length of time on each step depends on the organizational comfort level and the size of the deployment. Smaller environments can likely get much more aggressive. I would suggest a decent amount of time in between steps. For example, even if you are jumping from step 1 to step 7, I would sit tight on step 1 at least a few weeks or possibly even a month. Why? Well, sometimes people only do certain things or send certain things quarterly. 😉 The highest level of protection, found in step 13 above, is not complete until the DMARC policy is set to reject all.
As shown above in the XML example, XML reports can be somewhat difficult to understand. The difficulty of reading XML reports can be even more cumbersome in larger environments. Fortunately, there are ways to ease the burden.
One way is to upload the XML reports to the dmarcian website. No account is needed and it is free for small environments. After a short time processing the data, the report will generate easy to follow graphs and details such as what percentage of emails align with SPF and DKIM.
https://dmarcian.com/dmarc-xml/
Another way to digest the data also comes by way of the dmarcian website. If the implementation has less than 50,000 DMARC-capable emails over a 30-day span, then creating a free account makes the DMARC journey a little easier. The primary differences between a free account and the lowest cost paid account is the inability for emailed reports (from dmarcian) and access to the Forensics Lab. The dmarcian website will accept data by either forwarding the designated email address, e.g. postmaster@<your domain> or by publishing the DNS record with the email address assigned by dmarcian. In either case, the assigned email address is found under the “Add DMARC” option after creating an account.
Although dmarcian is not free for larger deployments, the pricing is very reasonable and it would likely improve the success of the project. The non-free packages also provide added advantages such as support, multi-user setups, and data retention. Note: Another option for long-term analysis is DMARC Analyzer. It has similar features, offers a slightly higher free volume of 100,000 monthly emails, and it does appear to cost less.
https://www.dmarcanalyzer.com/our-pricing/
Some other benefits of all dmarcian accounts (free and non-free) include the policy planner. The policy planner feature provides recommendations as the organization is ramping up toward the reject all policy.
Another feature is the “Threats/Unknown” section of the report. This section can help determine if a domain is being abused or if some legitimate emails do not align with the policies. For example, the report can help identify if the emails from “localhost” warrant further investigation. The report can also help management understand why the anti-spoofing protections are needed.
Going Further – Blacklisting
SPF, DKIM, and DMARC are a great way to eliminate email spoofing for domains the organization owns. Unfortunately, those controls do nothing to block domains utilizing character substitution, character omissions, or homoglyphs.
Blacklisting gets a bad rap because it often does not go far enough and whitelisting is often a far better approach. Normally that is an accurate statement, but this is one example where blacklisting works perfectly. An email administrator can easily create a domain blacklist with a tool that comes by default on Kali Linux called URLCrazy. Using URLCrazy and cut (to the right of the # symbol below), an administrator can generate a list of offending domains that should never be used legitimately. These domains also represent those that would most likely be used in phishing campaigns on the organization.
# urlcrazy –format=CSV linuxincluded.com | cut -d’,’ -f2 |tail -n +2 linuincluded.com linuxicluded.com linuxinclded.com linuxincludd.com linuxinclude.com linuxincluded.cm linuxinclued.com linuxincuded.com ... <- the '...' means $hi+load$ more!!!
Once URLCrazy finishes generating the domain name variations, the list can then be inserted into the company’s anti-spam server or blocklist.
Going Further – Security Awareness Training
The phishing attacks covered by the previously mentioned defenses specifically use the domain name or even variations of the domain name. There are numerous types of other phishing activity these technical controls do not cover. Attacks not covered include sending email from [yourorganization]@gmail.com, [yourhelpdesk]@hotmail.com, or millions of other possibilities — fake UPS or FedEx, fake healthcare.gov enrollments, etc. For those phishing attempts, nothing beats a healthy security awareness program and making sure users know how to tell the difference.
Other Tools
There are numerous commercial tools in the marketplace to assist with the deployment of SPF, DKIM, and DMARC. As shown in the examples, many modern MTAs can easily integrate these anti-spoofing measures. If an off-brand MTA does not support one or more of these components, another option is the GNU-licensed solution, Scrollout. Scrollout can provide any of the features discussed as well as added benefits such as anti-spam using real-time blacklists or spam scoring along with virus scanning and numerous other features.
That’s it! It’s really not as bad as you thought, huh?
Best of luck getting SPF, DKIM, and DMARC implemented in your environments!
References
Add A DMARC Record https://support.google.com/a/answer/2466563?hl=en
Can I Use DMARC If I Have Only Deployed SPF? https://dmarc.org/2017/03/can-i-use-dmarc-if-i-have-only-deployed-spf/
Generating DKIM Key With OpenSSL https://lxadm.com/Generating_DKIM_key_with_openssl
Dallas Haselhorst has worked as an IT and information security consultant for over 20 years. During that time, he has owned his own businesses and worked with companies in numerous industries. Dallas holds several industry certifications and when not working or tinkering in tech, he may be found attempting to mold his daughters into card carrying nerds and organizing BSidesKC.