Email Fraud Defense

Sender Policy Framework (SPF) allows a domain to define which mail systems are permitted to send emails on its behalf. SPF records may contain the mail system IP addresses of its domain as well as those of its partner domains that are trusted to send emails as the domain (such as a vended email system or a constituent relationship management (CRM) service like Salesforce). The SPF record is published in the domain's DNS records. An email server will query the SPF record from the domain's DNS records when it receives an email message with a sending address from that domain. A match authenticates the message as having originated from a trusted source on behalf of the sending domain.

Using DomainKeys Identified Mail (DKIM), a domain provides a cryptographic signature in email messages it sends, and that signature can then be verified via a DNS record containing the public key. The DKIM signature contains both a domain identifier for the hosted public key record to query from DNS, and the selector to uniquely identify the email messages signed. This DKIM signature is added to the email headers of signed email messages.

A domain may publish multiple DKIM keys, and a domain may have multiple selectors. This permits the domain to configure multiple keys to distinguish and manage sending from different accounts and email servers. An email server receiving a signed email message will query the public DNS record according to the DKIM signature to verify that the domain from which it is purported to have been sent matches the signature.

Domain-based Message Authentication, Reporting & Conformance (DMARC) uses SPF and/or DKIM to verify that received email messages "align", and it also tells receiving email systems what action to take with received email messages based on what the domain publishes in the DMARC record. The DMARC record is published to the domain's DNS records. Without a DMARC record, email systems will act independently. Having a DMARC record puts the domain in control of how email messages are handled by other email systems.

DMARC permits a domain to tell email systems what to do with messages that do not "align" with their SPF and/or DKIM records. The three permitted options are:

• Take no action: This option is often implemented during the information-gathering phase to collect reporting data from other domains about email messages being received.
• Quarantine: This option recommends marking messages that do not align with SPF and/or DKIM as spam.
• Reject: This option advises email servers not to accept email messages that do not align with SPF and/or DKIM.  

DMARC at UC San Diego

In order to reduce phishing and expansion on email security, Information Technology Services has implemented DMARC.

From early 2019, ITS monitored ‘unauthenticated’ email from the core @ucsd.edu email domain. This allowed ITS identify sources of email using our domains, sort those sources for likely legitimate senders, and then work with the senders to properly authenticate the use of the @ucsd.edu for DMARC compliance.  

In January 2020, DMARC was implemented in ‘quarantine’ mode.  This means that @ucsd.edu email from unauthenticated sources will likely be classified as spam. ITS is closely monitoring for legitimate email coming from unauthenticated sources and will work with identified departments.

Examples of External Email Services That Need Authentication

• Constant Contact
• Sendgrid
• MailChimp
• MyEmma
• Campaign Monitor
• SalesForce
• Other Off-campus servers & services
• Non university mail accounts which ‘send as’ a university email address (using a personal gmail, yahoo, or hotmail account to ‘send as’ @ucsd.edu)  

The easiest solution is authenticated to a campus email relay (smtp.ucsd.edu, outmail.ucsd.edu) to send email.  This will work for the simple cases of using a non-university email account to send-as, but often does not work for a large commercial service.  If you are attempting to authenticate one of these services, please contact ITS (servicedesk@ucsd.edu) with the following information.

• Service/Vendor name (Mailchimp, Constant Contact, etc)
• Service/Vendor website
• Is there a dedicated IP or dedicated range the email will be sent from?
• Number of emails to be sent per year/month/day
• Email address the vendor will send from
• Your contact information

Q: I am not receiving important email from U.S. government agencies, including email from Department of Homeland Security and the National Science Foundation.  I am being told that this is related to a DMARC policy.

A: DMARC was officially required by all U.S. government agencies in October 2018. Although, the implementation has been slow throughout these agencies, the pace has increased over the last six months.  Most of the problems seen by UCSD faculty/staff/students is related to the forwarding of @ucsd.edu email to an external email account (personal gmail, Hotmail, etc). 

It is important for you to know that if your campus email forwards to a personal email account, you may not receive emails from Federal agencies in that forwarded account. Any messages related to grants received, Federal grant opportunities, messages from government employees, etc., will not be delivered to your forwarded address.  Please work with ITS or your local IT support to use a UCSD email account for this correspondence.