The set up
- Using google suite to manage inbound/outbound emails. All MX records are configured properly for my domain.
- Using google's web-based email client to send/receive emails
- We get almost all emails, however, there are a few emails originating from a corporate domains that never arrive. There is no bounceback alerting the sender that email was never delivered and there is no evidence of the email ever arriving (I looked at the inbound mail logging using the
admin > reports > audit > email log)
- I have
dmarcset up and working properly.
I can rule out
- Definitely not the normal culprits:
custom filters, etc. because I don't see emails ever arriving in the logs
- MX Records setup because I am receiving the majority of other emails
It might be
- DNS propagation issue? We recently switched over to a new
DNS. I exported/imported all the
zeit.coDNS management around the same time that we started noticing this issue. I've since move back to my original
zoneeditconfiguration, but the problem persists.
- The individual outbound email set up of each of the domains that we cannot receive email from. There's no way to really verify this w/o getting access to their email logs. And trying to get cooperation is unlikely.
Things I've tested
me@my_corp_domain.com- no email, no bounce
client@their_corp_domain.comWORKS! and then when they hit reply and send - no email, no bounce
- What's even weirder:
firstname.lastname@example.orgWORKS! and when they group reply NOTHING! not even to my gmail or hotmail accounts.
- Changing DNS messed stuff up in a way that when the sender's mail system trying to resolve my MX records, they see some inconsistent IP addresses and puke all over themselves. Or, there's some blacklisted IP addresses in the
zeit dnsmanaged servers that cause emails to disappear.
I'm basically looking for other ideas that I could try out and test out to help nail down this elusive bug. If you run your own outbound email server and are willing to help me w/ logs, I'd greatly appreciate it.
As per comments, I've done some additional testing:
- them@their_corp_domain.com -> bogus email: BOUNCEBACK REC'D.
Emailing from other domains to me@my_corp_domain.com
- email@example.com <--> me@my_corp_domain.com: WORKS BOTH WAYS.
- firstname.lastname@example.org <--> me@my_corp_domain.com: WORKS BOTH WAYS.
- me@my_other_corp_domain (also google apps managed) <--> me@my_corp_domain.com: WORKS BOTH WAYS. Not certain about it, but I think google-based mail servers are able to see if it's an internal delivery and just route it directly. I've attached screenshot of the routing routing of email
Traceroute from their end
No issues here. I think the real interesting question would be what does the traceroute look like from their SMTP server. Each of these corporate domains that cannot send us email outsources their mail handling to 3rd party provider.
There are 3 different corp domains that I'm aware of that cannot email us.
I did some digging and found that
REDACTED.ecicloud.com show up in
MX records for 2 of the 3 accounts. The other corp domain uses
http://www.abacusgroupllc.com/ for their managed IT.
I tried to do a
telnet directly to one of the servers above to spoof an email directly over
smtp. It might a red herring, but for
rcpt to: <someone@their_corp_domain.com> I got a
Sender ok, but for any address outside their domain, i got
Relaying denied. This wasn't an exhaustive test by any means.
MX Records TTL
- Per suggestion in comments, I checked TTL. They were originally at 7200 sec for each MX record. I've now updated all of them to be 3600 sec.
MXToolbox Header Analysis
- Per suggestion by harrymc, I ran the header analysis and came up with these results: results. Honestly, I'm not super clear as to what I'm looking at in this report, but I can see that
DMARCare not configured properly. I'm guessing that