Google Mail Authentication Change FAQ

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 are now in effect.

As of September 2024 all mail sent using a CWRU email address must comply with Google’s new requirements or they will be rejected.

Bulk senders must implement one-click unsubscribe in all commercial, promotional messages. All bulk senders must pass SPF validity checks or Google may delay delivery of those messages, or mark them as spam.

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.

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.

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.

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:

DNS Zone Delegation Requests

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:

Vendor DKIM Request Form

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.

• 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

1. On your computer, open Gmail
2. Open the email that you want to analyze.
3. Next to Reply,  click "More" then "Show original" 
   
   • In a new window, the full header shows.
4. Click "Copy to clipboard"
5. Open Google Admin Toolbox Message header
6. In the box, paste your header.
7. 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 you are dealing with a large number of systems, the most effective way to handle them is to set up a mail gateway that will DKIM sign all messages passing through it, and route your individual servers through that gateway. Such a mail gateway must be secure and approved by UTech before being put in place. A certain level of expertise in setting up mail systems is expected if you plan on setting up your own mail gateway.

UTech offers a DKIM signing mail gateway for use of on-campus mail systems or devices, such as printers, that can not use smtp.gmail.com. Access the following form to register your system(s): DKIM Registration for Email Senders. To use the service once registered and approved, set your outgoing mail server setting to smtp-dkim.case.edu.

UTech is now able to provide limited support for cwru.edu and case.edu subdomains via the DKIM signing service. Access the following form to register your system(s): DKIM Registration for Email Senders. To use the service once registered and approved, set your outgoing mail server setting to smtp-dkim.case.edu.

1. Sign into Mailchimp and select "Domains"
2. Next to your entry for case.edu select "Start Authentication"
3. In Step 3 "Create CNAME record using Mailchimp info"
   1. For "Type" select "CNAME"
      1. For CNAME1 "Name" textbox enter "k2_domainkey.case.edu" and for "Value" textbox enter "dkim2.mcsv.net"
      2. Copy the above values for CNAME2.
   2.  
4. In Step 4 "Create a DMARC record"
   1. For "Type" select "TXT"
      1. In "Host" textbox enter "_dmarc"
      2. In "Points To" textbox enter "v=DMARC1; p=none;"
   2. Leave the "TTL" default value
   3. Click "Save"