Sendmail: Sender address rejected (Domain not found)

Question

I'm running into problems with sending mail on our webserver. Some mails are sent and delivered without any problems (eg Gmail), while others are deferred with "Sender address rejected: Domain not found"

I understand that this is a spam protection measure whereby a lookup is done on the sending domain but our domain has MX records:

Server:     8.8.8.8
Address:    8.8.8.8#53

Non-authoritative answer:
premiumconnect.co.za    mail exchanger = 10 za-smtp-2.mimecast.co.za.
premiumconnect.co.za    mail exchanger = 10 za-smtp-1.mimecast.co.za.

Authoritative answers can be found from:    

(As an aside, why don't we have a authoritative answers? Could that be the problem?)

As well as an A record:

Server:     8.8.8.8
Address:    8.8.8.8#53

Non-authoritative answer:
Name:   premiumconnect.co.za
Address: 196.28.97.202

Here is the logs for a specific mail that was trying to be sent:

Feb  5 12:07:52 premiumconnect sm-mta[2411]: s15C7qYp002411: from=<[email protected]>, size=3522, class=0, nrcpts=1, msgid=<[email protected]>, proto=ESMTP, daemon=MTA-v4, relay=localhost [127.0.0.1]
Feb  5 12:07:52 premiumconnect sendmail[2410]: s15C7q0o002410: to=*****@tott.co.za, delay=00:00:00, xdelay=00:00:00, mailer=relay, pri=33324, relay=[127.0.0.1] [127.0.0.1], dsn=2.0.0, stat=Sent (s15C7qYp002411 Message accepted for delivery)
Feb  5 12:07:52 premiumconnect sm-mta[2413]: s15C7qYp002411: to=<*****@tott.co.za>, delay=00:00:00, xdelay=00:00:00, mailer=esmtp, pri=123522, relay=antispam-vdc-01.gam.co.za. [41.0.5.44], dsn=4.1.8, stat=Deferred: 450 4.1.8 <[email protected]>: Sender address rejected: Domain not found
Feb  5 12:07:53 premiumconnect sm-mta[2413]: s15C7qYp002411: to=<*****@tott.co.za>, delay=00:00:01, xdelay=00:00:01, mailer=esmtp, pri=123522, relay=mx-filter-01.gam.co.za. [41.0.5.131], dsn=4.1.8, stat=Deferred: 450 4.1.8 <[email protected]>: Sender address rejected: Domain not found
Feb  5 12:12:46 premiumconnect sm-mta[2479]: s15C7qYp002411: to=<*****@tott.co.za>, delay=00:04:54, xdelay=00:00:00, mailer=esmtp, pri=213522, relay=mx-filter-01.gam.co.za. [41.0.5.131], dsn=4.1.8, stat=Deferred: 450 4.1.8 <[email protected]>: Sender address rejected: Domain not found
Feb  5 12:12:46 premiumconnect sm-mta[2479]: s15C7qYp002411: to=<*****@tott.co.za>, delay=00:04:54, xdelay=00:00:00, mailer=esmtp, pri=213522, relay=antispam-vdc-01.gam.co.za. [41.0.5.44], dsn=4.1.8, stat=Deferred: 450 4.1.8 <[email protected]>: Sender address rejected: Domain not found

I have little experience with Sendmail (or MTAs in general), not sure what other information could be useful.

Solution 1

I found the problem, once I was pointed in the right direction by the other answers. The (autogenerated) sendmail.mc had a line MASQUERADE_AS(`debian70.vm')dnl, I changed this to MASQUERADE_AS(`premiumconnect.co.za')dnl and the emails are being set correctly now. Thanks for the insight.

Solution 2

This error is specifically regarding the 'from' address, not the sending mail server. As such, MX records are not relevant, and your MTA settings are probably not relevant.

The issue is that you're sending an e-mail from "[email protected]", which the recipient correctly determines cannot possibly be a valid e-mail address, since the debian70.vm domain does not exist.

The solution will depend on how exactly you're generating these e-mails. One option is to specify the desired 'from' address in whatever software is generating these mails.

On the other hand it looks like you're not actively specifying a 'from' address, but letting the system generate one. In that case, the part after the @ is set based on what the system thinks is its mail name. Debian checks '/etc/mailname' to determine this, and if it doesn't find anything then it uses its fully qualified domain name, which in your case is 'debian70.vm' - a name that's only valid for your internal network since it's in the .vm top-level domain.

If you edit /etc/mailname (creating it if necessary) to say 'premiumconnect.co.za' (without the quotes), it will probably solve your problem.

If not, then that could indicate that an MTA is generating the address based on some other configuration, so we would need to know more about your MTA setup.

Solution 3

How is it supposed to resolve the domain debian70.vm? looks to me you're using [email protected] as the sender address. The spam check is done over debian70.vm, which can't get resolved.

Comments

[NickW]

If you're not giving out Authoritative replies, you need to make sure that your domain registrar has your NS servers listed..

[JonoCoetzee]

Our domain registrar forces us to use their name servers, couldn't change if I wanted to unfortunately...

[NickW]

Well, if you are forced to use theirs, you need to ensure that their NS servers are returning the records YOU want, and that includes a proper MX record. Also ensure that either your ISP or your hosting company publishes a proper RDNS record for your mailserver.

[JonoCoetzee]

Okay, the records returned above are correct for our domain and what is set in the authoritative NS (at the registrar), including the MX record which point to an external mailserver. Also the mailserver (defined in the MX record) resolves with a reverse DNS lookup. The domain/webserver don't though, not sure if this would affect things?

[NickW]

So, are your webservers relaying through your mailserver? That would be the simplest way to ensure that the mail they are sending will go through..

[stoned]

@slm Nope. That's actually the answer imho. To me he's trying to sending mail as [email protected], whose domain can't get resolved by the remote server. Sorry if it's not clear, I'll modify my answer.

[NickW]

stoned is right, that is the primary issue.. a secondary one might be why his relay server is accepting addresses like that :)

[slm]

@stoned - the edit makes it better, I've removed the comment, thanks.

[JonoCoetzee]

I get that, if you look at the first line in the log you'll see that that the from address is set: from=<[email protected]>. I have have already tried setting /etc/mailname. What would cause this not to work?

[JonoCoetzee]

I tested again with Gmail and the emails are still coming through as [email protected]? I have restarted the sendmail service but no change.

[JonoCoetzee]

I have Authentication-Warning: premiumconnect.co.za: www-data set sender to [email protected] using -f in the mail.log, could this be related?

[JonoCoetzee]

I agree that this is the problem, I thought it was going through with the correct sender but obviously not. I have commented on @Nye's answer with more details.