421 invalid sender domain
Hello,
One of my clients that I'm constantly doing business with - starting a week ago - begin not receiving my E-mails in time - When I say - not in time - means that they will receive my E-mails about 24 h later.
I didn't change anytihing in our mail server in the past week.
Eventualy after couple of hours I am getting a response back from them saying:
"421 invalid sender domain, possibly misconfigured"
I did run several searches on the Internet related to this issue and somewhere there was an explanation like this error denotes a temporary delivery failure. "This error indicates to your mail server, that it should attempt to resend the email later"
I did email to the e-mail address in question from two different places and it works great and fast.
From my domain - does not work. I am not blacklisted in any server.
One of my clients that I'm constantly doing business with - starting a week ago - begin not receiving my E-mails in time - When I say - not in time - means that they will receive my E-mails about 24 h later.
I didn't change anytihing in our mail server in the past week.
Eventualy after couple of hours I am getting a response back from them saying:
"421 invalid sender domain, possibly misconfigured"
I did run several searches on the Internet related to this issue and somewhere there was an explanation like this error denotes a temporary delivery failure. "This error indicates to your mail server, that it should attempt to resend the email later"
I did email to the e-mail address in question from two different places and it works great and fast.
From my domain - does not work. I am not blacklisted in any server.
Do they have some kind of spam appliance that is sitting in front of their mail server? It seems like your messages are being delayed for some reason. Typically you can get tagged as spammer locally and sent to an admin quarantine. It is not as harsh as universal blacklist but you just might be caught in one of their rules. Are you sending attachments? Can you time test with their admin folks and see if they can track the message on their side once you send it? The other possibility is that inbound mail servers are unable to resolve the reverse DNS, or PTR, record for the IP address of your mail server, and received an NXDOMAIN response to queries. The solution to this problem will be for you to contact your ISP and/or hosting provider to get a valid PTR record setup for your server's IP address.
ASKER
Well.... did some other new things.
They host their site and have the mail server at 1&1 ....
It happen that I have couple domains hosted there as well (only as registar)
I set up an E-mail account - adn guess what - my E-mail was rejected, but my other two E-mails went tru.
So bottom line - it seems that 1and1 mail server ahs some kind a rule - or spam filter that they reject the E-mails coming from my work domain.
I did call the IT on the other side (recipient side) to tell him to deal with 1&1.
I'll update accordingly
They host their site and have the mail server at 1&1 ....
It happen that I have couple domains hosted there as well (only as registar)
I set up an E-mail account - adn guess what - my E-mail was rejected, but my other two E-mails went tru.
So bottom line - it seems that 1and1 mail server ahs some kind a rule - or spam filter that they reject the E-mails coming from my work domain.
I did call the IT on the other side (recipient side) to tell him to deal with 1&1.
I'll update accordingly
"421 invalid sender domain"
That probably means the HELO setting in your server is either not something legal or resolvable. That setting needs a real fully qualified domain name. Like mail.yourdomain.com or smtp.somewhere.net. By default I think this setting is set to the machine name, which is bad if you're using some internal AD name like exchange.ourad.local. Best to change it to the same as your reverse dns and MX records.
What server and version are you using? This is posted in both sendmail and exchange zones, so I'm not sure which it is.
For Exchange (2003) you would set this in the ESM -> servers -> [yourserver] -> protocols -> smtp -> properties on the virtual server -> delivery tab -> advanced button -> fully qualified domain name field.
For Sendmail it can be tricky depending on the role of the machine. But you really only need to change the IP entry in the /etc/hosts file.
That probably means the HELO setting in your server is either not something legal or resolvable. That setting needs a real fully qualified domain name. Like mail.yourdomain.com or smtp.somewhere.net. By default I think this setting is set to the machine name, which is bad if you're using some internal AD name like exchange.ourad.local. Best to change it to the same as your reverse dns and MX records.
What server and version are you using? This is posted in both sendmail and exchange zones, so I'm not sure which it is.
For Exchange (2003) you would set this in the ESM -> servers -> [yourserver] -> protocols -> smtp -> properties on the virtual server -> delivery tab -> advanced button -> fully qualified domain name field.
For Sendmail it can be tricky depending on the role of the machine. But you really only need to change the IP entry in the /etc/hosts file.
I am experiencing the same issues and 1and1 are being as unhelpful as ever. I dotn suppose you know what was doen to fix this for your client?
Regards
Regards
1and1 I agree is completely worthless.
I have resolved this issue a few times in the past with clients that have Cisco Pix firewalls. How to fix you need to remove the mail guard on the pix.
its my guess 1and1 looks that the banner from the sender. They see 220 ******** instead of 220 mail.mydomain.com....
http://mcdmagix.blogspot.com/2008/06/ms-exchange-smtp-behind-cisco-pix.html
So if you have a PIX this is more than likely the fix.
I have resolved this issue a few times in the past with clients that have Cisco Pix firewalls. How to fix you need to remove the mail guard on the pix.
its my guess 1and1 looks that the banner from the sender. They see 220 ******** instead of 220 mail.mydomain.com....
http://mcdmagix.blogspot.com/2008/06/ms-exchange-smtp-behind-cisco-pix.html
So if you have a PIX this is more than likely the fix.
I ran into the same problem today, also with 1and1. We have multiple domains behind our exchange server, all going out as our primary domain, which has a fqdn and correct reverse, so we comply with the RFC. I called 1and1 to see what was up, and I was told that "because of the conversion between mac and windows, they adopted a policy that IS NOT RFC compliant that does not accept email from a mail server that uses aliases for sending emails" Not sure what the mac to windows thing is, but that's what she said.
So unless you have a mail server for every domain you host mail for, you will not be able to send email to 1and1
So unless you have a mail server for every domain you host mail for, you will not be able to send email to 1and1
Sorry I forgot to add this...ensure your MX record is not a CNAME...create an A record.
I ran into the exact problem today with a domain hosted by 1and1. Our HELO setting is correct is far as it can be, it is the FQDN of our Exchange server & matches public A records. But it will never match a MX record because our organization uses an external Spam server (Trend Micro). If we create an MX record with our FQDN & Trend Micro spam servers go down, all email will be sent directly to our organization. I wonder if 1and1 thought about this type of setup at all when they made whatever change they made in the last few days.
I believe that I just solved this problem for a mail domain who doesn't host DNS through servers I manage, but uses my managed email servers for Smarthosting and Spamfiltering. I still need to do final testing on Monday to verify, but here is what I found.
For all DNS domains that we host, where we have a SPF (Sender Policy Framework) record defined in DNS. For all these domains that use us for Smarthosting and have this entry, they can send without any problems to 1and1.com mail servers.
For domains that were missing a SPF record in DNS, they received the 421 error after sending the RCPT TO: command to the 1and1.com servers.
The SPF record that is working for us looks like
Hopefully this works for you.
For all DNS domains that we host, where we have a SPF (Sender Policy Framework) record defined in DNS. For all these domains that use us for Smarthosting and have this entry, they can send without any problems to 1and1.com mail servers.
For domains that were missing a SPF record in DNS, they received the 421 error after sending the RCPT TO: command to the 1and1.com servers.
The SPF record that is working for us looks like
mydomain.com. 86400 IN TXT "v=spf1 mx ~all"This tells email servers that the only mail servers that are allowed to send email from a domain are those that are listed as MX records so you need to make sure that the outbound email is going from a MTA that is also listed as the MX record for the domain.
Hopefully this works for you.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
We also use Trend Micro IMHS. I was expecting an email from 1&1, but they never came through. What is the priority 20 mx that you have used? We have around 60 domains ALL having this problem.
If you could let me know, that would dig me out of a small hole.
Thanks in advance.
If you could let me know, that would dig me out of a small hole.
Thanks in advance.
I don't mean to hijack the thread, but contact Trend and tell them you are having problems delivering to 1and1 because the MX record is a CNAME. They will give you another name to add at a preference of 20. Here's what i have:
10 - in.sjc.mx.trendmicro.com
20 - in.mx.trendmicro-fail-over
Those settings might not work for you though.
10 - in.sjc.mx.trendmicro.com
20 - in.mx.trendmicro-fail-over
Those settings might not work for you though.
Thank you for your reply.
This may help a few other people that are having this problem.
We spoke to our ISP (Zen Internet) and they worked out the same thing.
Our MX for Trend IMHS is in.mx.trendmicro.eu.
This then returns 4 records; in.eu.mx.trendmicro-fail-o
This was the problem that 1&1 will not accept from a domain that has a cname for an mx.
Implenting the same method at matt_monaco has on all of our domains, we created a lower priority mx record with in.eu.mx.trendmicro-fail-o
This meant that 1&1 would check the first mx - not like it, check the second one (which returns an IP instead of a name) and then accept the mail.
Having the two mx entries means that the mail will work in the same way as before, yet would keep any company adhering to the RFC regarding cnames for mx, happy. :)
Hope this helps some other people.
This may help a few other people that are having this problem.
We spoke to our ISP (Zen Internet) and they worked out the same thing.
Our MX for Trend IMHS is in.mx.trendmicro.eu.
This then returns 4 records; in.eu.mx.trendmicro-fail-o
This was the problem that 1&1 will not accept from a domain that has a cname for an mx.
Implenting the same method at matt_monaco has on all of our domains, we created a lower priority mx record with in.eu.mx.trendmicro-fail-o
This meant that 1&1 would check the first mx - not like it, check the second one (which returns an IP instead of a name) and then accept the mail.
Having the two mx entries means that the mail will work in the same way as before, yet would keep any company adhering to the RFC regarding cnames for mx, happy. :)
Hope this helps some other people.
ASKER
Because we use a CNAME for the MX record .... that's why we had the issues. Changed that and it all works.