• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 590
  • Last Modified:

mx records

OK, so what do they do and what are they for?

I thought I knew but today I had a weird problem.

We have 1 lotus server at my location and 1 lotus server at a remote location.  There was a connection "file" that was set on the remote server to send all smtp email to a symantec antivirus gateway.  
We cleared out the IP address of that server and then the email was being passed from the remote lotus server to the lotus server at this location.

NOW - that continued for a while and I posted this in the lotus section.
I started looking through our dns and found that there was only an mx record for the lotus server at our site.  Thinking that the reason the remote email server was sending its email to our server which then passed it onto the pix and out because it only knew about the one email server with the mx record I added in an mx record for the remote lotus server.
Now the email started going right out to the internet from the remote lotus server which is what we wanted.

HOWEVER, to prove the mx record fixed the problem, we deleted it and rebooted everything and the email is still going directly through the PIX.
So, it appears the mx record did nothing to hurt or help.
so where in lotus does it say what and how it will send the email to and do I need that mx record.
1 Solution
ZvonkoSystems architectCommented:
The MaileXchange records in DNS have mostly the rolle to prorize the sequence in which the mail server will accept mails for a domain identified by those MX records for same domain.
If you do not have MX records for that domain, then are the A records and CNAME records responsible for resolving the symbolic names.

The MX records are requested from DNS by mail server for mail forward and relay purposes.
Notes servers will look for Connection documents prior to checking DNS. Look at the Connection documents on each server and see if you have specified a fixed IP address for the connection in question.
thepunish3rAuthor Commented:
Yes, that is what I thought, so I have a connection document and it is an smtp connection doc with a domain name and server.

Now this is what confuses me and being new to lotus doesn't help.

The domain name is like our corporate name shortened with an underscore and another abreviation we use sometimes and then underscore domain so it looks like

xxx_xxx_domain, now this means nothing to me so what is it really?

Then the server name is xxx_gateway and that isn't a real server either and for the relay part of this doc there is no IP address.  There was previously because they use to route the email to a symantec gateway server but we took that IP out and now it goes straight out via our pix which we are happy with but the question is what does that doc do, what does our foreign domain doc do because that has info that is just like this where it seems to just be entered info with nothing really relating to it and no IP addresses.  I can't do any nslookups on these items to see if they mean anything.

Modern healthcare requires a modern cloud. View this brief video to understand how the Concerto Cloud for Healthcare can help your organization.

thepunish3rAuthor Commented:
The other thing is what would the mx record do for me if I added it in for this remote lotus server?  Right now we just have the one for our lotus server.

So what do the internal mx records really do?  I know they are supposed to tell the network who your email servers are when you are getting inbound email but the pix sends all notes traffic right to the lotus server at our site and all smtp traffic still goes to that symantec gateway.  we are going to change that so all traffic goes right to the lotus box.

we are using postini for spam and virus plus another  virus system on the lotus servers and desktops so the gateway isn't doing anything for us really, the spam filter in there stinks.
You didn't mention which version of Notes you're using ... but in general:

Either the Name or IP Address should have a value which leads to another server. So if you're using the nameing convention mentioned, I would assume that there is (or was)either a Server document, Connection document, or host entry for xxx_xxx_domain. And if that led to xxx_gateway, there is/was a Server document for that ... etc.

Bottom-line: If you are routing mail directly to the internet, you do not need a Foreigh SMTP Domain document at all.
thepunish3rAuthor Commented:
Sorry, 6.5

but anyway, where can I find what that gateway points to?  It isn't set anywhere in the connection doc and I have searched everywhere?  But from what I was told by someone else here if that isn't there then email starts routing everywhere else.

One part I forgot to mention is that this is part of a large corporation.
so even though we only look after this site and one other that we are tied to through a frame relay line with there are other lotus servers that replicate to ours.
I checked out their smtp connection docs and they do point to a specific IP in that smtp connection doc.
That Ip is for one of them a netiq system and for the other I am guessing a proxy server.

So maybe the foreign doc is in there for them?  How can I trace down what this xxx_gateway thing is?  They don't reference it anywhere.
The foreign domain doc basically says put *.* to the domain I mentioned above.
That would sound logical.  Without a Foreign SMTP doc, the SMTP server will attempt a direct connection with the destination server based on their MX record.

If you can't find a referecne to xxx_gateway as a Server document, my guess is that is was an IP/DNS name. Either in an internal DNS file or local hosts file somewhere. From your server, do you get any resolution for it via ping or nslookup?
thepunish3rAuthor Commented:
I get no resolution either way.

Now I figure it should somewhere have to be matched to an IP but can't find it and I know it isn't listed in the document.

So I guess the foreign doc does impact our site?  But don't you need a smtp connection doc that ties to the foreign doc?  That is what I believe I read.  So I figure that the foreign doc is there and then for the other sites over sea's they have their smtp doc that details what their smtp relay is.

Now we don't have an smtp relay so I guess the mail then travels out the default gateway of the server, just the nic gateway?
And that is when I thought that how can the remote lotus box at the other us site which we are connected to via framerelay send their email out our pix without it being defined somewhere?  I guess it uses the default gw on the nic but you would think that it also needs an mx record in dns to resolve against because otherwise it wouldn't know it is a mail server and it would see the mx record for the lotus server at our site and then start relaying the mail from there.

Now that is what I thought was happening because yesterday we did this.
Had the NC site - we will call it -, their lotus server which we will call lotus 1 sending email out via a symantec gw.
so lotus 1 sent email to navgw and the navgw was defined in the smtp connection doc as the xxx_gateway and the ip was entered in the doc.
we wanted to stop using the navgw so we took that IP out.
Next I watched the email going out and it was then being passed to lotus 2 - the server at our site.
Now I couldn't find anywhere that would tell the lotus 1 server - if there is no smtp relay configured then use lotus 2, but it did do that on it's own.
So and this is where it got confusing.
I looked at the mx records and noticed there was only 1 for our server in the dns records.  I added 1 for the lotus 1 server in there.
Well I was doing that someone decided to restart the routing service on the lotus 1 server.  
Next the email start traveling right out via the pix which is what we wanted but we didn't know if it was due to the taking out of the IP address in the smtp connection do or adding in the mx record.
So being stubborn as I am, I decided to delete the mx record, clear the dns cache and see if the email would start traveling back through lotus 2 because that is now the only mx record there.  It didn't so I am attributing the taking out of the ip address in the smtp connection doc as the change that started telling the lotus 1 server to send email directly out to the internet.
Now it works fine but what is that smtp connection doc doing for us because I was told without it the email starts routing to the other overseas lotus servers, and also, this means that no mx record is needed for the lotus 1 server?  My understanding was you always needed an mx record for every server that would pass email out to the internet.
Is it possible that is cached somewhere so just because I deleted it the lotus1 server still sees the record somewhere?  I can't find anywhere.
Sort of complicated but I would love to know how it went from routing to the lotus 2 server at this site after removing that ip in the smtp connection doc to going staight out, was it that change or was it adding the mx record and if it was the mx record how is it still working after deleing the record and rebooting all the servers?
The direct answer to your question is NO you do not need an MX record.

You only need an MX record for an SMTP server that will be receiving email (or, to point to a firewall that will route the inbound mail to the incoming SMTP server).  You do not need an MX record to SEND anything.

When your Domino server gets an email destined for the Internet, if the server can see the Internet, the default behavior is to send the message directly out.  You can use Connection documents to change this behavior - for example, to route all outbound traffic through a hub server, or a firewall, or an SMTP relay.
Closed, 500 points refunded.

Community Support Moderator

Featured Post

Concerto Cloud for Software Providers & ISVs

Can Concerto Cloud Services help you focus on evolving your application offerings, while delivering the best cloud experience to your customers? From DevOps to revenue models and customer support, the answer is yes!

Learn how Concerto can help you.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now