ExchangeDefender Whitelisting & DEA (Disposable Email Addressing)

ExchangeDefender is a cloud-based email security solution, similar in implementation to an SMTP based firewall. As such, ExchangeDefender policies are designed to conform to the RFC 5321 standard, considering only the real routable email address used in the SMTP envelope (envelope-from).

For a less technical explanation, please enjoy the rest of this article, where we explain the difference between SMTP header and envelope from, how it fits in the overall email security design, how to properly whitelist senders, as well as best practices.

The Bulk of standards behind Internet email were designed in the 1980's, and it resembles our postal snail mail in both terminology and design. Every email you send contains an envelope, with mail routing information such as sender/recipient email addresses, and the message, which contains additional items such as the date, subject, and the data itself, like text and attachments. Just like the post office and mail carriers do not open the letter to find who it's going to (relying instead on the addresses on the envelope to deliver/return the letter), Internet email servers and firewalls like ExchangeDefender only look at the email envelope for routing and delivery instructions.

The post office would use the recipient address on the envelope (the envelope to:) to route the mail to Orlando, where a mail carrier would deliver it to 8131 Vineland Ave. If the letter could not be delivered, the letter would be returned to the sender in Los Angeles. Email servers delivering email messages work in a very similar way. Each email has an envelope (with address routing information) and a message body that contains message headers with a friendly from, to, subject as well as the rest of the message text and attachments. In plain terms, they both have envelope information that has to be valid for delivery, and a letter/message content that is only relevant to the recipient.

Just like it's very hard to fake a street address, it's difficult to fake an envelope "from" address because it must conform with SPF/DKIM/DNS and other Internet protocols to pass the checks and get delivered to the right email address. As the digital equivalent of a postal service and mail carrier making the delivery, ExchangeDefender only looks at the envelope address, not the potentially forged/fake email addresses inside the message headers or body.

In our example, the sender address on the envelope tells us it is from Los Angeles, CA and the postal service will return this letter to the address on the envelope at 123 Main Street. However, once we open the envelope, we see that the message is actually from Donald J. Trump in New York City. This is how spoofing and forgery work: hackers use a real email address on the envelope (to deliver the message) but they forge the from address in the message body (letter) in order to make it look like it came from someone else that you'd trust and click on. 

ExchangeDefender functions as the SMTP firewall service (SMTP proxy) for email going in and out of your organization. We accept email on behalf of your organization, scan contents for potentially dangerous items, and deliver safe messages according to policies you set. Because we are a firewall service, we only look at the envelope from: address when enforcing policies because that is generally the only email address we can trust and validate. If there is an issue with delivery, a non-delivery receipt (NDR, or "bounce message") would likewise be sent to the envelope from:address.

Just like a mail carrier doesn't open your letter to double-check that both the envelope and the name on the letter match, ExchangeDefender does not look at email addresses printed inside the message headers or the message itself. We are only concerned with routing and the authenticity of the message.

ExchangeDefender relies heavily on DNS, SPF, DKIM (DomainKeys) and other standard Internet protocols in order to securely deliver email while minimizing forgeries. Because even the envelope from:address can be forged (after all, you can type in any email address when setting up an email client), we can look at the SPF record and check if the mail from that specific sender (envelope from) can come from the IP address of the mail server that is delivering the message.

From a legitimate email sender standpoint, the envelope from: is also the only legitimate or relevant email address - because it's reasonable to assume that they'd want to know if their email could not be delivered. ExchangeDefender (and all other email servers) will bounce/return the email to the sender identified by their envelope from: email address. Almost all the mass mailing, ecommerce, newsletter, and email automation platforms use the envelope from: address to track campaigns, lists, and to track bounces and errors.

Because of all of these reasons, the best and only address we consider is the envelope from:email address when applying email policies.

When it comes to mail client use (Outlook, Gmail, LiveArchive, etc) the situation is completely different: you're actually reading the letter. Mail clients do not care about email routing or authenticity, they just present you with the message and whatever the sender put in it: which could include completely forged and fake elements! This is how SPAM messages manage to appear legitimate, because mail clients do not care about what is in the message or where it's from, they are just there to present the message to you.

If you're having trouble getting an address whitelisted in ExchangeDefender, view the message headers and search for "envelope-from", that is the address you want to whitelist (if it's long or contains a bunch of numbers, whitelist the domain). The sender is likely using DEA to mask the address, and you'll need to whitelist the domain of the bulk-mail operation that is actually sending the message.

Now that you know the difference between the envelope from: and the header from: email addresses, you can answer the following question:

There is an extremely good chance that they whitelisted the wrong address. Remember, policies are only actionable when they apply to the envelope from: email address and users often only think about the email address displayed in their Outlook/Gmail: the fake message header from email address. In order to properly whitelist or blacklist a sender, you need to use their envelope from: email address.

Why do senders use fake addresses as their From:, instead of the real envelope address?

For many it's the optics, because the fake header from auto-confirm@amazon.com looks a lot better than the envelope from: 202010241725117eba9a4215f34481b11b50e99450p0na@bounces.amazon.com. Senders tend to opt for friendly looking display addresses for their newsletters and mailing lists, so you can immediately tell where they are coming from. In technical terms, this is known as a "disposable email address" (DEA, "dark mail") where a unique envelope-from address is generated for every email sender/recipient/campaign combination so that any delivery errors or bounces can be tracked. 

Unfortunately, that same method is the way spammers and hackers forge the address in the message header in order to trick the user to trust and open the message. Yes, the same method mass-mailing (bulk) operations use to track bounces and evade IP sender reputation is used in the exact same way by spammers, hackers, and spear phishing operations. They use a valid envelope-from address that conforms to all the SPF/DKIM checks so that firewall solutions (like ExchangeDefender) don't bounce or categorize their mail as SPAM. Then they include the familiar but fake From: address that your Outlook / Gmail will display as the From: line so you'd recognize it and click on it.

Some of the most popular mass mailing (bulk mail) operations include SendGrid, AmazonSES, MailJet, SMTP2Go, SocketLabs, Postmark, Mandrill, Mailgun, MailChimp, ConstantContact, etc. They are used and abused by legitimate senders as well as hackers alike, in many cases for the same purpose.

As it's our job to keep fake, forged, and dangerous senders from your inbox, our policies can only apply to the email addresses that we can actually verify: envelope-from.

In order for the message to get accepted by ExchangeDefender it needs to pass validation of SPF, DKIM, and many other SPAM checks. Here is a sample SMTP session in which we will use a real email address to send the message, and then forge/spoof the From line and the message contents that are not used in email routing (so no policies can be applied to them):

In the example above, we use a real envelope-from: in order to bypass ExchangeDefender's SPF/DKIM infrastructure. Once the data command is issued, we start sending the actual email message, the headers and the body that will be used by your email software (Outlook, Gmail, Thunderbird, Eudora) to display the subject, text, images, etc. In the message, we can put anything we want - and in this example we spoofed the message to come from Amazon.com <auto-confirm@amazon.com>

The rest of the message can be forged with additional elements such as images, backgrounds, tracking magic pixels, etc. We can make the body as believable as we want to, and this is how hackers work. Everyone has received a spoofed message or even a spoofed cell phone call that came from a number that looked legitimate: but it never is.

For this reason, and for many other security considerations, ExchangeDefender only looks at envelope-from address.