550 5.7.1 relaying denied email error

May 17, 2017 6:28 AM

Hello, hoping someone here can help me when both Google support and my hosting provider have given up. I'm working with two domains - we'll call them mycompany.com and client.com, both use G Suite for email, both at the same hosting provider. One email (mine) on mycompany.com (my work domain) is getting this bounce back message: 550 5.7.1 relaying denied when emailing any address at client.com. My colleagues, also emailing from mycompany.com, don't have a problem.

Things that may be relevant:

This started when we repointed the client.com domain to a new site we made, moved all the email addresses from an exchange server to google, updated MX records accordingly. This was a couple of days ago.

Before this change, I regularly emailed several addresses @client.com with no issues.

Google support say they "flushed both domains" but say the problem is not theirs.

The hosting provider say they "flushed both domains" but the problem is not theirs.

Both of them insist it's not anything to do with them and refuse to do anything further.

Any help would be most appreciated as I need to manage this client and therefore need to be able to email them!

If anyone needs more detail you can ask here or memail me.

Thanks!

posted by cilantro to Computers & Internet (11 answers total)

A relaying denied error could be based upon your email client settings. When you're sending, what email client are you using? If it's not a webmail client, what is the smtp server that you're using to relay mail? In the advanced settings, are you going over port 25 and not authenticating? Ideally you'd use port 587 with tls or 465 with ssl for your smtp server settings. If it is a webmail client, is it on the same exchange server that used to host client.com

If you memail the actual domain of client.com involved I'll give you a sanity check. Most important would be a sanity check that client.com looks to be properly setup for receiving email; after that it's likely an email client issue on your end.

I'm trying to be clear in wording, "email client" means the program that you're using to send email. webmail is a perfectly valid answer. It's mainly less clear because you used "client.com" for your example destination address.
posted by nobeagle at 6:47 AM on May 17, 2017 [1 favorite]

If this is only affecting one email address out of many, then I’m betting that somewhere along the way it’s been aliased to an address on a different domain which the target smtp server refuses to accept email for. "Relaying denied" is an error from an smtp server which is refusing to accept email for the domain in question.

Can you post the full bounce message?
posted by pharm at 7:09 AM on May 17, 2017 [1 favorite]

Possibly your client is connecting to the old smtp server and it’s throwing a fit because the dns shows that it isn’t the MX for that domain any more?
posted by pharm at 7:12 AM on May 17, 2017 [1 favorite]

Response by poster: Here's the whole bounce message, with a bit of identifying client details redacted - and I'll check the SMTP server details in my client as well, thanks everyone

Message not delivered
Your message couldn't be delivered to [e-mail] because the remote server is misconfigured. See technical details below for more information.
The response from the remote server was:
550 5.7.1 ... Relaying denied


Final-Recipient: rfc822; [e-mail]
Action: failed
Status: 5.7.1
Remote-MTA: dns; mx1.lcn.com. ([client IP address], the server for the domain client.com.)
Diagnostic-Code: smtp; 550 5.7.1 ... Relaying denied
Last-Attempt-Date: Wed, 17 May 2017 05:04:11 -0700 (PDT)

posted by cilantro at 7:15 AM on May 17, 2017

Response by poster: OK - I checked SMTP server details on my email client against what a colleague has in his client (we're both using Airmail) and they're the same.

Also this happens when emailing from within the Google webmail client as well as from my phone, from Airmail, etc.

Thanks very much for everyone's help so far!
posted by cilantro at 7:21 AM on May 17, 2017

Do you have an IPv6 MX defined for @client.com, and is it properly included in SPF headers for the domain?
posted by nickggully at 7:54 AM on May 17, 2017

Are you 100% sure that this is happening from your gmail client?
posted by empath at 7:57 AM on May 17, 2017 [1 favorite]

Best answer: Checking with the domain name that you supplied via memail everything looks fine; the MX entries all point to google.com (using my dnscache, along with google's 8.8.8.8 and 8.8.4.4 ). On preview I'll note that SPF is setup correctly for this domain (however that's for sending from @client.com which isn't the problem in this case).

Testing telnet'ing in to the MX entries listed for this domain I received a 250 OK for an example address at the domain that you supplied instead of a 550 error. More over, while testing talking to gmail's servers and suppliying a domain that they're not authoritative for, I got a 550 5.1.1 error (email account doesn't exist). I.E. gmail isn't generating this error.

You say that you get a 550 5.7.1 error even using google's servers, but it looks like they'd be giving a different error. In your followup bounce message, this part: "Remote-MTA: dns; mx1.lcn.com" indicates that something is trying to deliver other than to google. While I see in the update that you're using gmail, do you have it configured to use a different outbound server (airmail?) for sending when using the from address of "@mycompany.com" ?

If so, but you can send to all other domains, then the problem is with the alternate server that you're using. mx1.lcn.com isn't an exchange server, but it's a mailguard appliance which might ultimately relay to an exchange system. If it's used for both inbound/outbound scanning, this could be the problem; the old exchange hosting provider might have made changes so the ultimate backend knows where mail should go, but the email scanning system might not have picked up on the changes, or might still have configuration telling it to email to the old backend (which is likely not configured to relay for anyone, thus the error).

On the plus side of all this, this should only be a problem for the client receiving email if someone else is using the old system as their mail relayer. To test/verify this, you could create a new outlook/gmail account and email an @client.com address.
posted by nobeagle at 8:05 AM on May 17, 2017 [3 favorites]

Best answer: Yeah, finding out why the mail is going via mx1.lcn.com is your first priority.
posted by pharm at 8:26 AM on May 17, 2017 [1 favorite]

Best answer: I have been an email postmaster for 20 years. I am not your email postmaster.

"both use G Suite for mail"

"Remote-MTA: dns; mx1.lcn.com"

Those two things are not compatible. If client.com is using G Suite for mail, I'd expect the Remote-MTA to be one of Google's mail servers. Something, somewhere, is telling your local mail server that mail for the domain you're trying to send to is supposed to transit via mx1.lcn.com.

For reference, the MX (Mail eXchanger) records for my Google-hosted vanity domain:
hanov3r.com. 14400 IN MX 30 ASPMX4.GOOGLEMAIL.com.
hanov3r.com. 14400 IN MX 10 ASPMX.L.GOOGLE.com.
hanov3r.com. 14400 IN MX 20 ALT2.ASPMX.L.GOOGLE.com.
hanov3r.com. 14400 IN MX 30 ASPMX2.GOOGLEMAIL.com.
hanov3r.com. 14400 IN MX 20 ALT1.ASPMX.L.GOOGLE.com.
hanov3r.com. 14400 IN MX 30 ASPMX5.GOOGLEMAIL.com.
hanov3r.com. 14400 IN MX 30 ASPMX3.GOOGLEMAIL.com.

Knowing your client's domain name might be helpful in tracking down where responsibility for this lies. Also, check to make sure you haven't somehow typo-ed your recipient's domain on mail you're trying to send.
posted by hanov3r at 10:24 AM on May 17, 2017 [3 favorites]

Response by poster: SO - I took the "why is mail going via mx1.lcn.com when both I and the client are using G Suite for mail?" question to the nice woman in tech support at the hosting provider. She said OH I know what's going on - and told me to delete the unused @mycompany.com email addresses in our web hosting account that we set up before we started using Google mail.

Weirdly, none of these addresses were [e-mail], and my colleagues who did have copies of their emails addresses set up in the web hosting account were having no problems, but the tech support woman said to try deleting them anyway, and I did, and it worked right away.

Thanks very much for all your help! Weird mystery solved even though I'm not sure I understand why - the woman in tech support said that since both sites were hosted by her company, something somewhere was trying to be clever and deliver locally instead of externally. Or something. She helped me fix it but she wasn't very good at explaining the problem.
posted by cilantro at 2:03 AM on May 18, 2017