Google Mail Authentication Change FAQ

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 (, 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
  • Use the Gmail app on their phones or tablets

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 and that server can verify that the sending server IS actually authorized to send email coming from, 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 5000 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, you may be impacted by these changes depending on how you are sending your email. The new rules will apply to your mail. However, most common user client configurations will probably be ok. 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 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 that the "sending mail server" setting of your application points to Previous instructions indicated that the sending server should be, 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 You should be asked to "log in" when setting up a client to point to Use your CWRU account email address, for example, 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, or

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, ConstantContact or any other service that can send mail out with a From address of or For example, automated messages that are sent after filling out a form 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.

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, a third-party email platform, has published two servers, and, in its SPF record. CWRU has published, but NOT in CWRU’s SPF record. An end user wants to send an email from their account using the "from" address

If the mail gets sent from the account through, while the SPF record is valid for, it is NOT "aligned" because CWRU hasn’t said that can send messages with "" in the "from" in the CWRU SPF record.

The same piece of mail sent through would not only be considered to be coming from a valid mail server (for but would also be considered to be "aligned" because has been published in the CWRU SPF record for 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 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 ''. to the vendor would allow that vendor to send emails as

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 instead.

If your vendor can create a vendor managed delegated domain, gather the necessary information as listed below, then, open a help desk ticket on behalf of your vendor.

When you create a ticket or call the help desk, use the keywords `DNS Zone Delegation' in the ticket title.

Within your ticket:

  • 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 in the ticket

UTech will update your help desk ticket to let you know which subdomain name 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.

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.)

Once you have obtained your vendor's DKIM public key(s), it's time to create a help desk ticket. When you create a ticket or call the help desk to create one for you, use the keywords 'Vendor DKIM Keys' in the ticket title.

Within your ticket:

  • 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

You will relay back to us via your ticket the DKIM record(s) your vendor has provided to you.

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 ( 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 email address that you can send mail to and be able to read that mail using Google’s webmail client.
  • Send a mail message from the service you are checking to the address that you have access to.
    1. Note: The message should be from a or 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" 
    Within Gmail, click on the three vertical dots next to the Reply arrow to select "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.
    Showing the DMARC status of the email
  • 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 or If we can support this in the future, we will make an announcement.