Closed oasis1234 closed 6 years ago
The wiki error was spotted previously https://github.com/atech/postal/issues/587#issuecomment-388324086 and hopefully will be corrected.
Postal is DMARC compliant (https://github.com/atech/postal/issues/424#issuecomment-349602340) but isn't set up out of the box to handle the reports so shouldn't take responsibility for enforcing or recommending DMARC on your domains.
Domains you use with Postal should have DNS records that reference domains that point to your Postal server. I'm not sure where you're getting confused and what autofills you're seeing.
I'm also not sure where you're seeing the root DNS records.
MX Toolbox may simply not be programmed to follow CNAMEs to their destination. Email servers that send returned mail have no problem following the psrp path. There are indeed limits for lookups but if you're that close to them already that Postal puts you over the edge, you probably have many other services involved and need to simplify your domains existence. We have recently solved this issue for one of our customers.
Ok, I was confused because I thought that I could add multiple domains to Postal that will have their own DNS values. But after testing I realized that you create a "master domain" in postal.yml and then several "slave domains" that will reference the "master domain". So the secondary domains are like alias of the primary domain. Nevertheless, it would be clearer if the web interface showed that difference, instead of listing all the domains at the same level.
As you pointed out, the documentation does need a little work to be completely clear and Postal is, in effect, a white-label software package that could be resold so everything references the master domain name.
Postal project looks awesome, but I failed so hard at Dns setup step. There were conflict between Dns setup page, postal.yml and Wiki page
It would be great if someone update the postal.yml file instructions, Dns setup wiki page, domains -> Dns setup page :+1:
I've fixed the MX error in the wiki :+1:
https://github.com/atech/postal/wiki/Domains-&-DNS-Configuration This guide is really confusing. Shows a mx.mail.example.com that doesn't exists (the mail server is mail.example.com, not mx.example.com nor mx.mail.example.com). It says nothing about configuring the most important record: the MX record. I found out that there was a "MX Records" section that was deleted. https://github.com/atech/postal/wiki/Domains-&-DNS-Configuration/_history Besides, there is a conflict between the 'DNS Setup' page and the values in postal.yml that leaves the user completely clueless. The setup step order is the key. My guide (https://github.com/atech/postal/issues/614) explains clearly the setup steps in the right order, and has all the values the user needs to edit. The official guide doesn't include the DMARC record, which is important. The 'DNS Setup' page takes the values from postal.yml. How am I supposed to add more domains? Even when creating a new organization or server, Postal autofills the new added domain with postal.yml, so the DNS verification fails.
DNS records at root. @ A 1.2.3.4 @ MX 10;mail.example.com @ TXT v=spf1 a mx include:spf.mail.example.com ~all They aren't required, as the mail server and the web management are in mail.example.com. Nevertheless they are required by the 'DNS Setup' page verification. (Note: the MX at root is only for incoming email, if needed).
Do we really need chained DNS records? psrp.example.com -> rp.mail.example.com -> spf.mail.example.com https://mxtoolbox.com/ complaints psrp is a CNAME and rp.mail "SPF Void Lookups" I don't have time to discuss this, just do your tests at https://vamsoft.com/support/tools/spf-policy-tester and check the internals. There're limits for DNS lookups. I tried to shorten that but spf.mail.example.com it's hard-cored and required for verification.