relay not permitted, authentication required

G

gate2vn

Verified User
Joined
Nov 9, 2004
Messages
495
Location
Oslo
In short: sending to [email protected] returns error: relay not permitted, authentication required, even I have checked "Use this server to handle my emails." Double-checked in /etc/virtual/domains, the adomain.com exists there.

Long version: I am migrating email users from adomain.com, currently running on a DA server, to Google Workspace. During the migration, Google has an option which is using routing for forwarding non-existing email addresses to the current DA server. I have configured that, and the incoming emails are forwarding to the current DA server already. No problem with forwarding.

The adomain.com is using:
- CloudFlare name servers.
- MX records point to Google already.

On the DA server, the adomain.com is configured with:
- local name servers.
- local MX record.

The /etc/resolv.conf is also configured to dig locally first. When checking in ssh, "dig adomain.com mx" commands show local MX record.
The adomain.com is existing in /etc/virtual/domains. Have have checked "Use this server to handle my emails." in DA already.

However, when incoming emails are processed at the DA server, Exim always returns error: relay not permitted, authentication required.

Any idea? Thanks.
 
I feel like maybe there's a chance that this is simple. The relay not permitted error, are you 100% certain it's coming from the server that you want to receive the email at? Don't rely on Google telling you that it is, double check the exim logs and make sure that this exact server is actually returning that error. Because my suspicion is that the server which has adomain.com configured and with the "Use this server..." box checked isn't the same server that is returning the error. Because if that isn't the answer, this is worth opening a bottle of tequila over.
 
Richard G said:
Try using:
dig @8.8.8.8 adomain.com MX
to see if the domain already resolved everywhere.
Click to expand...
Yes, MX records are Google’s. Like I mentioned, the incoming emails are forwarded successfully, no problem.

mxroute said:
Don't rely on Google telling you that it is, double check the exim logs and make sure that this exact server is actually returning that error. Because my suspicion is that the server which has adomain.com configured and with the "Use this server..." box checked isn't the same server that is returning the error.
Click to expand...
Yes, I checked. The error returns both in Google and DA Exim logs. We are talking about the correct server.
 
Google WorkSpace showing MX record and CNAME Record verified?

Google has changed their records recently please follow new guidelines

Screenshot 2023-04-11 at 10.49.15 AM.png
 
Google MX is not a problem. If it’s not working, the incoming emails cannot be re-routed to the destination DA server.
 
Relay not permitted tells a clear story that exim doesn't think this domain is a local domain. It's very limiting in scope but in this case, also very confusing. You should be able to take Google out of the equation and simply say that if mail is sent to this server, for that domain, it returns the error. It should be the same if you set the MX to the DA server.

I don't know how you can arrive there unless you're wrong about something or the exim configuration is broken. I would say it's worthy of a DA support ticket.
 
I found the reason. When doing routing from Google, I chose port 587, but default Exim config is only allowing authenticated users working with port 587. Changing to port 25 resolved the problem. Will check further about configuration with port 587.
 
Correct. Port 587 is an SMTP port, so if you would send mail from/via Googles smtp, you should use 465 or 587 (Google uses 465 if I'm not mistaken).
A forward should automatically connect to the receiving mailserver at port 25. So if Google was trying to use port 587 on the DA server, then indeed this will not work.
 
You must log in or register to reply here.
Back
Top