Link to home
Start Free TrialLog in
Avatar of Shirley Mastrorilli
Shirley MastrorilliFlag for United States of America

asked on

On-going Email Issues

About 4 weeks ago we began having issues where emails would be sent to customers/vendors but were never received by the customer/vendors.  Our employees do not receive any rejection emails or NDR's.  When customers/vendors try to email to our domain, with or without attachments, sometimes they receive rejection emails, sometimes they do not.  This happens both domestic and internationally.  We were able to find one issue, which was our URL in our signatures.  We removed the URL and this allowed about 70% of the emails to be received by the customer/vendors; however attachments were still be blocked at the customer/vendor side to be sent out.  Our IT director thought he may have found an answer when he found a post pertaining to EXIM Service on the website.  This service was disabled last week, but our issues still persist.  We have checked and we are not on any black lists, and believe this is a company by company issue.  We cannot get in contact with any IT department in the customer/vendor companies, but have had the contacts within those companies open tickets.  If anyone can give us any ideas as to a resolution to this issue, it would be greatly appreciated.
Avatar of Paul MacDonald
Paul MacDonald
Flag of United States of America image

I would verify the problem recipients aren't using Yahoo for their mail service (even if they have their own domain name in front of it).  We've also had problems with recipients who use a "reputation" service to block e-mails.  It's not an RBL per se, but has a similar effect.

Do you have SPF, DKIM, and/or DMARC records in DNS?  Your mail may be rejected if not.
Have you run anything like MXToolbox against your mail domain to see if there are any issues there?
Tip: The answers are found in your MTA logs.

If you're using EXIM, then you'll refer to your logs.

Reviewing logs can be... complex as data is abstruse (complex, near indecipherable at times), so if MTA log analysis is new to you, likely best to hire someone for assistance... if this is a pressing issue...

If you can tolerate a potentially very long time to debug this, you'll start with 1x problem, outbound or inbound mail, then start posting related logs, for people to analyze for you.

Likely good starting point will be, "About 4 weeks ago we began having issues where emails would be sent to customers/vendors but were never received by the customer/vendors."

So you'll pick exactly 1x outgoing message, posting the full message (all header, no redactions) along with your related EXIM log entries, which will match the Message-ID: header assigned to the failing message.

Tip: Unless you debug this type of problem, all day, every day... take a deep breath... as you'll develop an amazing level of patience as you expand you MTA deliver/inboxing expertise.
Avatar of Shirley Mastrorilli


We have found an answer for most of the issues -- for one particular vendor they were using a service that would block email based on reputation.  We appeared to trigger their reputation - due to the words that were being used in the email.  The vendor contacted the company he uses for the reputation and they whitelisted our company.  I have one other company with an issue, but I am sure this is the same issue.  This question can be closed.  Thank you all for your assistance.
Just reading over this.

You're welcome.

And... one consideration is you may be caught in the persistent saga of the "Misinformation Database".

To determine if this is the case, send one of your normal email to a Gmail account.

If you get a - 250 (success) - this is not the problem.

If you get a - 550 your domain is not authenticated to send this message - this tells you instantly you've been caught by either a Misinformation Match on the domain part of a URI (Web or Email address) or... and this is ugly... you've hit one of Google's many message parser errors.

Google's parsers are broken beyond belief right now... flagging misspelled words... dangling punctuation... incorrectly encoded URLs... to name a few.

The only way you can determine this is by sending a message directly to a Gmail account, bypassing any other service.
It appears there were two causes for this issue.  One company was using a filter that monitored wording and would rate the email according to the particular words in the email.  This had to be adjusted, considering the type of information that was being dealt with.  The second cause was due to our URL in the signature addresses our employees used.  For most of the people who had this issue, removing the URL would resolve the issue.  I hope this helps any other people who run into this issue.
Avatar of David Favor
David Favor
Flag of United States of America image

Link to home
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
It has been a while now since I first asked this question.  I do believe I sent a test message to my GMail account, and had no issue, delivered with no NDR or error.  The other issue with this is that an error or NDR is never received, so all that can be done is trial and error, and when possible, work with the receivers IT support.  This case can be closed.