452 bounce codes using relay.force9.net

[#1]

I have a persistenly stubborn error for one email address when sending through Force9/Plusnet servers. The dreaded 452 error relating to recipient/quota/etc. Mail sent via Google Mail to this address is fine ! Webmail also fails with the 452 error. The email address is an important business address so this is getting very urgent. If it helps the client is using Office365(I know !)

[#2]

Is anyone else seeing this sort of problem? It seems to be a problem with dns at Plusnets end as the office 365 ips keep changing for the customers domain

[#3]

If the local computer uses DHCP assigned DNS IPs you could try setting it to use a fixed DNS instead. Google Public DNS IPs 8.8.8.8 and 8.8.4.4 are popular choices.

[#4]

Thanks for the reply spraxyt but its the Force9 relay server that's returning the 452 bounce code.

I've tried sending the test messages direct from my pc to the force9 smtp server, from my pc via 3 of my mail servers on different domains, and finally through webmail.

All bounce back with the 452 code albeit with different ending text, e.g. 

452
    ... temporary failure (in reply to RCPT TO command)
or
452 error... failed to add recipient

What I have seen when running a dig mx command or mxtoolbox info , is that the ip of the office365 smtp server had changed a couple of time...it also look as if there may be a dns autority problem with that to. However, mail sent from Google reached the customer in all cases...just not any at all from Force9

[#5]

Sorry about the [-Censored-] spelling...my fingers aren't working properly at present!

[#6]

I don't think dig MX on the recipient's domain returning different IPs is significant, it simply means more than one MX is available to accept the message. For example dig outlook.com mx returns 4 IPs to me.

Since the message has a temporary code I think the Force9 relay will have successfully found a mail server for the recipient. However that server is refusing the message and returning the 452 error code and description. Google servers getting through but not Force9 ones suggests the recipient might be blocking/delaying messages from the Force9 relay.

When you said you tried sending directly from your PC to the relays was this done using telnet or a mail client?

[#7]

Thanks for the reply spraxyt. The test messages were sent via Thunderbird in all cases except webmail where I used Roundecubemail on Force9. I use relay.force9.net as a smart host to Postfix on Linux servers but I did also test relay.plus.net with the same results. I also tried all ip variants of the two.I watched Postfix's logs as the messages went through and were rejected. The message sent direct was from Thunderbird using relay.force9.net I cant see that any Force9/plusnet servers are on blocklists at present so why Office365 should be blocking them is a bit of a mystery! I must say that the customer outsources his IT to a 3rd party so convincing him that the problem may lie at his end is not going to be easy.