Third Party Email Platforms - Promoting Successful Delivery

Number of views : 23

Article Number : KB0018706

Published on : 2023-07-10

Last modified : 2023-07-10 14:48:02

Knowledge Base : IT Public Self Help

Overview

Many departments have email needs that fall outside of typical use cases for Office 365 or Group Email. For example:

Bulk email/email marketing
- Constant Contact
- Mailchimp
Ticketing/CRM
- ServiceNow
- Salesforce
System generated notification or reporting email
- Amazon SES

To meet these specific needs, departments rely on third party platforms designed with these use cases in mind. These platforms’ email infrastructure typically supports several configurations for sending and securing email. However due to the evolving email threat landscape and the consequent focus on email security (both by senders and recipients), there are best practices when configuring email settings to help improve email deliverability. Not all third-party platforms support every configuration. You will need to consult your vendor’s documentation to determine which are supported.

Why Care About Email Security?

Email is a major attack vector for cybercriminals. As such, UT Austin uses several layers of defense to help protect users against email threats. Other organizations likewise employ email defenses to protect users and infrastructure from malicious or unwanted email. If you want to make sure that your message is seen by the intended recipient, then it is important to understand the email security technologies used by email service providers to determine the legitimacy of a message.

Simple Mail Transfer Protocol (SMTP), the protocol used to send e-mail over the internet, was standardized in 1982 and was not designed with security or even authentication in mind. Since SMTP’s inception, supplemental email security protocols have been adopted in various degrees by organizations to help filter out illegitimate email. As email service providers tighten security to prevent spoofing and phishing, it becomes more and more necessary for the owners of email domains to take specific measures to help prevent spoofing of addresses within their domain, and to prevent legitimate email from being flagged as potential spoofing. These measures are collectively called “email authentication.”

Technologies for Email Authentication

There are three main protocols for providing email authentication:

Sender Policy Framework (SPF) – Identifies which mail servers, as identified by their IP addresses, are authorized to send mail on behalf of a domain. It does this by way of TXT records in the DNS (colloquially called “SPF records), which specify the permitted mail servers for the domain in question. This protocol was formerly known as Sender Permitted From.
DomainKeys Identified Email (DKIM) – Allows sending servers to put cryptographic signatures on the messages they send, to authenticate that they sent them. It uses TXT records in the DNS to distribute the public keys needed to validate signatures.
Domain-based Message Authentication, Reporting and Conformance (DMARC) – Allows email domains to define policies for how receiving mail servers should deal with messages which fail SPF or DKIM authentication. These policies are published as TXT records in the DNS.

SPF

SPF authenticates only the SMTP envelope sender address against the IP address of the sending server. It does nothing to authenticate the headers or body of the message (that’s where DKIM comes in).

Despite its utility, SPF has several shortcomings:

It is fragile and can be broken by simple email forwarding if it isn’t done properly.
It does not scale well because the SPF specification imposes a hard limit on the number of DNS queries it is allowed to make in order to reach a decision (10). If this limit is reached before a decision is reached, then SPF verification fails.
It is relatively high maintenance and prone to human error. The syntax used in the SPF record is a bit inscrutable, and any change to an organization’s email infrastructure can require corresponding change to the organization’s SPF record.

DKIM

DKIM protects the entire message body and most headers but does nothing for the SMTP envelope (it leaves that to SPF). It securely identifies the entity that generated and sent the message. It is also extensible, allowing more than one sending entity to sign messages on behalf of a sender domain.

DKIM also has shortcomings:

A digital signature can be easily invalidated by simple formatting changes which can occur while a message is in transit, but which don’t alter the meaning of the message. It can also be invalidated by things like disclaimer headings inserted by email security software.
It does not ensure that the sending entity is authorized to send on behalf of the sender domain found in the From: header. To give a concrete example, a message with a utexas.edu sender address could be sent by a server belonging to tamu.edu. This message would contain a tamu.edu DKIM signature and would pass DKIM authentication if the signature was successfully verified.

DMARC

DMARC provides the policy infrastructure that allows a domain to indicate how SPF and DKIM failures are to be handled for messages purporting to be from the domain. One of the key concepts in DMARC is called alignment. Simply put, if the entity that signed the message with DKIM has the same domain as the sender in the From: header, then the signature and header are said to be aligned. In the above example, utexas.edu and tamu.edu are not aligned. Alignment can also exist between the domain in the From: header and the domain in the SMTP envelope sender address. DMARC requires that either SPF or DKIM verification pass, and that the corresponding domain aligns with the From: header.

Implementing Best Practices

If possible, use our authenticated relay. The authenticated relay service is an SMTP relay accessible to cloud services, using SMTP authentication to control access. To use the authenticated relay, your third-party platform must support outbound authenticated SMTP on port 25 with TLS encryption. To get access to the authenticated relay, you will need to request a service EID from the EID Team. Then, you will need to send an email to postmaster@utexas.edu requesting permission to allow that service EID to use the relay (only whitelisted service EIDs are allowed to use the service).

Our email defenses trust email relayed through this service. These messages will not be marked as junk or spam by our Exchange tenant or by UTmail. In addition, messages routed through the authenticated relay do not receive an external sender warning. It is important to note that mail delivered to external email servers will be evaluated similarly to any other message sent from our infrastructure. As such, mail sent to external recipients can still be acted on (marked as junk, spam, or quarantined) by the receiving email infrastructure

The SMTP configuration for the authenticated relay are as follows:
- SMTP Server: authenticated.relay.mail.utexas.edu
- Port: 25
- TLS: Required
- Username: Service EID
- Password: Service EID Password
Otherwise, configure the mailer to use a custom DKIM key for your domain to allow alignment. Consult your vendor’s documentation on how to configure DKIM with their systems.
If you are sending mail with a FROM address that is under a domain that you control, you should configure SPF to specify that the vendor is allowed to send email for your domain. Creating a correct SPF record can be difficult in complex email environments. You must take care not to create a record that needs more than 10 DNS queries to fully resolve. Note that we are unable to further modify SPF records for austin.utexas.edu or utexas.edu due to this limit. A few SPF mechanisms, namely all, ip4, and ip6, do not require further DNS lookups. But all others do.
If none of these are possible, make sure that the FROM address is not a UT address and does not “pretend” to be genuine, for example like scholarship.utexas.edu@gmail.com. Most third-party email platforms will allow you to use their domain as the FROM address.