Reverse DNS Hostname Blocking

[phogs]

Hi,

Good day!  Is there a way to block certain Reverse DNS Hostname on the ironport?

Thank you.

[Libin Varghese]

The HAT sendergroup Blacklist has a default action set to block connections and you can add sending server IP, reverse DNS host name for that server complete or partial to that sendergroup. 

This is located in the GUI under Mail Policies - > HAT Overview. 

Regards 

Libin Varghese 

[phogs]

Hi Libin,

Thank you for that response. It seems to be not enough to define the HAT
Overview to set blocking the domain. Some unverified domains still enter to
our email inbox. Is there any advance setting to do with that?
​​
​Thank you.​

[Libin Varghese]

You can also enable envelope sender verification under HAT Mail Flow Policies.

With envelope sender verification, the domain portion of the envelope sender is DNS verified. (Does the envelope sender domain resolve? Is there an A or MX record in DNS for the envelope sender domain?)

In more detail: 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. This falls into the category of “Envelope Senders whose domain does not exist.” NXDOMAIN can mean that the root name servers are not providing any authoritative name servers for this domain.

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.

Regards,

Libin Varghese

[exMSW4319]

Each Sender Group in the HAT has three checkboxes:

• Connecting host PTR does not exist in DNS
• Connecting host PTR lookup temporary DNS failure
• Connecting host rDNS does not match A record

As far as I'm aware, a mail descending through the HAT groups will be diverted into the ticked group if the condition matches. If you are doing anything clever in later filters or rules, you can even create a specific sender group or groups just for DNS issues so that later filters can see that the group applied and can take action.

You can also go after upstream hosts that appear in the message headers by employing a dictionary with suitable entries for a message filter or content rule. It's less efficient, but accommodates hosts who are only 90% trouble.