How to configure SPF, DKIM and DMARC for your domain

Expand All

  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

Warning

There must be no more than one SPF policy for a domain, even though you can have as many TXT records as you like. You will need to check this, as well as ensuring that your SPF record is valid syntactically and against other SPF rules; Hydra does not validate TXT record contents and will not advise of any issues.

 

Oxford servers sending via Oxmail

You don't need to configure DKIM message signing on in-house servers sending via the Oxmail message submission service. Oxmail will provide a DKIM signature for any message with an Oxford sender (From) address.

 
  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: authorise third-party to send from your domain

If the third-party you are using does not support properly-authorised sending via Nexus365 or Oxmail (message submission) then the following steps should meet the basic requirements of most recipient mail services.

Warning: This does not guarantee message delivery, and can adversely impact all mail sent from your domain

The changes required below mean that the third-party influences how mail sent from your domain is assessed, and the mail reputation for your domain.

An error in the third-party SPF configuration will cause SPF to fail for ALL mail sent from your domain (not just via the third-party).

 
  1. Ensure that you have a good understanding of SPF (see SPF Project resources), DKIM and DMARC
  2. Obtain an SPF inclusion clause from your third-party. This should be in the form “include:saas.example.com
  3. Create or edit the SPF record in DNS for your domain using Hydra IPAM, and insert 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
  4. 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
  5. 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...

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.