Over the past few years, there has been a significant evolvement in email relay controls, especially in how application-generated emails are handled. The reason why this evolution carved its way is the urgent need to upgrade security, deliverability, and compliance with modern email standards. When email was in its nascent phase, the concept of open relays prevailed. These servers would accept and forward emails from any sender, making them easy targets for threat actors.
Application emails, like password resets or order confirmations, often relied on these open relays, which lacked proper authentication mechanisms. However, over the past few years, the digital landscape has become more vulnerable to cyberattacks. Also, the advent of generative AI has enabled malicious actors to develop flawless codes and content. Now, there are hardly any mistakes or tonality issues in emails; earlier, these were considered the red flags that often prevented targeted recipients from falling into the trap.
As more and more instances of email abuse have started surfacing, major email providers have blocked open relays. Earlier, it was possible to control which application-generated emails were being sent by your company’s domain. This flexibility made it easier to control what data goes out, cushioning the brand’s integrity.
But now the scenario has changed. Applications are evolving, making it hard for CISOs to hold control over outgoing emails and the data embedded in them. If you are concerned about how application modernization messes up your grip on your organization’s email identity, you’re not alone.
Controls that offered protection in the past
Deploying the following measures helped teams manage application-based messages–
DMARC
In the past, DMARC has played a crucial role in preventing the abuse of application-generated emails by enforcing strict policies. It aligned results with SPF and DKIM, and enabled domain owners to specify how unauthorized messages should be handled. This mitigated the risk of recipients engaging with a potential phishing email sent on your behalf. DMARC’s deployment ensured that only authenticated application-generated emails from legitimate sources land in the inboxes of recipients, effectively safeguarding communications and reputation.
Outbound filters
Outbound email filters were used to evaluate outgoing messages for characteristics that are generally considered red flags. These included suspicious keywords, excessive links, or atypical sending patterns.
Access control restrictions
It was applied to restrict control over which applications and systems can use SMTP relays.
Application modernization
The following application upgradations have posed a significant threat to application-generated emails’ security-
1. Migration to cloud
More and more applications are migrating to the cloud, mainly because of scalability opportunities and cost reduction. However, there is no provision for secure SMTP relay in the cloud.
Using old on-premises SMTP relays might seem like an easy way to manage DMARC and outbound email filtering. However, allowing these relays to handle emails from external cloud environments is risky because it can turn them into ‘open relays,’ which are vulnerable to abuse. Additionally, SMTP relays are becoming outdated.
2. Email service providers
Email service providers emphasize using SPF, DKIM, and DMARC, but they require their customers to share an extensive list of authorized senders through an SPF record. An SPF record is updated on your domain’s DNS and is available for public access, allowing threat actors to retrieve it to intercept or modify.
3. SaaS
In the SaaS model, applications are outsourced to third-party vendors, focusing more on product development and differentiation; email security is not on their focus sheet. Often, SaaS providers can’t send DMARC-compliant emails. It becomes challenging to subject unauthorized emails to a ‘quarantine’ or ‘reject’ policy. Just like the email service providers’ case, this setup would also require authorizing an extensive range of IPs and mailing servers, which is a vulnerability in itself.
