An SMTP relay allows Campus servers and devices to programmatically send mail from their applications to their target users without having to run their own mail server. SMTP relaying is necessary when your server, application or device is unable to authenticate to smtp.office365.com and you need to send email programmatically to recipients that are off-campus and the list of recipients may not be known before the email is generated. This service is limited to campus IP space and is protected by the campus firewall to insulate it from potential spammer access.

If you are an application administrator you should first evaluate whether you could use an OAuth connection to connect to a Microsoft 365 account via IMAP, POP or SMTP. See Microsoft documentations: Authenticate an IMAP, POP or SMTP connection using OAuth.

• The unauthenticated relay is only available to systems, services or devices that are located on campus and sending email in support of UW-Madison Teaching, Research or Administrative activities.
• Only paid UW-Madison faculty or staff may request access to the unauthenticated relay services.
• Server and Service Owners must follow the UW System guidelines for Acceptable Use of Information Technology Resources.
• Campus partner mail servers or servers that accept mail submissions on port 25 should not use the unauthenticated relay service.
• Unauthenticated relay services is not available to end user workstations.
• Use of the service is explicitly prohibited for sending spam, phishing or email with offensive content.
• The relay service should not be used to send unencrypted HIPAA protected data (Protected Health Information, PHI) to non-UW-controlled email addresses. For more information, see UW-Madison Policy regarding Email Communications Involving Protected Health Information.
• If the University receives a credible report that a violation of the Terms of Use has occurred, or if, in the course of managing the service, discovers evidence of a violation, then the matter will be referred for investigation, University disciplinary action, and/or criminal prosecution.

An SMTP Relay request is only necessary if your application or device is sending email to recipient addresses not hosted in our UW-Madison Microsoft 365 or Google Groups environment. If your application is hosted on campus and you are only sending to UW-Madison M365 or g-groups.wisc.edu recipients then you may use the smtp.wiscmail.wisc.edu service without submitting a request.

To submit a request for SMTP relaying for a new IP address, fill out our SMTP Relaying request form.

If you are the admin of record for a relay you can make changes or delete an existing relay IP here List Relays.

Relay IPs that are unused for an extended period of time will be removed from the relay table.

Please contact the DoIT Help Desk with any other questions regarding relay requests.

Once your IP is allowed to relay, you may use the following configuration to relay email.

• SMTP Server: smtp.wiscmail.wisc.edu
• SMTP Port: 25
• Id/Password: This is not used. Please leave blank.
• TLS/SSL: Enabled (where possible)
• From Address: You must use a valid From address. This address should be a name@domain.wisc.edu account that is hosted within the UW-Madison Office 365 tenant.

Important: The HELO/EHLO domain used by the application, server or device can not contain the & character

Note on TLS/SSL support: The unauthenticated campus relay service currently supports TLS 1.0, 1.1 & 1.2. In the future TLS 1.0 & 1.1 will be deprecated but no date has been set. Encrypted communication is required for sending mail to certain external domains (e.g. uwhealth.org). For the full list of domains that require TLS see: Microsoft 365 - Email Domains that Require TLS.

There is currently no functional difference between using smtp.wiscmail.wisc.edu or relay.mail.wisc.edu for relaying mail.

Relay mail may be sent from the following IP addresses:

• 67.231.145.152
• 67.231.153.115

These IPs are represented in our published SPF record

The SMTP Relay service offers opportunistic TLS through support of the STARTTLS command which offers a way to upgrade a plain text connection to an encrypted connection. SMTP Relay also forces TLS communication to certain external domains. For the full list of domains that require TLS see: Microsoft 365 - Email Domains that Require TLS.

The unauthenticated campus relay service currently supports TLS 1.0, 1.1 & 1.2. In the future TLS 1.0 & 1.1 will be deprecated but no date has been set.

Yes. See: Microsoft 365 - What are the limitations for message size, recipient number, and mailbox storage?

No, the unauthenticated relay service is not available to off-campus infrastructure. We now offer an Authenticated SMTP Secure Email Relay Service. That service is available to off-campus systems such as applications built on AWS EC2 instances, Lamdba serverless functions, or other 3rd party services. See SMTP Authenticated Secure Email Relay sending for more details.

In some cases it can, but it also further complicates matters. Since the relay service effectively bypasses domain-level authorization of use of email addresses, it would be covering up the forging problem that DMARC would otherwise solve. We need to ensure that the systems we allow to relay have some level of control over who is allowed to send as arbitrary email addresses. We recommend that you consult with us to ensure your messages are DMARC compliant: Microsoft 365 - Email Authentication (DMARC) Introduction.

All email that passes through the campus relay service is DKIM signed for the relay.mail.wisc.edu domain. The relay service does not support custom DKIM signing for specific domains. The application sending the mail will need to DKIM sign those messages if you need to sign for a different domain.

1. Third party email service providers are not allowed to use the @wisc.edu domain they can only be configured to use subdomains of wisc.edu (e.g. mailplus.wisc.edu).
2. For assistance with evaluating whether your email service provider is DMARC compliant, please see: Microsoft 365 - Email Authentication (DMARC) Introduction
3. For more information about DMARC and Email Authentication see: Trust in Email Begins with Authentication

If you are sending newsletters, calls for research participation, surveys or other forms of bulk mail, your messages need to offer support for one-click unsubscribe. Your application will need to add the appropriate headers to the email messages and handle unsubscribe requests. This is not a feature of the relay service.

Any abuse of this service will result in removal of relaying privileges for the offending IP address.

If you have any questions, please contact DoIT Help Desk.