To improve email security and reduce the threat of phishing and spam, major email providers are implementing changes to verify that email is actually sent from the domain it claims to be sent from. Google and Yahoo/AOL have stated that, starting in February 2024, any piece of email that cannot be authenticated will be quarantined (in other words, sent to the recipient’s Spam/Junk Mail folder).
This will not impact most daily communications sent from individuals at Case Western Reserve, but will affect those who send large numbers of emails to groups or large lists of people—for example, those using outside mailing services such as Mailchimp, Constant Contact or other systems.
The new requirements apply to any mail that you send to Google (gmail.com), or Yahoo/AOL addresses.
In technical terms, Google is requiring that email received by Google's servers must be "DMARC compliant" (see below) to be accepted without being quarantined.
See Google's announcement, New Gmail protections for a safer, less spammy inbox, for more details. For additional support Google has added a new further guidance / FAQs posting.
People who are affected
- Use Outlook, Apple Mail or another non-Google mail program (see question 4 for fix)
- Use a 3rd party application or service to send mail, including bulk emails
- Run their own mail server
People who are not affected
- Use the web interface at webmail.case.edu
- Use the Gmail app on their phones or tablets
Enforcement for bulk senders that don’t meet Google’s Email sender guidelines will be gradual and progressive.
In February 2024, bulk senders who don’t meet sender requirements will start getting temporary errors (with error codes) on a small percentage of their non-compliant email traffic. These temporary errors are meant to help senders identify email traffic that doesn’t meet our guidelines so that senders can resolve issues that result in non-compliance.
In April 2024, Google will start rejecting a percentage of non-compliant email traffic, and will gradually increase the rejection rate. For example, if 75% of a sender’s traffic meets Google’s requirements, Google will start rejecting a percentage of the remaining 25% of traffic that isn’t compliant.
Bulk senders have until June 1, 2024 to implement one-click unsubscribe in all commercial, promotional messages.
Email authentication refers to the process of a mail server verifying that a piece of received email actually comes from the organization indicated in the “From” address of the email. For example, if a mail server receives a piece of email with a "from" address of mymail@yahoo.com and that server can verify that the sending server IS actually authorized to send email coming from yahoo.com, that piece of email is considered to be authentic, and the email has been authenticated by the receiving mail server.
Mail servers use both SPF and DKIM (see below) to determine if a piece of email is authentic
The 5,000 emails per day is based on the number of emails sent from a given domain. The number of emails sent from the CASE domain far exceeds this number. So, yes, the new rules will apply to your mail. You may be impacted by these changes depending on how you are sending your email. However, most common user client configurations are not expected to be impacted. Review all the entries in this FAQ to see if your particular situation has been addressed.
The safest way to ensure your email is likely to be delivered is to use the Gmail application or webmail.case.edu to compose and send your mail. When you use either of those methods, you have to log in to your CWRU Google account, and Google automatically does what’s necessary to ensure your email message meets Google’s new requirements.
Other applications should work, as long as you have your settings correct. Make sure the "sending mail server" setting of your application points to smtp.gmail.com. Previous instructions indicated that the sending server should be smtp.case.edu, but that address should no longer be used by mail clients.
In other situations, such as when setting up a phone or desktop mail client like Outlook to send mail, use smtp.gmail.com. You should be asked to "log in" when setting up a client to point to smtp.gmail.com. Use your CWRU account email address (for example, abc123@case.edu) as the user ID.
See Add Gmail to another email client for more information from Google.
Thunderbird and Gmail
Thunderbird Gmail - IMAP vs POP3
Thunderbird Settings
- Outgoing Server: smtp.gmail.com
- Port: 465
- Encryption Method: SSL/TLS
- Authentication: OAuth2
Outlook and Gmail
Outlook Settings
- Outgoing Server: smtp.gmail.com
- Port: 465
- Encryption Method: SSL/TLS
How To Add Gmail Account To
See Example of Outlook Settings:
https://drive.google.com/file/d/1j2lp0vbYJQyayGWaIOMV4XycnSnzcD-a/view?usp=drive_link
For assistance configuring your settings, contact the University Technology Service Desk at 216.368.HELP, help.case.edu or help@case.edu.
If you or your department use a service to send email for university business, you will need to verify that the service or application follows Google’s email sender guidelines so it continues to work properly after the upcoming changes. These services may be mail hosting services like Mailchimp or Constant Contact or any other service that can send mail out with a From address of @case.edu or @cwru.edu. Example: Automated messages that come from filling out forms or when an action is taken, such as registering for an event or making a purchase.
To find out if the service you use is compliant, reach out to the service provider (e.g., Mailchimp) and have them verify compliance with these guidelines. Refer them to Google’s Email sender guidelines and ask to confirm that their service is or will be ready for the changes Google is making in February 2024.
Once your vendor has responded to you regarding whether they are compliant, record their response using the Google Compliance Status form. You may use the Suggested email for vendor document as a template to send to the vendor.
Mailchimp - to learn more about how Mailchimp will be affected by these changes, reference this documentation: mailchimp.com/help/set-up-email-domain-authentication
Constant Contact - to learn more about how Constant Contact will be affected by these changes, reference this documentation: knowledgebase.constantcontact.com/email-digital-marketing/articles/KnowledgeBase/5932-self-publishing-for-authentication?lang=en_US
NOTE: If you are using a case.edu domain to send email via Constant Contact, you MUST self-authenticate with the TXT option. When you have the TXT information, you can submit a DNS record request via the Vendor DKIM Keys Requests form. If you already have an open ticket with the CWRU Help Desk, you can provide the TXT information in that ticket and be sure to provide all the vendor contact information.
If you run your own mail server, then it is your responsibility to get it into compliance. You will need to work with UTech to ensure your mail server follows the requirements for hosting a stand-alone mail server within the CWRU environment. Also refer to Google's email sender guidelines.
In short, to have our emails delivered, we must comply with the standards being set by Google and Yahoo/AOL. Making sure email is authentic makes it, in general, more secure and protects CWRU from scammers and phishing attempts.
SPF, or Sender Policy Framework, describes an authentication scheme that uses the sending mail server's IP address to verify that the sending server is authorized to send email from the domain (the information to the right of the "@" in the email address) indicated in the "from" address of the email address.
Each domain publishes a list of machines authorized to send mail "from" that domain in the domain's Domain Name Service (DNS). The published list can include IP addresses from other domains, such as third-party email senders that the "from" domain wishes to authorize.
DKIM, or DomainKeys Identified Mail, is an email authentication method that uses a digital signature to let the receiver of an email know that the message was sent and authorized by the owner of a domain.
A special key pair, one private and one public, is created and the public key is published in the domain's Domain Name Service (DNS). The private key is used by the email sender to add a DKIM signature into the headers of the mail, and the public key is used by the receiver of the email to verify that the signature is authentic and that the message has not been modified by any of the mail servers through which it has passed on the way to its intended destination.
Alignment means that not only is the SPF/DKIM information valid for the domain from which the email is sent, it is also valid for the domain in the "from" address of the message.
As a simple SPF example, imagine that example.com, a third-party email platform, has published two servers, mta1.example.com and mta2.example.com, in its SPF record. CWRU has published mta2.example.com, but NOT mta1.example.com in CWRU’s SPF record. An end user wants to send an email from their example.com account using the "from" address myaddress@case.edu.
If the mail gets sent from the example.com account through mta1.example.com, while the SPF record is valid for example.com, it is NOT "aligned" because CWRU hasn’t said that mta1.example.com can send messages with "@case.edu" in the "from" in the CWRU SPF record.
The same piece of mail sent through mta2.example.com would not only be considered to be coming from a valid mail server (for example.com) but would also be considered to be "aligned" because mta2.example.com has been published in the CWRU SPF record for case.edu as well.
DMARC, which stands for "Domain-based Message Authentication, Reporting & Conformance", is an email authentication, policy and reporting protocol. It builds on SPF and DKIM protocols, adding linkage to the author ("From:") domain name, published policies for recipient handling of authentication failures, and reporting from receivers to senders, to improve and monitor protection of the domain from fraudulent email.
In order to be DMARC compliant, and therefore acceptable to Google and Yahoo/AOL after February 2024, either SPF or DKIM (or both) must be both valid and aligned.
Unfortunately UTech cannot reach out to the third-party vendor you are using. It is your responsibility to work with them to find out if they are compliant, and if they are not, whether or not they have a compliance plan in place. It is your responsibility to ask the vendor what tasks they need CWRU to complete, if any, to bring their service into compliance.
According to CWRU’s Google representative, these changes will NOT affect mail sent to @case.edu addresses at this time.
To determine if your service is compliant, first check the Third party email systems list. If you do not see your vendor on the list, contact the CWRU manager of the service and ask them if it is compliant.
Unfortunately, in almost all cases, services are set up without UTech involvement. Unless the manager has already reached out to us and placed the vendor on the Third party email systems list we cannot help you with determining the CWRU manager.
DNS Zone Delegation is a process by which an authority over a DNS domain (e.g. Case.Edu or CWRU.Edu) gives authority over a portion of that name space (subdomain) to another.
By using DNS Zone Delegation, CWRU will allow a third party service provider full control of the DNS records for a subdomain that has been delegated their way. This gives the vendor of your third party service the authority to make changes/updates to the DNS records for that subdomain at will.
Zone Delegation example:
Delegating a subdomain of 'alumnievents.case.edu'. to the vendor would allow that vendor to send emails as someone@alumnievents.case.edu
It is desirable to have a combination of SPF + DKIM (Email related) DNS records in place in the name servers that serve up DNS domain names for a zone. Due to the way SPF works, CWRU is at its SPF limit, which only allows 10 includes.
DNS Zone Delegation allows a vendor to serve up their own SPF+DKIM (and any other) DNS records in support of your application, which then bypasses CWRU's SPF record limit issue.
First, make sure that your vendor is able to set up a vendor managed delegated domain.
If the vendor cannot do so, go to the DKIM section of this FAQ and follow the steps listed there.
If your vendor can create a vendor managed delegated domain, gather the necessary information as listed below, then, fill out the following form on behalf of your vendor:
Within the form:
- List your department.
- List an alternate CWRU person in your department who is also familiar with this third party service.
- Provide us with your phone number as well as that of your work colleague.
- List the vendor for your contracted service and two vendor contacts along with their contact information.
- Provide a brief description of the contracted service that your vendor provides to you.
- List the application that your vendor service provides and the email domain that it currently sends email from.
- Determine the subdomain that you wish to send email from.
- Provide the desired subdomain name as well as an alternate subdomain name on the form.
Once your form is submitted, a help desk ticket will be created and you'll be provided with the ticket number.
UTech will update your help desk ticket to let you know which of the two subdomain name's you've requested is available.
Once UTech determines availability of your desired subdomain name, you'll contact your vendor and acquire the names of the name servers CWRU is to delegate your subdomain to.
Vendor Requirements: We require at least two NS records that we will put into our DNS.
You will relay back to us via your ticket the DNS records your vendor has provided to you.
Case Western Reserve University (CWRU) will point the name server (NS) records for the subdomain we are delegating to the name servers you tell us you will be using for the subdomain.
If your vendor CANNOT set up a vendor managed delegated domain they will have to set up DKIM signing.
Placing your vendor's public DKIM record(s) into our name servers will allow your vendor to send email as someone@Case.Edu.
You will need to work with your vendor to acquire the public portion of their DKIM key(s).
First, tell your vendor that the DKIM selector(s) they use must be readily identifiable as being for their service.
A selector like `s2' is not acceptable.
The DKIM selector should be in the form service2 where service is recognizable as their service name.
Also let your vendor know that we require DKIM keys to be a minimum of 2048 bits in length.
Make sure the key(s) they provide back to you are in text format (not a PDF file, or snapshot.)
Gather the necessary keys and information as listed below, then, fill out the following form on behalf of your vendor:
Within the form:
- List your department.
- List an alternate CWRU person in your department who is also familiar with this third party service.
- Provide us with your phone number as well as that of your work colleague.
- List the vendor for your contracted service and two vendor contacts along with their contact information.
- Provide a brief description of the contracted service that your vendor provides to you.
- List the application that your vendor service provides and the email domain that it currently sends email from.
- Attach the DKIM record(s) your vendor has provided to you to the form.
Once your form is submitted, a help desk ticket will be created and you'll be provided with the ticket number.
Once you provide the DKIM key(s), UTech will place the key(s) into our campus name servers to complete the set up.
The services that are currently under review include:
- Salesforce
- Slate
- Qualtrics (surveys.case.edu Only)
- Canvas
- Secure Research Environment
Other services that are in progress can be found in the Third party email systems spreadsheet.
If you cannot find your service on the spreadsheet, you need to contact the manager of the service and inquire as to its current status.
If you are the manager, you will need to verify the status of your service and submit that status to the Google Compliance Status form, and then work to bring that service into compliance.
- You will need to have a gmail.com email address, such as a personal Google account, that you can send mail to and be able to read that mail using Google’s webmail client.
- You must use an @gmail.com address to test this. You cannot use your @case.edu address.
- Send a mail message from the service you are checking to the gmail.com address that you have access to.
- Note: The message should be from a @case.edu or @cwru.edu email address. You may use this technique to check mail from other domains but we can not help you with bringing those domains into alignment.
- When you receive the message use Google’s Analyze Message Header tool as follows:
Analyze an email header
- On your computer, open Gmail
- Open the email that you want to analyze.
- Next to Reply, click "More" then "Show original"
- In a new window, the full header shows.
- Click "Copy to clipboard"
- Open Google Admin Toolbox Message header
- In the box, paste your header.
- Click "Analyze the header above"
- Check the results and look for the DMARC status. If it says PASS you should be fine.
- If you do net get a PASS in the DMARC section, then you need to follow the instructions in the Google Mail Authentication Change FAQ to get your system into compliance.
If these systems are sending email to internal campus addresses, or if those systems are on the 129.22 subnet, they do not need to be registered.
However, if there is a chance that any of those systems will send an email off campus, then yes, you will need to register those systems. Access the following form to register your system(s): DKIM Registration for Email Senders.
At this time, we are unable to DKIM sign messages originating from email addresses that are not user@case.edu or user@cwru.edu. If we can support this in the future, we will make an announcement.