Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

We've got a linux server running sendmail that relays email through our primary mail server, but ever since a change of DNS servers last week, it's been timing out connecting to our mail server. Upon further investigation, /var/log/maillog shows lines like the following, incl. the incorrect IP address for the mail server:

Apr  4 15:37:32 yip sendmail[20583]: p34JVgLE020540: to=<user@domain.tld>, ctladdr=<root@host.domain.tld> (0/0), delay=00:05:50, xdelay=00:02:00, mailer=esmtp, pri=258071, relay=mailserver.domain.tld. [], dsn=4.0.0, stat=Deferred: Connection timed out with mailserver.domain.tld.

Now, we had updated the linux server's DNS servers last week along with the migration by editing /etc/resolv.conf. Running dig mailserver.domain.tld, host mailserver.domain.tld, or nslookup mailserver.domain.tld on the linux server all result in the correct IP address being returned. Where could sendmail be getting/caching the incorrect IP address and how can I resolve that issue?

share|improve this question
up vote 2 down vote accepted
  • Restart sendmail.
  • Restart nscd (if it's in use on the system).

Also make sure you have the correct MX record entries. Sendmail relies on the MX lookup.

Try dig mx domain.tld and see if that results in the correct host. If not, you can force sendmail to deliver mail destined for a particular domain using the mailertable file typically found in /etc/mail/.

A typical mailertable entry looks like: esmtp:[]

Where "" is the domain and the IP for delivery is explicitly stated.

share|improve this answer
I had used dig -t MX domain.tld to verify the MX record matched the hostname of the mail server in question. A restart of sendmail using /etc/init.d/sendmail restart seemed to resolve the issue and mail started flowing. Any idea why sendmail would've held onto the old IP for so long? – morgant Apr 4 '11 at 21:36
@morgant: If you actually changed DNS servers (their addresses, as opposed to their contents), that information is cached from /etc/resolv.conf by libc the first time the resolver is invoked. – geekosaur Apr 5 '11 at 19:15
That explains it. Yes, the DNS server changed and the former DNS server was dishing out old IPs, so it was still querying against the old server. – morgant Apr 6 '11 at 2:15

sendmail does cache information about a host's status before reconsulting DNS. Tweaking Timeout.hoststatus can change this, but then again restarting sendmail for your particular case is the way to go (instead of waiting for the timeout to expire).

share|improve this answer
Thanks, very good to have confirmation of what I was seeing (and how to adjust in the future, if needed). – morgant Apr 5 '11 at 11:18
The default timeout setting for TO_HOSTSTATUS is 30 minutes. Normally this is ok, but some mail providers (like Message Labs) rotate the IPs of their mail servers frequently as an antispam measure. These means that Sendmail may be up to 30 minutes out of date with its IP address for the remote mail host. From what I can tell, the TTL of the DNS records is NOT taken into account in Sendmail's caching. – Doug Luxem Mar 22 '13 at 21:11

Sendmail doesn't do any caching itself, it relies on the local name server.

There's a couple of things that are worth checking, though you'll probably of done them already:

  • Check /etc/hosts has no entries for the relay server, that'll take precedence over DNS
  • Check the Sendmail resolver options to see if it's actually set to use DNS
  • Ensure /etc/resolv.conf is only pointing to updated DNS servers, and 1 of them isn't still returning the old value. Do this manually by running nslookup and entering "server" for each DNS server, remember it could return 2 different IPs on repeat queries if it's set to have duplicate entries. I've seen this plenty of times.

I know they're all pretty basic, but it's easy for a very rushed admin to make a simple mistake like one of these.

share|improve this answer
/etc/mail/ had no entry for ResolverOptions, so it was relying on the defaults (I'm unsure whether that'd include DNSRCH, but I'd assume so). I had used dig @server mailserver.domain.tld to verify that each of the DNS servers in /etc/resolve.conf was dishing out the correct IP. – morgant Apr 4 '11 at 21:34
yes the default includes DNSRCH. – Ewan Leith Apr 6 '11 at 10:12

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.