Topics Map > Features and Functionality
Topics Map > Administrators
Requesting SMTP Relaying for sending unauthenticated email
An SMTP relay is used for sending unauthenticated email. SMTP relaying is necessary when 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. To submit a request, fill out the form below.
What is SMTP Relay?
An SMTP relay allows Campus users to programmatically send mail from their applications to their target users without having to run their own mail server. Common uses range from servers that may generate high volumes of mail to low volume printers, scanners and multifunction devices. This service can be used where a smart-host is required. This can be used to send mail to both campus and non-campus mail addresses. This service is insulated from spammers by maintaining a table of IPs allowed to relay.
Office 365 customers may not need an SMTP relay in all cases. If you are an Office 365 administrator, please see the following guide to help determine what option is best for your needs: Office 365 - Options for Individual and Programmatic Sending
Submitting a Request
To submit a request for a new SMTP relay or to change an existing SMTP relay, fill out SMTP Relaying request form.
Once your IP is allowed to relay, you may use the following configuration to relay email.
- SMTP Server: relay.mail.wisc.edu or smtp.wiscmail.wisc.edu
- SMTP Port: 25
- Id/Password: This is not used. Please leave blank.
- TLS/SSL: This is not used.
Important: You must enter a valid From address. This address can be a firstname.lastname@example.org or email@example.com account that is hosted within the UW-Madison Office 365 tenant.
What is the difference between relay.mail.wisc.edu and smtp.wiscmail.wisc.edu
Both relay.mail.wisc.edu and smtp.wiscmail.wisc.edu will allow you to relay mail if your IP is listed in the WiscMail Relay table. relay.mail.wisc.edu is a newer service, which is set up to emit traffic on an alternate set of IPs separate from the traffic being sent by end-user accounts. The reputation of the email traffic relaying through relay.mail.wisc.edu will be better, which should result in a higher likelihood of messages arriving in Inboxes of the remote email services. Unlike smtp.wiscmail.wisc.edu the IP address of the device sending email must be included in the WiscMail Relay table in order to use relay.mail.wisc.edu. This is true even if the email is being sent exclusively to O365/WiscList addresses
Can the relay service be used by off-campus infrastructure?
Yes (AWS only.) In order to ensure that UW-reserved EC2 ElasticIP addresses are not released and reassigned to a non-UW account, you need to set up an AWS IAM permission to allow the DoIT Email service to periodically read the IP address information about your AWS account. Fill out the SMTP Relaying request form to get started setting up SMTP relay integration with AWS EC2 ElasticIP addresses.
Can the relay service be used to bypass DMARC requirements?
No. 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.
How can I achieve DMARC compliance using a SaaS provider without relaying?
- Determine which domains the application will need to send as "From".
- Configure all outbound messages to use addresses within that domain. You don't need the addresses to actually exist within the domain, but it would be best practice if your users use a deliverable address (to catch bounces, etc. See also: this doc )
- Add the SaaS provider's outbound email IP addresses to the SPF record for the domain. We have a new feature in the Wisc Account Admin Site called "DMARC Info" which can help you stage changes to your domain's SPF record.
- Implementing SPF is adequate for DMARC compliance, but you should strive for implementing DKIM in the long term. Encourage your SaaS vendor to implement support for DKIM signing. Feel free to point your vendor at the following documents if they need an industry primer on how to implement DKIM.
If you have any questions or would like to discuss relaying options, please contact firstname.lastname@example.org.