Best way to block outgoing mail with unknown sender domain in ESA

[Cesare]

We have a lot of applications sending email through the ESA Relay interface to the outgoing internet interface. We are now in te process of setting SPF, DKIM and DMARC for all our domains (1000+), but we noticed that a lot of email is send  with unknown or fake (developers have a lot of fantasy) or internal domains. These emails must be blocked, but we wonder what the best approach is to this problem.

I've looked at the Sender Verification Exception Table, which looks like how the RAT is functioning for incoming trafic but I wonder if there is any other better approach to this problem.

Any better solution?

[marc.luescherFRE]

SPF, DKIM and DMARC

We have been there and are still struggling with this for our domains and
are about 9 month I n to it



What I would recommend you to do :

a. SPF - define your outgoing gateways in SPF, create one main SPF
record and refer all other domains there for easier maintenance
b. DKIM - define a user and system key per domain which is sending to
outgoing mail recipients, rollover keys every 1 2 months
c. DMARC - first park all inactive domain and implement a reject policy
for them, use an external service provider and a monitoring policy to
understand how bad your problem is with all other domains
d. ESA -split end user and system outbound gateways so you can first
fix end user traffic and the taggle system traffic
e. ESA - built a cluster of two internal relay gateways for SMTP system
traffic only so you can define policies and a host access table allowing all
fixed systems to be compliant.
f. ESA - rewrite all fancy outbound emails into something more generic
like system.sender@domain.com as a short
time solution.
g. ESA - use a set of message and content filter for "massaging" of bad
senders.



Happy to discuss more if needed



-Marc

[Cesare]

Do you have any advise what mechanism to use?

Do you have Sender Verification enabled on the Relay interface?

With the use of the sender verification exception table?

[Libin Varghese]

When envelope sender verification is enabled on a mail flow policy AsyncOS performs an MX record query for the domain of the sender address. AsyncOS then performs an A record lookup based on the result of the MX record lookup. If the DNS server returns “NXDOMAIN” (there is no record for this domain), AsyncOS treats that domain as non-existent.

However, if the DNS server returns “SERVFAIL,” it is categorized as “Envelope Senders whose domain does not resolve.” SERVFAIL means that the domain does exist but DNS is having transient problems looking up the record.

The exception table is used to add domains to it for which you would like to bypass the envelope sender verification.

Ideally this check is used on inbound connections, since relay policy would be used for your internal trusted servers validating their DNS records would not be of much help.

Regards,

Libin Varghese

[Cesare]

That means that sender verification is not the way to go for blocking rogue domains on our relay interface. Problem is that we have a huge amount of servers/application allowed to use the relay interfaces. How can we block any domain, not on our "domain list', from escaping to the internet.

Must we build an Outgoing Content Filter based on Envelope Sender? I'm searching for the equivalent of the RAT but for outgoing traffic.