Avatar of Shirley Mastrorilli
Shirley Mastrorilli
 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.
Email Servers

Avatar of undefined
Last Comment
Shirley Mastrorilli

8/22/2022 - Mon
Paul MacDonald

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.
Andrew Porter

Have you run anything like MXToolbox against your mail domain to see if there are any issues there?
David Favor

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.
This is the best money I have ever spent. I cannot not tell you how many times these folks have saved my bacon. I learn so much from the contributors.
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.
David Favor

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 whatever.com 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.
Shirley Mastrorilli

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.
Try out a week of full access for free.
Find out why thousands trust the EE community with their toughest problems.
David Favor

View this solution by signing up for a free trial.
Members can start a 7-Day free trial and enjoy unlimited access to the platform.
See Pricing Options
Start Free Trial
Ask your own question & get feedback from real experts
Find out why thousands trust the EE community with their toughest problems.
Shirley Mastrorilli

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.