How to configure SPF, DKIM and DMARC for your domain

1. Login to Hydra DNS records list (requires Oxford network or VPN)
2. Select Create
3. Enter details as follows:
   

   Field	Value
   Hostname	unit.ox.ac.uk
   Type	TXT
   Content	v=spf1 redirect=_spf.ox.ac.uk
   TTL	300

4. Select Create
5. Test that you now have a valid SPF configuration using an online tool such as MX Toolbox SPF checker

1. Ensure that you understand how DKIM works, and how it is implemented in your system. You will need to know how the DKIM selector is set for your system, and how to generate / obtain a DKIM key
2. Configure or confirm the DKIM selector for your system
3. Generate and configure, or obtain, a DKIM key for your system
4. Create the required DKIM record in DNS for your domain using Hydra IPAM, for example:
   

   systemk._domainkey.unit.ox.ac.uk TXT v=DKIM1;p=MIIE9lry7oA1jhH4S9H3qTjo...

5. Enable DKIM on your system

1. Do not configure a DMARC record for your domain(s)

We strongly recommend that you do not configure a DMARC record for your domain(s). Recipients should then check for a DMARC record in the parent domain, ultimately applying the DMARC configuration for ox.ac.uk.

The DMARC configuration for ox.ac.uk is set in our DNS. You can check this at any time using a DNS lookup; On 28/02/2024 it was set to:

_dmarc.ox.ac.uk TXT "v=DMARC1; p=quarantine; pct=0; rua=mailto:dmarc-rua@dmarc.service.gov.uk"

The presence of this record requires recipients to run SPF and DKIM validation checks, and if either fails then this is reported to a service that we can use to detect and take action against unauthorised senders. Mail is not blocked, even if it fails these checks.

If you absolutely require a different configuration then please make sure that:

1. You have a comprehensive understanding of SPF, DKIM and DMARC
2. You configure a valid DMARC record
3. Whoever monitors your configured reporting service is aware and has agreed to the potential reporting volumes your change may trigger.

You can check the DMARC configuration for your domain using an online tool such as the MX Toolbox DMARC checker

Preferred method: send via an Oxford mail service

The best way for a third-party system to send mail from an Oxford address is to use one of following two options:

1. Set up a dedicated generic Nexus365 mailbox and configure the third-party system to send through that
2. Set up a dedicated SSO-only account and configure the third-party system to use this to send using the message submission service

Fall-back method 1: authorise third-party to send from your domain using DKIM

If the third-party you are using does not support properly-authorised sending via Nexus365 or Oxmail (message submission) but does support DKIM message signing then the following steps will authorise your third-party as a sender of messages from your domain.

1. Ensure that you have a good understanding of DKIM and DMARC
2. Configure DKIM message signing in your third-party service. This will normally involve enabling DKIM, setting / confirming the DKIM selector and generating / obtaining a DKIM key via the web admin interface
3. Create the required DKIM record in DNS for your domain using Hydra IPAM, for example:
   

   saasxmpl._domainkey.unit.ox.ac.uk. TXT v=DKIM1;p=MIImxJCfLeSbBMI4CSmTIQo...

Fall-back method 2: authorise third-party to send from your domain using SPF

In this situation you can configure SPF by:

1. Ensure that you have a good understanding of SPF (see SPF Project resources) and DMARC
2. Liaise with your local IT team to agree whether this can be setup on an existing mail domain or needs to be setup on a separate subdomain
3. Work with your local IT team to setup the agreed domain to receive mail, if required. (If mail is sent with an address like noreply@subdomain.unit.ox.ac.uk then mail reception is not required - this significantly reduces the work required to setup a subdomain for the supplier)
4. Work with your supplier to configure your system to send mail from the agreed domain
5. Obtain an SPF inclusion clause from your third-party. This should be in the form “include:saas.example.com”
6. Ask your local IT team to add the supplier's SPF clause into the SPF DNS record for the agreed domain using Hydra IPAM. For an existing domain this will typically require insertion of the additional clause between v=spf1 and any other specifiers. For example:
   

   unit.ox.ac.uk. TXT v=spf1 include:saas.example.com redirect=_spf.ox.ac.uk

Note 1: SPF, DKIM and DMARC are entirely controlled via your DNS records and third-party system configuration. IT Services does not have access to either of these, so if you need assistance then we recommend consulting the IETF RFCs for each standard, reviewing message headers using the message header analyzer and working with your third-party to review log messages.

Note 2: Some third-party systems simply don't support contemporary methods of sending mail reliably (or at all). We have found some, even large / well-known / expensive, third-party systems that are not able to send mail via Office365 or via SMTP services, and do not support SPF or DKIM. These systems will not be able to send mail from Oxford addresses reliably, and in some cases may not be able to send mail from Oxford addresses at all. Options here are essentially limited to: configure the third-party system to send mail from their own domain (assuming they have SPF, DKIM and DMARC configured correctly), or find another supplier.

1. Send a message from the system that you have configured to an email account that you can access and know how message authentication results are shown (examples are given below for Nexus365)
2. Copy the full message headers into the message header analyzer

3. Check the authentication results from the recipient mail system.

   Messages delivered to an Oxford email account will record the authentication result in the X-TM-Authentication-Results header if the message arrived via our email message security platform, and the Authentication-Results header otherwise (in which case the X-TM-Authentication-Results header will not be present). The authentication results will show "spf=pass" and "dkim=pass (signatures verified)" if all is well.

   Other mail systems will tend to be similar, using either the Authentication-Results header or something with a similar name.

4. If the message from Step 1 has not arrived after 24 hours then you will need to investigate from the sending system side

SPF records were centrally added to all top-level domains (unit.ox.ac.uk) in 2016. This was a one-off exercise, and we recommend that local ITSS add the default SPF record to any domains they use in email sender addresses.

Some background on why we introduced SPF records, and their impact in relation to some ISP mail providers and common scenarios is available in the ITSS wiki.

Please do ensure that you understand SPF before amending records, as even a syntactically correct entry can render your entire SPF invalid. Consult a suitable SPF guide or the associated RFC for details.