SOLVED Can't receive email from Google workspace (sender verify fail)

[rt3me]

My server is unable to receive emails sent from Google workspace email addresses. I have the server configured to verify sender email addresses.

Here is the error I am receiving in exim: 2021-08-03 17:50:33.324 [33088] H=mail-io1-f51.google.com [209.85.166.51]:33295 I=[69.16.255.247]:25 sender verify fail for <pastor a ~ t cliffordbaptist.com>: No Such User Here

pastor a ~ t cliffordbaptist.com is a valid email address in a Google workspace account. I have tested sending to my server from multiple addresses in another workspace account and I get the same error for each sender. It appears to my that cPanel/WHM is unable to verify sender email addresses for emails sent from Google workspace.

Any help would be greatly appreciated. Thank you!

 

[cPRex]

Hey there! I see the domain you originally posted has all the MX records pointed to Gmail. Since that is the case, I wouldn't expect your server to be handling any messages for that domain, so Exim should not be involved.

Can you get me more details on how and where you are sending those messages and where you are expecting to receive them?

 

[rt3me]

Hey there! I see the domain you originally posted has all the MX records pointed to Gmail. Since that is the case, I wouldn't expect your server to be handling any messages for that domain, so Exim should not be involved.

Can you get me more details on how and where you are sending those messages and where you are expecting to receive them?

I am not sending emails. I am receiving them, or rather not receiving them. My server cannot receive from Google workspace accounts. For whatever reason, it appears to me that Google workspace is telling my server that Google workspace senders (i.e. [email protected]) are not valid when I know for sure they are... I know who they are... they tell me they tried to email my server, etc. Maybe I should have said the recipient my server is blocking these for is [email protected] which is the email I receive messages from customers at. And this is happening with multiple Google workspace accounts that have attempted to send to my server.

 

[cPRex]

Thanks for the additional details. Are emails from other locations being delivered normally, such as from Yahoo or an account on another server?

 

[rt3me]

Thanks for the additional details. Are emails from other locations being delivered normally, such as from Yahoo or an account on another server?

Yes. I have verified I can receive email from my personal gmail address, from other cpanel email addresses, etc. It seems to only be Google workspace emails failing to be received.

 

[cPRex]

I will say I'm not an expert on the Google Workspace tools, so I may not be of much help there.

However, I still would not expect any email for the domain you mentioned previously to reach your server. When I check the MX records for your domain they are all pointed to Gmail, so any messages sent would not reach the cPanel server.

Does Google Workspace somehow handle the message first and then send it to cPanel or is there something else going on that is causing the mail to reach your cPanel machine?

 

[rt3me]

I will say I'm not an expert on the Google Workspace tools, so I may not be of much help there.

However, I still would not expect any email for the domain you mentioned previously to reach your server. When I check the MX records for your domain they are all pointed to Gmail, so any messages sent would not reach the cPanel server.

Does Google Workspace somehow handle the message first and then send it to cPanel or is there something else going on that is causing the mail to reach your cPanel machine?

"your domain" is not my domain. You are confused. My domains are h e n r y a v e . c o m and h e n r y . h o s t

Neither have MX records pointing to gmail. People who use Google workspace have MX records pointing to google, which is what you are looking up. You are looking up the MX record for some random person out there in the world trying desperately to email my server. THIS IS NOT MY DOMAIN OR MY MX RECORD. I AM TRYING TO RECEIVE EMAILS NOT SEND THEM. They are reaching my server as well, then being rejected by my server because exim is configured to verify SENDERS when it RECEIVES emails. It attempts to contact the Google workspace servers to verify the Google workspace sender (remember that random guy out there in the world trying to email me?) and MY SERVER rejects the email because it says the sender verification failed. In other words, my server is saying that it will not accept an INCOMING email from Google workspace because the sender does not exist in THEIR servers. The sender does exist. I know them personally. They use Google workspace and love it, which I am starting to understand why. THEY USE IT, NOT ME. PEOPLE ARE ALLOWED TO USE GOOGLE WORKSPACE AND MY SERVER SHOULD BE ABLE TO RECEIVE EMAILS FROM FROM FROM FROM FROM FROM FROM THEM. RECEIVE!!!!!!!

Please try and understand: I DO NOT USE GOOGLE WORKSPACE IN ANY WAY AND DO NOT HAVE ANY MX RECORDS POINTED AT THEIR SERVICES. I AM TRYING TO RECEIVE EMAILS NOT SEND THEM. THE THING THAT IS CAUSING THE MESSAGES TO REACH MY MACHINE IS THAT PEOPLE ARE ATTEMPTING TO SEND EMAILS TO MY MACHINE. A COMPLETELY NORMAL THING FOR PEOPLE TO DO.

 

[cPRex]

Ah, that makes far more sense now! The initial line from the error message read as if the domain was on your machine.

I see three possible options that I can think of that could be causing this. One is that the SPF record from the sender is invalid, which is breaking the email authentication. When I check the CB.com domain that was sending you a message, I see there is just one SPF record listed, which is for the actual webserver IP address the domain is configured on. It seems this is a common misconfiguration for users of Google Workspace as they have an article on this here that explains how you can setup an SPF record that will work for either *just* sending from Google Workspace, or for sending from multiple locations. I don't see that this particular user has that set up properly, and that could be the case for other users as well that may have tested sending you a message with Google Workspace, indicating your server is correctly blocking the email due to failed verification.

Option 2 is weird, but it happens - the domain was once created on your machine and has since been removed, but there is cruft present. From what you said that is not likely, but if you wanted to check the files would be /etc/localdomains and /etc/remotedomains. Like I said, unlikely to be the situation since you described the sender as being someone else completely, but I'm just including that as it is a common result of 550 errors.

Option 3, the least likely, is that there is a more widespread issue with Google Workspace accepting the sender verification callouts. I haven't come across this yet, but anything is possible.

It's possible that an exigrep for the CB.com domain would reveal more detail, but option 1 of multiple users having misconfigured records seems the most likely.

 

[rt3me]

OK Now you're talking! That opens my eyes a bit. Thank you!

Both of the domains involved are hosted on my server, one just the domain so there is no email or any related setup. One was transferred in with existing google workspace service and I think it stopped working incoming after that point (pretty sure). The other was registered on my server and then had google workspace service set up and was never tested sending in to my server til now and it doesn't work. Neither use email on my server, neither had SPF records changed to work with workspace. This might be the cause!

Do you have a link to that article you mentioned?

 

[cPRex]

Oof, did I not include that? Here you go! About SPF - Google Workspace Admin Help

 

[rt3me]

Thanks again!

 

[cPRex]

Sure thing!

 

[rt3me]

It seems that spf records were the problem. I set up everything google recommends on the affected domains and mail is arriving just fine now from workspace domains to my server. Thanks again!

 

[cPRex]

Awesome - I'm glad to hear that was the issue!