Beginning October 16, 2018 U.S. government agencies will no longer deliver email to forwarded accounts.
The U.S. Department of Homeland Security will fully implement a new Federal directive relating to email delivery on October 16, 2018. Federal agencies are being mandated to follow Binding Operational Directive 18-01 to help ensure the integrity and confidentiality of internet-delivered data.
It is important for you to know that if your campus email forwards to a personal email account, you may not receive emails from Federal agencies in that forwarded account. Any messages related to grants received, Federal grant opportunities, messages from government employees, etc. will not be delivered to your forwarded address.
This will impact forwarding or redirection from within your university account, as well as some Mailing List configurations. Please take steps now so that you will not miss key communications. Turn off forwarding in your MS Outlook email account or any other campus email account. If you use a mailing list for redistribution of email from Federal agencies you will need to configure your list to rewrite the ‘sender’ and deliver the message ‘on behalf of’ the agency. These changes are controlled by sending agency email and DNS servers and university email servers cannot ‘safelist’ or otherwise bypass these rules.
By using only campus email and not personal email to conduct University business you help to protect sensitive University data.
Follow this link to see a web-friendly version of the Department of Homeland Security’s Binding Operational Directive 18-01, “Enhance Email and Web Security”.
Follow this link to read about configuring an email distribution list
Email Fraud Defense at the University of Illinois using DMARC
In order to reduce phishing and expansion on email security, Technology Services will be implementing DMARC (Domain-based Message Authentication, Reporting and Conformance), which provides stronger controls to prevent the illegitimate use of university email addresses. DMARC enables email providers to verify that email was sent from a trusted university address rather than from a spammer, hacker, or another unverified source.
Learn more about DMARC and Email spoofing:
- Email Spoofing (Wikipedia)
- DMARC (Wikipedia)
- What is DMARC, and how does it combat phishing?
- Why is DMARC important?
- DKIM (Wikipedia)
Implementation of DMARC
Technology Services has begun monitoring ‘unauthenticated’ email from core university email domains. This will allow us to identify sources of email using our domains, sort those sources for likely legitimate senders and begin ‘re-configuring’ how we send email for various campus business cases. Resources for configuring email use to properly ‘authenticated’ methods are being made available and departments can reach out to Technology Services for assistance.
We expect to spend most of the next two years carefully working to identify university business processes and communicate the pending changes in email policy before implementing a DMARC ‘reject’ policy. We hope to implement DMARC quarantine or reject policies in spring of 2020. After that change email using certain University of Illinois domains that is not sent by a supported email service will be affected by these changes and will likely have delivery problems.
The final phases of full DMARC implementation runs from March 2018 through June, 2020. During that time, the amount of email that is bounced/rejected from unapproved/unverified services will increase each month:
July/August 2018 : Official campus-wide announcements will be shared, with knowledge base articles and other resources made available. We will begin DKIM signing of key university domains on the Campus Email Relays. We will begin sending invitations to identified university email senders to coordinate changes to email sending, and we will provide campus-wide communications asking users of identified third party services to contact us and begin coordination.
By December 2018 : We intend to address 25% of ‘unauthenticated legitimate’ email begin reported. That means we will work with various campus email senders, and work on solutions for users of key third party services to begin transition email use to known and approved sending sources. We will prepare to move SPF records for key domains from a ‘?all’ stance to a ‘~all’ stance to better identify unknown/unapproved senders using our domains.
By June 2019: We hope to reduce ‘unauthenticated legitimate’ email reports for our key domains by 50%.
By December 2020: We hope to reduce ‘unauthenticated legitimate’ email reports for our key domains by 90%.
By April 2020 : We hope to have identified and resolved 99% of ‘unauthenticated legitimate’ email and begin enabling a DMARC quarantine or reject policy to end fraudulent or unauthenticated use of key university email domains.
Examples of Unsupported Email Services:
Below are examples of third party email services that are not configured to work with the new DMARC controls. We will prepare alternative solutions and create options to work with vendors who can support these requirements.
Other Off-campus servers & services
Non university mail accounts which ‘send as’ a university email address (using a personal gmail, yahoo, or hotmail account to ‘send as’ @illinois.edu)
Third Party applications that do not send emails using the following mail services:
Campus Email Relays
Cloud Emailer Service (new service being deployed to meet this need)
Examples of Supported Email Services:
U of I Gmail accounts using Google’s webmail or smtp servers. New student accounts may be offered on Office365 in AY2019, and support for gmail accounts may be depricated in the future.
U of I Exchange or Office365 accounts
Campus hosts or applications using the Campus Email Relays service
Off-Campus services or hosts configured to use the Cloud Emailer Service
Third Party Email Services that are configured to work with the new DMARC controls (requires Technology Services coordination)
What steps should be taken if you use email services that fall into the “unapproved” category of services?
If you are using an unsupported email service, you should contact Technology Services and consider a new email delivery solution. Through coordination with Technology Services, it may be possible to continue to use your service, and we will work to make transitions to currently supported transitions as seamless as possible.
Contact us via email at email@example.com or by phone (217) 244-7000. You will need to provide the following information:
- Vendor/Service name
- Vendor/Service website URL
- Are you paying for this service?
- Do you have a dedicated IP Address that the emails are sent from?
- Number of emails sent per day/month/year
- Email address domain that the emails appear to be from
- Recipient Types - U of I users only/Non-U of I users/Students/Faculty/Staff/Other
- When was the last time a message was sent using this service/vendor?
Please attach example messages so that administrators can verify.
DMARC Frequently Asked Questions
Question: I received an email from Office 365 stating that an email I sent couldn’t be delivered because the recipient's organization could not confirm that it was "sent from a trusted location." What does this mean?
Answer: You received this email because the recipient’s organization uses a particular email service that does not correctly classify email from U of I.
Despite this message, your email should still have been delivered to the recipient, according to Microsoft Documentation. However, it may have been classified as spam. (You may wish to notify the recipient that the email may be in their spam folder.)
Example: Email from Office 365 is shown in the accompanying image, and references an“SPF (Sender Policy Framework) validation error and an Email Admins Status code: 550 5.7.23
Additional Technical Details
Many organizations are using Microsoft’s email service "Exchange Online" as part of their Office 365 implementation. A lot of Exchange Online implementations co-exist with other email services in what is known as a "Hybrid Environment" -- there is more than one email service in production at the organization. As part of Microsoft’s Exchange Online Protection (EOP) service in a hybrid environment, Exchange Online rewrites email headers as it sends email through its various environments.
Because of this, emails may be improperly evaluated according to DMARC, i.e. emails which are legitimately sent from U of I accounts appear to have come from non-U of I accounts. In effect, by rewriting the headers Microsoft Exchange causes the origin and trusted status of the email to be uncertain.
Microsoft Exchange Online disregards the rejection policy of the sending organization and instead treats the email as spam. According to Microsoft documentation, Exchange Online System Administrators (and recipients) do have some abilities, such as filtering emails, to improve deliverability, but by default the email is delivered as spam.
Note: The automated message sent by Office 365 suggests one particular technical solution to the issue: having the sender’s organization accommodate Office 365 by making a modification to the sender’s SPF (Sender Policy Framework). U of I Email administrators have no plans to implement this SPF modification, suggested by Microsoft, because it means extending trusted status to unverified services.
Links to Microsoft documentation on Office 365 and DMARC
Question: I want to use my personal email account (ex, gmail, yahoo, hotmail, etc.) to conduct my U of I business. Can I just forward my U of I email to my personal account and configure my personal account to send as my illinois.edu address? Will DMARC allow mail to be delivered that I send in this way?
Answer: No, DMARC will reject any mail that you send in that way. Using a non-U of I account to send email from a illinois.edu address is spoofing. The purpose of DMARC is to detect and prevent illegitimate spoofing. So, whereas non-university business email can be forwarded to another account , you cannot send as illinois.edu from that other account.