SCU has worked to improve the security around our email infrastructure, with two goals:
- To assure that messages that are sent by members of the SCU community are reliably delivered; and
- To reduce the number of malicious messages that members of the SCU community receive.
We made two key changes to SCU's email infrastructure in 2020:
We instructed other organizations’ email providers to block delivery of messages from SCU subdomains, for messages that do not pass authentication checks.
- This change will not impact email from standard SCU addresses, like bbronco@scu.edu -- standard SCU addresses do not use a subdomain.
- This change will impact mail sent using SCU subdomains only (for example, lists.scu.edu or engr.scu.edu).
- This change will not impact subdomains that have already been authorized. For example, we have already authorized the subdomains lists.scu.edu and engr.scu.edu.
We instructed other organizations’ email providers to mark as ‘spam’ any messages from standard SCU email addresses (like bbronco@scu.edu) that do not pass authentication checks.
Do you just send email through Gmail?
No action is needed for the messages you send or receive through Gmail or through the on-premise email relay.
Email security tools and SCU vendors
The tools we use to improve deliverability and reduce spam and phishing are DKIM, SPF, and DMARC (more information below). Information about email authentication from the Department of Homeland Security
If you work with a vendor, you may want to send messages from an SCU email address using the vendor’s system. For example, a department may contract with Mailchimp to send messages using their department’s SCU email address, to make the messages more friendly and personal.
In this case, we will work with you, and your vendor, to authorize the vendor’s use of the SCU email address. This will help to ensure your messages will continue to be delivered to your recipients’ inboxes.
If you are working with a vendor, and will be sending email using an SCU email address, extra work is needed to ensure that these messages are authenticated.
If your vendor doesn’t support DKIM, messages your vendor sends using an SCU email address will fail the authentication checks. Email systems that receive these messages should not deliver them to the recipients’ inboxes.
Once we have worked with your vendor to set up DKIM, be sure that you configure your messages to use an SCU email address. If you use the vendor’s email address, your messages may fail authentication checks, and may not be delivered.
DKIM and SPF are tools to identify authorized email senders -- people, systems, or vendors who are authorized to send email using an SCU email address.
SCU uses DKIM (DomainKeys Identified Mail) to cryptographically sign individual email messages. These messages contain a cryptographic signature in the email header. A receiver can authenticate a message by using SCU’s public key to calculate a signature; if the calculated signature matches the signature in the email header, the message is considered authentic.
SCU also uses SPF (Sender Policy Framework) to list the IP address of systems that are authorized to send email on our behalf. A receiver can use SPF to authenticate a message by comparing the sender’s IP address to the listed IP addresses. If the sender’s IP address is listed in SPF, the message is considered authentic.
DKIM is strongly preferred over SPF. SPF allows anyone sending from the specified system to send messages from an SCU email address. This could result in spoofed email, spam, or phishing messages being sent from what looks like a valid SCU system.
DMARC is a tool that tells other email systems what to do with email that says it is from an SCU email address, but the sender cannot be identified as an authorized email sender.
SCU uses DMARC (Domain-based Message Authentication, Reporting and Conformance) to instruct receivers about what to do when a message fails the authentication checks under SPF or DKIM.
One of three actions can be specified for messages that fail the authentication checks:
none - deliver the message to the recipient’s inbox
quarantine - deliver the message to the recipient’s spam folder
reject - block delivery of the message
For SCU, unauthorized messages from subdomains will be rejected; unauthorized messages from scu.edu will be quarantined.
Most modern, well-configured email lists are DMARC-aware; if you do have any issues with messages sent to email lists, please send an email to scu-email-security-questions-pg@scu.edu.
The interctions between email security tools and email lists are described in this article:
https://begriffs.com/posts/2018-09-18-dmarc-mailing-list.html
- Follow these tips from Google for formatting your email message.
- Send your message using your own SCU account, or a Delegated Mailbox you have access to. Do not attempt to emulate another person's account, even if they gave you their permission to do so. This is called "spoofing" and it is a common tactic used in spamming and phishing. These messages are likely to be flagged as potentially dangerous.
Starting April 24, 2023, Gmail began rejecting messages that contain more than one RFC-mandated single instance header in order to better protect against spam and abuse.
If vendors or other institutions send messages with multiple headers, the messages be rejected with the error message: “This message is not RFC 5322 compliant,” starting April 24, 2023.
For context, email headers are a set of lines that precede the body of an email message. They contain information about the sender, recipient, subject, the message's route to the recipient's inbox, and how to interpret the body (text, html, image). They also provide information that can be used to verify the authenticity of a message. Therefore, rejecting messages that contain multiple headers protects you from malicious duplicate header exploitation.
The Internet Official Protocol Standards: Internet Message Formats [Request For Comments (RFC) 5322] states that a message must have at most one instance of each of the following headers:
ToCcSubjectDateFromSenderReply-ToBccMessage-IDIn-Reply-ToReferences