Hi Viktor, thank You for Your explanation. I searched for some opinion from external people. I understand how mail system is working. The problem for me and my team is our consultant which completly do not understand how mail system is working and he trying to push some strange configurations to our mail system. With Your E-mail it will be much easier for me to force also some other topics.
@All, thank You very much for Your efficient (and super fast!) support. For me topic is closed. Short summary: Incoming messages: a) DNS A, PTR, MX Outgoing messages: a) DNS A, PTR, SPF Once again thanks for Your support. On Tue, Nov 10, 2015 at 9:49 PM, Viktor Dukhovni <postfix-us...@dukhovni.org > wrote: > On Tue, Nov 10, 2015 at 09:29:19PM +0100, Zalezny Niezalezny wrote: > > > We have two systems which are dedicated only to send E-mails. Mostly for > > massmailing. These two machines will not receive any E-mails. > > Don't confuse "systems" (SMTP servers) with email domains (the > domain part of an rfc822 email address). Your *systems* do not > need MX records. They just need FQDN hostnames, and their IP > addresses need to a PTR record that provides each system's hostname. > > Nor do the MX records of the envelope sender domain of the message > being sent need to point at the sending systems. It is not unusual > to have separate systems sending and receiving mail. > > > Do we realy > > need to configure MX records for that systems if they are not receiving > any > > E-mails? > > No MX records are required for your *systems* (SMTP servers). > > > From my point of view checking MX record from the client which > > sending message is ... strange... if not stupid... In the SPF record we > can > > have a lot of systems which are not necesserly configured in the MX > record. > > If you have SPF records for the envelope sender domain, then the > sending IP addresses should be listed there. In any case the > envelope sender domain need to resolve to a set of valid public > addresses or a set of MX hosts with valid public addresses. > > -- > Viktor. >
