How to integrate third-party systems with Oxford email

Recommended solution: connect to an Oxford mailbox 

In general, the best solution overall is to set up a dedicated Nexus365 mailbox and configure your SaaS solution to use this for sending and receiving email. 

Your local IT team can request a mailbox for this purpose. 

Your SaaS provider should be able to guide you or your local IT team through the process of configuring the mailbox connection. This will need to use an Exchange Online connection, or a Microsoft SMTP connection if your SaaS solution only needs to send messages. As of 31st January 2023 Microsoft security policy requires modern authentication (typically OAuth2). 

Alternative solution: use a dedicated service domain (send only) 

If your SaaS provider does not support Exchange Online or Microsoft SMTP connections then an alternative is to configure a dedicated domain for the service.

As an example, suppose you wanted to adopt the fictitious “Admin Day” platform for use within the Food Technology Department whose domain is food.ox.ac.uk.

You would need to: 

1. Configure a domain based on the service and department domain such as "adminday.food.ox.ac.uk"

2. Add a DNS TXT record for your domain to provide an SPF policy that permits your SaaS provider’s servers to send from this domain.

   Contact your SaaS provider for details, however we recommend that you always permit sending from Oxford mail hosts and configure the terminal (catch-all) mechanism to fail sending from any servers that are not explicitly permitted. A typical DNS TXT record for adminday.food.ox.ac.uk will therefore look like "v=spf1 include:_spf.ox.ac.uk include:spf.mail.adminday.com -all"

3. Add a standard Oxford MX record for this domain (technically this is not required and all mail to the domain will be rejected, however some systems require an MX record to exist)
4. Configure your SaaS tool to send email from an address in this domain such as "noreply@adminday.food.ox.ac.uk"

Alternative solution: no integration 

Using an Oxford domain for communications from a SaaS solution may seem attractive, and gives the impression of trustworthiness. However, done badly this can adversely affect the reliable delivery of mail for all addresses in your department, and reduce trust in your domain via global email reputation services. 

If the use of an Oxford domain is not essential to your service, then it may be cheaper, easier and more reliable simply to allow mail to be sent from your SaaS provider’s domain. This also ensures that any support issues are the responsibility of one organisation that has access to the diagnostics and configuration required to resolve them. 

Further information 

Some SaaS providers may advise you to configure an SPF record on your department domain, referencing their SPF record. We do not support this configuration and strongly advise against it, for the following reasons: 

1. Any address in your domain can now be spoofed by any of your provider’s servers referenced in their SPF record. This means that if an unauthorised party gains access to your provider’s infrastructure they can send messages from your domain that your SPF record validates as being genuine 
2. Errors in your provider’s SPF policy can invalidate all email sent from your domain. This includes syntax errors and exceeding the SPF limit on DNS queries to resolve hostnames, includes and redirects. If your provider’s SPF record cannot be found in DNS this also constitutes an error 
3. Many SaaS providers use public messaging services such as SendGrid or AWS mail. This typically means that you are actually authorising anyone else using those services to send mail from your domain