How to implement SPF, DKIM and DMARC
Sender Policy Framework
Identify outgoing mail servers
Identify your organisation's authorised mail servers, including your primary and backup outgoing mail servers. You may also need to include your web servers if they send emails directly. Also identify other entities who send emails on behalf of your organisation and use your domain as the email source. For example, advertising or recruitment firms and newsletters.
Construct your SPF record
SPF records are specified as text (TXT) records in DNS. An example of an SPF record might be v=spf1 a mx a:<domain/host> ip4:<ipaddress> -all where:
- v=spf1 defines the version of SPF being used
- a, mx, a:<domain/host> and ip4:<ipaddress> are examples of how to specify which server are authorised to send email
- -all specifies a hard fail directing receivers to drop emails sent from your domain if the sending server is not authorised.
It is important to note that you must set a separate record for each subdomain as subdomains do not inherit the SPF record of their top level domain.
To avoid creating a unique record for each subdomain, you can redirect the record lookup to another SPF record (the top level domain record or a special record for subdomains would be the simplest solution).
Identify domains that do not send email
Organisations should explicitly state if a domain does not send emails by specifying v=spf1 -all in the SPF record for those domains. This advises receiving mail servers that there are no authorised sending mail servers for the specified domain, and hence, any emails claiming to be from that domain should be rejected.
Protect non-existent subdomains
Some mail servers do not check that the domain which emails claim to come from actually exists, so proactive protection must be applied to non-existent subdomains. For example, adversaries could send emails from 123.yourorganisation.com.au or shareholders.yourorganisation.com.au even if the subdomains 123 and shareholders did not exist. Protection of non-existent subdomains is provided using a wildcard DNS TXT record.
Warn your users
Ensure users are told of the new SPF email policy so they can report any implementation issues which may arise. It should be noted that once SPF is implemented, emails sent from non-authorised servers, such as those outside the corporate network, may no longer reach their intended destinations. If users are required to send emails while away from the corporate network environment, then provisions should be made for authenticated remote access to an authorised mail server specified in the SPF entry.
Test your SPF record
Testing your SPF record will ensure that emails are processed correctly. Tools such as MX Lookup  can help assess the correctness of SPF records before finalising them. A hard fail policy (i.e. -all) is the preferred approach for SPF. However, while testing, you may wish to use a soft fail policy. This is done by specifying ~all instead of -all in the SPF record. By combining this with DMARC reporting, you can be made aware of potential issues before implementing a hard fail policy.
It should be noted that older methods of forwarding emails (e.g. .forward files on UNIX-based systems) can fail SPF checks if not treated correctly. If this describes your operating arrangement, you may wish to convert forwarded emails to re-mailed emails using Sender Rewriting Scheme (SRS).
Deploy your SPF record
When you have an SPF record you intend to deploy, ensure the Time to Live (TTL) is set low (e.g. 5 minutes). Setting the TTL low will allow you to correct or rollback your SPF record quickly in the case of an issue.
Monitor the success of the SPF record after deployment
When you implement a new SPF record it will take some time before mail servers on the internet recognise it. If you have an existing SPF record this time will be defined by the TTL associated with this record. If you don’t have an existing SPF record, you should review your domain’s ‘start of authority’ to determine the negative cache TTL value, sometimes referred to as ‘minimum TTL’. This number, in seconds, is the maximum time it should take email servers on the internet to detect your new SPF record – a typical default value is 7,200 seconds (i.e. two hours). After you have implemented an SPF record, you should monitor your mail server up to the TTL time and confirm that email delivery is continuing normally. If your SPF configuration is incorrect recipient email servers will begin to reject your email.
Incorporate SPF into the change management process and associated procedures
SPF records will need to be updated when new email sending servers are deployed, DNS entries are added, and DNS entries or IP addresses of sending mail servers change. In such cases, respectively, new servers will need to be added to the SPF record of the associated domains, new SPF records will be required (including wildcard SPF records), and the SPF record of all associated domains will need to be reviewed. It is important that your procedures account for these changes as part of your organisation’s change management process.
For additional information on SPF, see the SPF standard  and its update .
For additional information on how to setup SPF, see Microsoft’s Set up SPF in Office 365 to help prevent spoofing publication  and Google’s Help prevent email spoofing with SPF records publication .
For additional information on SRS, see Microsoft’s Sender Rewriting Scheme (SRS) in Office 365 publication .
DomainKeys Identified Mail
Decide what sections of your email you want to sign
The more sections of an email you sign, the more protected you are from adversaries sending fake emails that appear to come from you. At least the body and the following headers of emails should be signed:
If supported by your email software, it is also important to sign headers one more time than the number of times they occur. A detailed analysis of why this is important can be found in the Breaking DKIM – on Purpose and by Chance publication .
Decide when to sign your outgoing email
DKIM verification may fail if signed sections of emails are changed during delivery. This can happen without the interference of adversaries. For example, if you sign an email but then attach a legal disclaimer, you will likely invalidate the DKIM signature as the content of the email has now changed.
To ensure the DKIM signatures on outgoing emails are not invalidated, you need to understand your email infrastructure and when the content of emails is changed.
A good way to begin a DKIM rollout would be to sign emails as they leave the email gateway and if you run into issues, see how you can modify this approach to accommodate your email setup. In general, signing emails at the last stage before they leave the infrastructure under your control reduces the chance of unintended changes.
Generate your public and private keys for DKIM
You will need to find a tool to generate a public/private key pair. The tool of choice will depend on your organisation, its key management plan and operating system. In the absence of organisation specific tools, there are tools such as PuTTYgen  for Microsoft Windows or ssh-keygen for Linux and macOS. Information on how to use these tools is available in Oracle’s Generating a Secure Shell (SSH) Public/Private Key Pair publication .
After creating the public/private key pair, make sure you protect your private key in accordance with your organisation’s key management plan. If your private key becomes public, any adversary will be able to sign emails as yourself.
You may want to generate multiple public/private key pairs if you want different parts of your organisation to have the ability to independently sign emails.
Publish your public key in your DNS record
Public keys for DKIM are published in DNS TXT records. You will need to include a different TXT record for each private/public key pair you want to use by using a selector. You will then need to configure your mail server to specify the correct selector when sending emails.
Make sure you put the public keys at <selector>._domainkey.yourorganisation.com.au where selector must be different for every public/private key pair. For example you might have brisbane._domainkey.yourorganisation.com.au and melbourne._domainkey.yourorganisation.com.au for different offices in your organisation.
The content of the record itself will be similar to v=DKIM1; k=rsa; p=<your public key>.
Identify domains that do not send email
Organisations should explicitly state if a domain does not send emails by specifying v=DKIM1; p= in the DKIM record for those domains. This advises receiving mail servers that there are no valid public keys for that domain and any emails claiming to be from it should be rejected. This should be done for each domain and subdomain using wildcard DKIM records.
Warn your users
As for SPF, notify users of the change so they are aware and can communicate any unexpected change in email behaviour.
Develop and test your mail server configuration
Using a test environment, identify how your mail server implements DKIM and test your configuration as thoroughly as possible prior to implementation.
Configure your mail server to attach DKIM records to its headers
A phased implementation approach is recommended if your infrastructure layout allows. Immediately after deployment, test that emails are being signed correctly by sending emails to external email accounts and reviewing email headers.
Monitor after deployment
After DKIM has been added, and if you have already configured DMARC, you can use DMARC email reports to verify how many emails are failing DKIM checks.
For additional information on DKIM, see the DKIM website , the DKIM standard  and its two updates  .
For additional information on how to setup DKIM, see Microsoft’s Use DKIM to validate outbound email sent you’re your custom domain in Office 365 publication  and Google’s Enhance security for outgoing email (DKIM) publication .
Domain-based Message Authentication, Reporting and Conformance
DMARC is implemented by publishing a policy as a TXT record in DNS and is hierarchical (e.g. a policy published for organisation.com.au will apply to sub.domain.organisation.com.au unless a different policy is explicitly defined for the subdomain). This is useful as organisations may be able to specify a smaller number of high level DMARC records for wider coverage. Care should be taken to configure explicit subdomain DMARC records where you do not want the subdomains to inherit the top level domain’s DMARC record.
When implementing DMARC, it is advisable to first implement it in monitoring mode, followed by quarantine mode and finally reject mode as the implementation maturity level increases.
You can start your DMARC implementation with a simple monitoring policy for your domain which requests that DMARC capable mail servers send you statistics about emails they see using your domain. You can do this even before you’ve implemented SPF or DKIM in your messaging infrastructure, though until it is in place you won’t be able to move beyond this step.
As you introduce SPF and DKIM, reports will provide the number and IP addresses of emails that pass these checks, and those that don’t. You can then see how much of your legitimate traffic is passing SPF and DKIM checks, and troubleshoot any problems with your SPF or DKIM configuration.
You will also begin to see how many fraudulent emails are being sent, and from where. At this point you should put in place a capability to review reports from recipient mail servers sent in accordance with DMARC configuration to identify malicious activity.
An example of such a DMARC record is v=DMARC1; pct=50; p=none; sp=quarantine; ruf=mailto:email@example.com; rua=mailto:firstname.lastname@example.org where:
- v=DMARC1 defines the version of DMARC being used
- pct=50 specifies the percentage of emails subjected to filtering
- p=none specifies the policy for your organisation domain
- sp=quarantine specifies the policy for all organisation subdomains
- ruf=mailto:email@example.com states the email address to which forensic reports should be sent
- rua=mailto:firstname.lastname@example.org states the email address to which aggregate reports should be sent.
Note, if you plan to send your DMARC reports to a domain that is not the domain for which the DNS record exists, you will need to include a special record in the receiving domains DNS record.
When you believe that all, or most of, your email traffic is protected by SPF or DKIM, you can implement a quarantine policy. This will result in DMARC enabled servers marking emails from your domain that fail verification as spam.
Even if you request that only a small percentage of your email traffic have a quarantine policy applied, you will still get the full statistical reports that show what is happening with your emails. Eventually, as implementation problems are resolved, you can gradually increase your implementation to 100 percent.
Following testing using a quarantine policy, implement a reject policy. This will result in DMARC enabled servers rejecting emails that fail SPF and DKIM verification. Again, you can request that this policy only be applied to a small percentage of your emails (with the remaining percentage being quarantined) and monitor the results through reports. The same gradual increase to 100 percent can be implemented based on reports and feedback from users.
For additional information on DMARC, see the DMARC website  and the DMARC standard . The DMARC website also identifies common mistakes with DMARC records  and includes answers to frequently asked questions .
For additional information and assistance in generating a DMARC record, see the Global Cyber Alliance .
For additional information on how to setup DMARC, see Microsoft’s Use DMARC to validate email in Office 365 publication  and Google’s Enhance security for forged spam (DMARC) publication .