Email Authentication - Help

When set up correctly, email authentication greatly improves the odds that emails from legitimate senders reach the recipient's inbox. If an email is missing authentication, it may be flagged as spam or not delivered at all.

 

Who needs to be concerned with authentication

Campus senders who use a CU Boulder-provided technology platform (e.g., Microsoft Outlook, Canvas, eComm's Marketing Cloud instance; view the full list) don't need to take any action; their messages are properly authenticated.

Those who may need to act are campus senders who use a messaging or workflow platform that's not supported by CU Boulder (i.e., a third-party platform) like Mailchimp, Constant Contact, InfoEd or Flywire.

Between August and October 2024, OIT contacted and worked with 99% of the identified legitimate campus senders failing DMARC; however, some address owners and third-party vendors either could not be identified or, in the case of external listservs, fell outside of CU Boulder's sphere of influence.

Ultimately, it is the sender's responsibility to comply with the campus eCommunications policy and ensure that the messaging or workflow platform they're using adheres to authentication standards.

 

What the primary authentication methods are

Email authentication, also known as email validation, is a collection of methods that help protect email recipients and senders from phishing and spoofing attempts by using DNS records to verify the identity of a sender.

The authentication methods that are used in conjunction with DMARC (login required) are DomainKeys Identified Mail (DKIM) and Sender Policy Framework (SPF).

DomainKeys Identified Mail (DKIM)

With DomainKeys Identified Mail (DKIM), your email provider creates a public/private key pair for your domain. The public key is published in your domain's DNS record, but the private key is kept secret.

When your email provider sends a message on your behalf, it takes your message, runs it through that private key, and generates two signatures: One that certifies the email came from your domain and one that can be used to confirm the content of your message wasn't altered.

The receiving email server will read your DKIM signature headers, query your domain's DNS record to get your public key, and then run your message through that public key to see if it matches the signature headers.

Spammers don't have your private key, nor can they alter it; therefore, any attempt to spoof your domain should fail a DKIM check.

Sender Policy Framework (SPF)

With Sender Policy Framework (SPF), the domain owner publishes a set of IP addresses in the domain's DNS records to indicate which mail servers are authorized to use "envelope from" addresses in that domain.

While this policy ensures the sending mail server is authorized to originate mail from that domain, it only applies to the sender listed in the "envelope from" field, which recipients typically don't see.

To authenticate the email address that recipients see in the "from" line, domain owners must leverage other methods, like DKIM or DMARC.

 

How to check your authentication status

If you're not sure whether your email domain(s) pass SPF or DKIM authentication, follow the instructions on the free Learn and Test DMARC console to send an email to that system and view your authentication results.

If you need help interpreting your results, please send them to (link sends email)oithelp@colorado.edu with "DMARC test results" in the subject line.

 

Authentication recommendations

Both SPF and DKIM are important for improving email deliverability and protecting against email spoofing and phishing attacks. Implementing both can significantly enhance your email security.

That said, only one authentication method is necessary when used in conjunction with DMARC, and OIT recommends that currently unauthenticated campus senders adopt DKIM authentication.

Here's a brief overview of how each method contributes to specific objectives:

BenefitDKIM authenticationSPF authentication
Email authentication – Helps verify that an email was sent from the domain it claims to be from.Yes – DKIM uses cryptographic signatures to prove that the signer is a domain owner and that the "from" domain hasn't changed since the signature was applied.Mostly yes – SPF verifies that the IP address of the sending server is authorized by the owner of the domain in the "envelope from" domain, which might not match the "from" domain.
Integrity check – Helps ensure that the email's content wasn't altered in transit.Mostly yes – The receiving server can use the DKIM signature to validate content to the degree allowed by the signer.No – SPF can't be used to indicate whether an email's content has been tampered with.
Improved deliverability – Improves the likelihood that an email will be delivered to the recipient's inbox rather than being marked as spam.Yes – Emails with valid DKIM signatures are less likely to be marked as spam.Mostly yes – Legitimate emails using SPF can sometimes be marked as spam when forwarded.
Reputation management – Helps build a positive reputation for your domain, which can improve email deliverability and trustworthiness.Yes – DKIM's digital signatures send stronger trust signals, reduce spam classifications and provides consistent authentication even when emails are forwarded.Mostly yes – The limitations documented for the other benefits work to limit SPF's ability to build a positive reputation without DMARC.
 

How to authenticate your sends

Set up DKIM authentication

As described above, OIT recommends that currently unauthenticated campus senders adopt DKIM authentication.

Follow these steps to set up DKIM for messages sent using a third-party platform (e.g., SendGrid, Mailchimp):

  1. Check your vendor's support documentation for DKIM configuration instructions.
  2. If you need to contact their support team, feel free to use the email template below. If they ask for instructions, you may send them the following link: Instructions for admins with DNS records access.
  3. Once you have the DKIM information, send it to (link sends email)oithelp@colorado.edu with "DKIM record" in the subject line.
  4. Please allow 1–3 business days to finish setting up your authentication.
Vendor email request template

Subject: DKIM record request for [domain; e.g., colorado.edu]

Hi [Support Team],

I'm writing to request a DKIM record for our domain, [e.g., colorado.edu]. We're using [service/platform] to send our emails, and we need to set up DKIM to enhance our email security and deliverability.

Once created, please send us the DKIM record details (e.g., CNAMEs) so we can get them added to our domain's DNS records. If you need us to complete any steps or provide additional information, please let us know.

Instructions for admins with DNS records access
DKIM TXT record

First, you'll need to create a TXT record. Here's an example:

default._domainkey.example.com IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9..."

See the table below for a breakdown.

Example elementDescription
defaultThis is the selector. It allows multiple keys to be used for different purposes (like rotation).
_domainkeyThis is a fixed part of the DKIM specification.
example.comThis is the domain of the sender.
IN TXTThis indicates that the record is a TXT record.
"v=DKIM1; ..."This part contains the version, key type, and public key (truncated here for brevity).
DKIM CNAME record

Next, you'll need to create a CNAME record. Here's an example:

Type: CNAME
Name: 'selector._domainkey.colorado.edu'
Value: 'selector._domainkey.mailprovider.com'

See the table below for a breakdown.

Example elementDescription
TypeThis indicates that the record is a CNAME record.
NameReplace "selector" with the specific selector provided by your email service provider and "colorado.edu" with your domain, if it differs.
ValueThis value should point to the DKIM public key provided by your email service provider ("mailprovider.com").

Once created, send the CNAME record(s) to the account owner so they can get the record(s) added to their domain's DNS records.

DKIM-Signature

Once implemented, the DKIM-Signature will appear in sent email headers. Here's an example:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=example.com; s=default; h=from:to:subject:date; bh=abc123...; b=def456...

See the table below for a breakdown.

Example elementDescription
v=1DKIM version.
a=rsa-sha256The algorithm used to create the signature.
c=relaxed/simpleCanonicalization methods for headers and body.
d=example.comThe signing domain.
s=defaultThe selector used to find the public key.
h=...The headers that were signed.
bh=...The hash of the email body.
b=...The actual signature.

Set up SPF authentication

While OIT recommends that most campus senders adopt DKIM authentication rather than SPF authentication, SPF may be more appropriate for your particular use case.

Follow these steps to set up SPF for messages sent using a third-party platform (e.g., SendGrid, Mailchimp):

  1. Check your vendor's support documentation for SPF configuration instructions.
  2. If you need to contact their support team, feel free to use the email template below.
  3. Once you have your vendor's IP addresses, send them to (link sends email)oithelp@colorado.edu with "SPF authentication info" in the subject line.
  4. Please allow five business days for OIT to finish setting up your authentication.
Vendor email request template

Subject: SPF authentication request for [domain; e.g., colorado.edu]

Hi [Support Team],

I'm writing to request a list of the IP addresses used to send mail from our domain, [e.g., colorado.edu]. We're using [service/platform] to send our emails, and we need to set up SPF to enhance our email security and deliverability.

If you need us to complete any steps or provide additional information, please let us know.

 

Get Help

If you have administrative rights to a third-party service and need help authenticating your messages, contact the IT Service Center at 303-735-4357 or (link sends email)oithelp@colorado.edu.