What's changing, and why
Imperial currently runs two unauthenticated email relay services:
- automail.cc.ic.ac.uk
- smarthost.cc.ic.ac.uk.
Unauthenticated means any device on the network can send mail through them without proving who it is.
This is a legacy setup and a known security weakness (it's a common way for compromised devices to be used to send spam or phishing mail). As part of ongoing cybersecurity improvements, both services are being switched off by 31 October 2026.
After that date, only authenticated methods of sending mail will work - anything still pointed at the old relays will simply stop sending mail.
If any system, device, script or piece of software you look after sends email automatically (alerts, notifications, reports, newsletters), it must stop using automail.cc.ic.ac.uk or smarthost.cc.ic.ac.uk. Everything must move to an authenticated sending method instead.
This page explains how to check if you're affected and what to do about it.
Am I affected?
This page is for anyone who owns, administers, or is responsible for a system that sends emails.
Examples of these systems include:
- A script, cron job, or application on a server that emails reports or alerts
Lab or building equipment that emails alarms (e.g. freezer temperature monitors, BMS systems). - A cloud-hosted tool (e.g. Mailchimp, a survey tool, a booking system) that sends on your department's behalf.
- A newsletter or bulk mailing sent to staff/students.
- A printer, scanner, or other appliance configured to "scan to email".
Is action needed? If the above applies to you, please follow the guidance on this page.
If none of the above applies to you, for example, you only send email from Outlook or the My Imperial Campus app, then the information below does not apply to you, and no action is required.
Am I using one of the outgoing unauthenticated email relays?
Check the outgoing mail (SMTP) server setting on your device, script, or application. You are affected if it is currently set to either:
- automail.cc.ic.ac.uk
- smarthost.cc.ic.ac.uk
Where to look, depending on what system you're checking:
- Server/script: look at the SMTP host in the application's mail configuration file or environment variables.
- Physical equipment (alarms, printers, sensors): check the device's network/email settings menu, or its web admin console if it has one.
- Cloud-hosted service: check the outgoing mail or SMTP relay setting in the service's admin settings.
Not sure how to check, or don't recognise any of the above? Contact the ICT Service Desk - they can help you identify what your system is using.
What you need to do
Once you've confirmed you're using one of the old relays, you have three options:
- Migrate to an authenticated sending method -You need to keep sending this mail long-term, OR;
- Switch to an alternative service - An existing Imperial-supported tool (e.g. Poppulo for bulk internal mail) already does the job better, OR;
- Turn off the sending function - The mail isn't needed any more (e.g. old alerts nobody reads, a decommissioned system). The mail will stop being delivered after the relays are switched off - there is no automatic fallback.
If you choose option 1 or 2, please see further instructions below on how to find the best authenticated email option for you and how to set it up.
Which option applies to you?
Use the below list to find the right setup guidance for you:
- Client sending - Use for a server, script, or application you manage, sending to Imperial staff/students or external recipients.
- Cloud-hosted services - For a cloud/third-party tool (e.g. Mailchimp) sending as an @imperial.ac.uk address.
- High-volume / internal bulk email - For bulk email to internal Imperial recipients only (e.g. a newsletter.
- Contact the ICT Service Desk directly - For anything that needs to be assessed case by case, as not all equipment supports the required security methods. For example, a lab or building device (freezer alarm, BMS, ensor) that can't be configured for modern authentication.
Now you know the right setup, use the guidance below to set up authenticated sending.
Setting up authenticated sending
- Client sending (servers, scripts, and applications)
- Cloud-hosted services (e.g. Mailchimp, survey tools)
- High-volume and internal bulk email
This is for systems and code you manage directly (not a third-party cloud tool).
- Point your outgoing mail (SMTP) setting to: smtp.office365.com
- Use port 25 or 587
- Authenticate using one of:
- Basic Authentication - a valid Imperial username and password. (See note on Basic Auth below - this is being phased out.)
- OAuth 2.0 – submit a ticket to the ICT Service Desk requesting to register an application in Azure and use it to generate access tokens for sending. Follow Microsoft's guide: Authenticate an IMAP, POP or SMTP connection using OAuth (Microsoft Learn).
Sending as a shared/team address (role account)?
ICT can allow a role account (a shared mailbox not tied to one person, e.g. labalerts@imperial.ac.uk) to send mail, as long as that account has been granted send rights on the mailbox. Contact the ICT Service Desk to request this.
Using a standard email client (Outlook, mobile mail app)?
No action needed - supported clients already use Modern Authentication automatically.
Basic Authentication is also being retired.
Microsoft plans to remove Basic Authentication support entirely in the second half of 2027. If you set up Basic Auth now to hit the October 2026 deadline, you will need to move to OAuth 2.0 before Basic Auth is switched off too. We recommend setting up OAuth 2.0 from the start if your system supports it, to avoid doing this migration twice.
Imperial does not allow new external/cloud services to send mail using an @imperial.ac.uk address directly, for security reasons.
If you have a new requirement to send mail from a cloud-hosted service:
- Submit a new subdomain request form.
- Once the subdomain is set up, ICT will help you configure email security (SPF and DKIM/DMARC) so the external provider is authorised to send from that subdomain.
Only need to send internally (to Imperial staff/students)?
You likely don't need a subdomain at all - use Poppulo, the university's supported internal communications platform.
If you're sending bulk email to internal imperial.ac.uk addresses only:
- Under 10,000 messages/month: use Poppulo - ICT's recommended tool for regular internal bulk email. Account numbers for the High Volume Email service below are limited, so Poppulo is preferred for regular sends.
- Over 10,000 messages/month: request access to the High Volume Email service via the ICT Service Desk. This is an authenticated service requiring at least Basic Authentication.
This service is for internal recipients only - if you also need to send externally, use the client sending or cloud-hosted services as suggested above.
Further support
| Term | What it means |
|---|---|
| SMTP |
The technical protocol used to send email. Your "SMTP server" setting is where your device sends mail to be delivered. |
| Unauthenticated relay | A mail server that will forward mail from any device without checking who it is. This is what's being retired. |
| Basic Authentication | Logging in with just a username and password. Being phased out industry-wide due to security weaknesses (no protection against stolen passwords, no multi-factor authentication). |
| OAuth 2.0 / Modern Authentication | A more secure sign-in method using time-limited access tokens instead of a stored password, and compatible with multi-factor authentication. This is the long-term replacement for Basic Auth. |
| Role account | A shared mailbox not tied to a single person (e.g. estatesalerts@imperial.ac.uk), used so a team or system can send/receive mail collectively. |
| App registration (Azure) | The process of registering your system as a recognised "application" in Imperial's Microsoft Azure environment, so it can be issued OAuth tokens to send mail on its own behalf. |
| SPF / DKIM / DMARC | Email authentication standards that prove a domain has authorised a particular server or provider to send mail on its behalf. Required for any external/cloud service sending as an Imperial address. |
| Subdomain | A prefix added to imperial.ac.uk (e.g. news.imperial.ac.uk) set up specifically so external services can send email without using the main imperial.ac.uk domain directly. |
31 October 2026 - automail.cc.ic.ac.uk and smarthost.cc.ic.ac.uk are switched off. Anything still using them stops sending mail.
Second half of 2027 - Microsoft removes Basic Authentication entirely. Anything still using it stops sending mail unless moved to OAuth 2.0.
What happens if I don't do anything before October 2026?
Mail sent through the old relays will simply fail to send - there's no grace period or automatic fallback. Depending on your system, this may fail silently, so it's worth testing your setup well before the deadline.
My equipment doesn't support Basic Auth or OAuth 2.0 at all - what do I do?
Contact the ICT Service Desk. Older equipment may need a workaround (e.g. sending via a relay that does support authentication) - ICT can assess this case by case.
Do I need to do this twice (once for Basic Auth now, again for OAuth in 2027)?
Only if you choose Basic Authentication now. If your system supports OAuth 2.0, we recommend setting that up from the start to avoid migrating twice.
Is there a cost involved in any of these options?
Most have no cost, but Poppulo requires a licence, and fees are paid locally by your department upon request.
Who do I contact if I'm not sure which option applies to me?
See the above in page options guidance, but if you are still unsureContact the ICT Service Desk.
Need more help?
If you're unsure whether you're affected, which option applies to you, or if you need help setting up authenticated sending, contact the ICT Service Desk.