Recently, Proofpoint evaluated the DMARC data of 325 of our Email Fraud Defense customers to find out where it was coming from. We found that the average email that was sent from their domains came from:
- Applications/Systems (42%)
- Marketing (57%)
- End users (1%)
With applications sending 42% of email, messaging and security teams have their work cut out for them. Historically, on-premises SMTP relays have helped control which application-generated messages were being sent by their organisations’ domains. With this control, it was straightforward to protect their organisation’s email brand identity. Otherwise, the organisation’s reputation and sensitive data might be put at risk. Plus, recipients were vulnerable to fraudsters.
However, as applications modernise, teams are struggling to maintain this control. If you are a messaging or security practitioner that feels anxious about application modernisation and what it means for your ability to maintain control of your organisation’s email identity, you are not alone.
In this blog post, we’ll explain how email relay controls have changed. We’ll also provide some tips for getting that control back to protect your organisation.
Controls that used to provide protection
In the past, teams managed application-generated messages by implementing and maintaining these controls:
- DMARC ‘reject’ policies. These controls prevent domains from being ‘spoofed’ by bad actors.
- Outbound filters. These filters prevent spam, malware or sensitive data from being sent out either intentionally or by accident.
- Access control restrictions. Teams use these restrictions to control the applications and systems that can use SMTP relays.
Historic Relaying using on-premises solution
Below are three ways application modernisation has introduced risk to an organisation’s email identity.
1: Migration to the cloud
On-premises applications are now migrating to cloud environments. However, in the cloud, secure SMTP relay options are not available.
In theory, legacy on-premises SMTP relays could continue to make DMARC and outbound filtering easy. But allowing them to relay email from external cloud environments is risky as it means turning them into ‘open relays’ (if they aren’t already).
Exposing on-premises relays to external environments is risky
2: Email service providers (ESPs)
ESPs certainly send DMARC-compliant email. However, they require their customers to authorise vast shared infrastructure via SPF records. Unfortunately, SPF records are visible to bad actors. Plus, they are often insecure and lack outbound filtering.
ESPs specialise in deliverability, not security
3: SaaS
These applications are outsourced to third-party vendors. Because most of these vendors focus on core product development and differentiation, much like ESPs, email security isn’t their top priority.
- SaaS providers often cannot send DMARC-compliant email. This means that implementing and maintaining DMARC ‘reject’ policies is challenging.
- Like ESPs, this scenario requires authorising often insecure infrastructure in SPF records.
SaaS providers are focused on core product development, not email
Proofpoint SER delivers control
With so many challenges, it’s a tall order to put messaging and security teams back in control of application email. But that’s exactly what Proofpoint has accomplished with Secure Email Relay (SER). Here are some of the ways that SER solves today’s challenges:
Modernised relay
The principle of controlling application email via a relay hasn’t necessarily changed. What has changed, however, is how the relay is deployed and managed.
Architecturally, the ideal way to accommodate application modernisation and sprawl is a relay hub-and-spoke model. This is where:
- All emails—regardless of their source environment—pass through the ‘hub’. This is a central place for filtering emails, enforcing policies and encrypting payloads as well as other functions.
- ‘Spokes’ are optional conduits that assist with moving emails from various environments to the main hub. For example, a lightweight in-network spoke can gather emails from hundreds or thousands of applications. Then, it can normalise how they flow between a customer’s network and the hub. Or an Amazon Simple Email Service (SES) spoke can use SES Mail Manager to conditionally route email to the hub.
Security
Generally, when we talk about something being modernised, we imagine it’s more secure. However, it’s worth setting out a few dimensions that apply to an email relay:
- The solution development and deployment process should adhere to the latest security standards and best practices. For example, instead of a monolithic mail server, SER is built in the cloud using microservices. Microservice architecture results in smaller, purpose build systems that provide a narrower attack surface for bad actors. Microservices also use a modern CI/CD system. This makes it faster to apply security patches and deploy changes to production with little to no downtime.
- Emails handled by the solution should be end-to-end encrypted. At the inbound connection level, strict authentication should be required of applications (TLS 1.2, but preferably higher).
- The solution should provide security features like filtering for spam (‘AS’) and malware (‘AV’). It should also protect sensitive information and have data loss prevention (DLP) capabilities. Any emails egressing the system to the internet should be DKIM-signed with 2048-bit keys that are rotated every six months. We recommend tracking the progress of DKIM2.
Services
There is no escaping the human element. This is particularly true when it comes to decommissioning on-premises relays. These systems often actively handle several types of email. This includes:
- The emails of hundreds (if not thousands) of applications. Depending on the migration strategy, the owners of these applications may need to be consulted and supported during the transition process.
- Mission-critical emails, like password resets and MFA codes. Certain apps should be prioritised in their handling and in the timing of their migration.
The hub-and-spoke architecture of SER
Protect your email better with Proofpoint
With Proofpoint SER, your organisation can better manage all the applications and third-party SaaS partners that are sending email on your behalf. With SER, even if one of these sources is compromised, you’ll be able to shut them off immediately. This is especially important for third-party applications that have historically been outside your control but could still cause significant damage to your brand.
So, whether you’re looking to retire your on-premises relays, increase your security with DKIM or just want better control over all your application email, Proofpoint SER may be just what you’re looking for.
Want to learn more?
You can watch a short video overview or visit the Proofpoint Secure Email Relay product page. You’re also invited to contact your Proofpoint sales representative who can help determine whether SER is the right tool for you.
If you are an Amazon SES customer and would like to learn about securing your application mail traffic with Proofpoint SER, we recently did a joint webinar with Amazon on this topic.
There’s also an upcoming webinar: ‘Cloud Initiatives for Securely Sending Application-Generated Email’. Register for the event here.