The FreeBSD Diary

The FreeBSD Diary (TM)

Providing practical examples since 1998

If you buy from Amazon USA, please support us by using this link.
Returned mail: Data format error (Sender domain must exist) 4 March 2000
Need more help on this topic? Click here
This article has 2 comments
Show me similar articles
This article deals with an obscure error message I received when I encountered mail which was being rejected because of a "Sender domain does not exist" problem.
The example
Here is the message which bounced back to me.  Certain bits have been changed to protect the idiotic.

Date sent: Fri, 3 Mar 2000 12:43:12 +1300 (NZDT)
From: Mail Delivery Subsystem <MAILER-DAEMON>
To: <>
Subject: Returned mail: Data format error

The original message was received at Fri, 3 Mar 2000 12:43:04 +1300 (NZDT)
from []

----- The following addresses had permanent fatal errors -----

----- Transcript of session follows -----
... while talking to
>>> MAIL From:<> SIZE=1101
<<< 501 <>... Sender domain must exist
501 <>... Data format error

This problem didn't take me very long to understand the cause.  It's right there: "Sender domain must exist".  When the mail server receives the message I sent, it checks the return address to verify that the sender domain exists.   For some reason, my box was using the wrong domain.  I wasn't sure where to change this, but then I remembered how I had split my domain name space into private and public sectors.  I checked the zone file which contains my reverse look-ups (i.e. the file that maps IP addresses to host names; see my zone files for an example) and I found the problem there.

The solution

In my reverse lookup file, I found this:

20 IN PTR    

Ahhh!  There's the problem.  When sendmail on my box sends out a message, it looks up the host name for the IP address on which it's running.  In this case, the reverse lookup resolves to an internal domain, which nobody can resolve because I don't export that sub-domain (i.e.  Note that "int" in this context refers to "internal", not "international".

I changed the above line to:

20 IN PTR    

...and then I HUP'd named.  I then sent out a sample message.  It's important to make the destination address somewhere other than yourself  In other words, don't send a test messge from your server to your server.   That would not be a valid test.  I solved this issue by sending a message to my email address at my ISP.

Some observations
I remain unconvinced that my actions solved the problem.  As part of my testing I reversed my changes to observe the effect.  I couldn't reproduce the problem.  I HUP'd both sendmail and named.  I couldn't get the old problem back.

For what it's worth, here is a side-by-side comparison of the before and after headers of my test messages:

Return-Path: <> Return-Path: <>

It's important to note the change in the above lines.  On the left is the before image.  The return page contains the hostname of my box.  On the right is the after image.  It contains the reply-to address which is configured in my mail client.   That's interesting.  As I said, I tried to do some testing in this area to reproduce the problem but failed.  Therefor I'm not sure if my conclusions are 100% accurate or not.

Another possible cause 30 September 2000
John Conway wrote in with this note:

I had the same thing, but I don't have any reverse for my ip's.  The problem was in the DNS file, that particular server was not stated with:

myhost    A <ip here>

So if someone wanted to go to the server, it wasn't able to find an ip for server ..which was what it was showing as the

I added this to the dns file

blah    IN     A

In short, the host which was sending the mail had to have an IP address associated with it.  Before John added the host to his DNS file, nslookup would have failed.

Need more help on this topic? Click here
This article has 2 comments
Show me similar articles