Not sure which DNS domain name went wrong.

User access email https://outlook.domain.com

mx record - 10 Pref - mail.domain.com - 100.100.100.100

mx record - 20 Pref - mail2.domain.com - 101.101.101.101

PTR - 100.100.100.100 - mail.domain.com

PTR - 101.101.101.101 - mail2.domain.com

A record - outlook.domain.com - 100.100.100.100

A record - outlook.domain.com - 101.101.101.101

I'm using mxtoolbox to verify DNS.

Any idea whether DNS or IronPort causing the issue?

This is on the Ironport.  What have you got configured to present to remote email systems in the EHLO protocol message?

This shows how to set it.  Make sure its is a public resolvable DNS name and you have matching forward and reverse DNS lookups.  Make sure you are looking at the external facing interface(s).

https://supportforums.cisco.com/discussion/11923911/ironport-c170-heloehlo-response

In Ironport hostname, we configured mail.domain.com 

Sometimes email successful sent.

If the email undelivered, the sender will resend the email and successful sent.

Email undelivered message

X-IronPort-Anti-Spam-Filtered: trueX-IronPort-Anti-Spam-Result: ArIEAPrZplYKZGWa/2dsb2JhbABbAxkBAQEBDwEBAQGCPoEebQaIUaIokWAefIR1AoIVAQEBAQEBgQuEQQEBAQEDBSgcPgICAQgNBAQBAQYBAQEKFQcCBQ8BDQIMFAkIAQEEAREBCAbGTAEBAQEBAQEBAQEBAQEBAQEBAQEBDggEhTJ8hG2EGxEBKwkLFRGDdAWGFoIcikKEBIRdBIEOh2AHgV6ERIMbhTyKb4NSAYJjGIFQaoYMNHwBAQEX-IronPort-AV: E=Sophos;i="5.22,347,1449504000";    d="jpg'145?scan'145,208,217,145";a="2237622"Received: from unknown (HELO outlook.domain.com) by mail.domain.com with ESMTP; 26 Jan 2016 10:31:37 +0800

Unless mail.domain.com actually points to your Ironport this is not correct.  You need to enter the correct DNS entry - if you expect it to work.

Actual DNS meaning domain.com or outlook.domain.com ?

I should configure domain.com ?

Initial setup was domain.com 

Ironport support has changed the configuration to mail.domain.com

What Ironport hostname should configure?

What is the public IP address of your Ironport?  What DNS entry exists pointing to this IP address?

That is the DNS entry you should be using.

Hello Shwufai,

From review of the NDR error and the headers you are providing.

I believe the EHLO error in question is referencing the EHLO your ESA is sending to the destination server.

The HELO outlook.domain.com seems to be the HELO response sent to your ESA (IronPort) from the local servers you have.

I would suggest to review what is the EHLO that your ESA is sending when connecting out.

So please check GUI > Network>IP Interfaces, pick the interface that the outbound mail is going out from, and set its Hostname field.

Ensure this file resolves to a valid DNS record to stop the destination server from dis-allowing the email.

Regards,

Matthew

Make sure its is a public resolvable DNS name and you have matching forward and reverse DNS lookups.

Although it doesn't harm, (E)SMTP have no such requirement. You are mixing two unrelated things.

The IP address from which the SMTP session arrive to SMTP server needs to have matching forward and reverse DNS record.

According the error message, it seems not to be the issue.

The HELO/EHLO parameter require hostname, but such hostname is not required to have a relationship to client IP address. Imagine multihomed SMTP client (more than one IP address) or client behind NAT.

HELO parameter should primary hostname of the client host or address literal. See RFC5321 for details:

E.g. EHLO [ 10.0.0.1 ] is valid HELO (even with private IP used) and session should not be refused because of it.

Of course, Philip is right, you can workaround the issue by providing resolvable name, but it's not your computer who's misconfigured here.

There are RFCs, and then there are implementations that break RFCs.

I've seen plenty of receivers that block senders if EHLO argument does not resolve. Furthermore, the SMTP RFC *does* recommend it to be set to a resolvable FQDN. Even further more, SPF RFC recommends to check the HELO identity as well (see http://www.openspf.org/RFC_4408#helo-ident).

Additionally, while we may insist on being strict to the word of the RFC, it is much easier to change our own config (and satisfy all the "MAY" clauses) than influencing a 3rd party to change their own. At the end of the day, it only ends up in disruptions in mail delivery.

So, in practice, it is best to have your hostname configured as a fully resolvable FQDN (both A and PTR records, matching), as well as added to the SPF records of all the domains you do delivery for.

What sentence of my comment you disagree with ?