Callout Verification Failures

I keep getting messages that make me believe someone’s doing Sender Verification on their end and that perhaps I’m not accepting their verification messages. I’m seeing stuff like this in my returned email: host[[]]
said: 550-Verification failed for 550-Previous
(cached) callout verification failure 550 Sender verify failed (in reply to
RCPT TO command)

Is there a switch I can flip that will enable me to handle this verification process when I send mail from my server?

What a booger! I think I figured it out!

A few weeks ago, I had an old domain name transferred off of rented server space and into my own control. The guy I rented space from still hosts two other domains for me. But I moved this particular one to my own server under webmin control.

When I transferred, the guy I rent from told me he would keep my old site around on his system just in case I had to go back to it later. I did not think twice about it. If he wanted to keep it, that was alright.

But, when I tried to send mail from the domain name I transferred to this guy or to one of the other two domains that he still hosts for me, I kept getting bounced/rejected.

I do believe now that if he were to purge my old domain from his system that I will no longer have this problem. I’m probably hitting an old DNS entry or mail entry on his servers, and they are getting confused.

We’ll see what happens during the next couple of days.

  • Mark

Hey Mark,

This should only happen if you haven’t gotten the nameservers updated correctly with your registrar (though that could take a couple of days). It won’t matter whether the old site is still running or not…if a client DNS server gets old data it’ll either fail to connect or get the old server, it won’t magically get the new server. You can do some checking up on this with dig and whois.

whois domain.tld

Look for the nameserver line. Be sure they reflect the new reality. If they don’t, fix them with your registrar.

dig domain.tld

Look to see that you’re getting correct data. If not, look at your nameservers.

You can check specific nameservers with:

host domain.tld

With just this, you can spot any DNS trouble, except propagation time (it takes different times for nameserver changes to propagate).

There’s one tricky bit that often trips people up: Make sure your NS records are correct in your DNS zone for the domain. If they’re wrong, domains could resolve indirectly some of the time (because you’re then redelegating the zone out to someone else, in addition to the root name server delegating the tld to your nameserver). I’ve seen this one get people very frequently.

Hey Joe,

I got it fixed. I’m not totally sure which action took care of it, but we did two things:

  1. The guy who hosted for me previously deleted the old website from his server. This eliminated any possibility that I might be finding an old address laying around when I sent email there. This may or may not have helped, but I quit getting 550 Error codes then. Instead, I began to get 503 Error codes.

  2. After doing a lot of testing, I discovered that I could log into his server and send mail out through my accounts alright. If, though, I tried using Outlook, then I got the 503s. I looked them up on the web, and I discovered that Outlook had to be configured to do authentication for my outgoing server. After I changed that, everything worked well for me. I’m betting that he began to authenticate things a bit differently on his end, and we didn’t know the full ramifications of it.

Conclusion: None of my problems were a result of Webmin or of improper DNS settings on my end of the link. As with most issues I’ve had lately, it’s a matter of tuning something trivial.