A group manager account with Kolab Now consists of one or more domains your users use to send and receive email. This article outlines DNS Zone settings you may apply to your domains, so that email is sent and received correctly, and up to the highest standards.
In this Article
- Where does email for your users need to be submitted?
- Who’s allowed to send email from your domain(s)?
- How strict should receiving parties be applying your policies?
Where to does email for your users need to be submitted?
MX records contain information about the receiving email servers for the domain. Since your groupware is hosted with Kolab Now, the following MX records should be considered for your domains:
MX 10 mx01.kolabnow.com. MX 10 mx02.kolabnow.com.
Do not omit the trailing dot (.) character.
Among other benefits, MX records are useful to distinguish the target servers for email traffic from the target server(s) for web traffic. For a zone with no MX records, email would be submitted to the address for the domain. For example, if a website https://example.com were to land at an address 93.184.216.34, and the domain example.com has no MX records (it doesn’t), then email for the example.com domain would be submitted to the SMTP server at 93.184.216.34 (this server doesn’t respond on port 25).
MX records also allow for a priority indicator (this is the 10 in the aforementioned set of MX records). This was originally implemented to allow for a “backup SMTP server” to be specified, to be used if the “primary” was unavailable for some reason, and while most regular email services will obey the priority specified, several implementation details in reality have meanwhile negated its value;
- Temporary failures indicating to sending servers, that delivery should be re-attempted at a later date, often cause senders to contact the backup SMTP server immediately.
- Spam bots may elect to attempt delivery to backup SMTP servers first, as backup SMTP servers all too often have fewer and less strict anti-spam restrictions in place.
See Also
- FAQ: Can I use MX records that use my own domain?
- FAQ: Can I specify an additional MX record for my domain?
Troubleshooting your MX Records
Verify your MX records are configured correctly using, for example, nslookup.
$ nslookup > set type=mx > kolab.org Server: 8.8.8.8 Address: 8.8.8.8#53 Non-authoritative answer: kolab.org mail exchanger = 10 mx01.kolabnow.com. kolab.org mail exchanger = 10 mx02.kolabnow.com. Authoritative answers can be found from: >
Sometimes, if you have changed your MX records very recently, the zone changes may not have propagated yet, and you’re hitting a cached entry. To work around this delay in propagation, ensure you use the Start of Authority (SOA) nameserver, or any of the name servers listed:
$ nslookup > set type=soa > kolab.org Server: 8.8.8.8 Address: 8.8.8.8#53 Non-authoritative answer: kolab.org origin = sec1.rcode0.net mail addr = hostmaster.kolabsys.com serial = 2017091601 refresh = 1200 retry = 600 expire = 1814400 minimum = 60 Authoritative answers can be found from: > server sec1.rcode0.net Default server: sec1.rcode0.net Address: 192.174.68.100#53 Default server: sec1.rcode0.net Address: 2001:67c:1bc::100#53 > set type=mx > kolab.org Server: sec1.rcode0.net Address: 192.174.68.100#53 kolab.org mail exchanger = 10 mx01.kolabnow.com. kolab.org mail exchanger = 10 mx02.kolabnow.com.
Which servers are allowed to send email from your domain?
To indicate to the rest of the world that only a limited number of servers on the Internet are allowed to send email from your domain, you use a Sender Policy Framework (SPF) record. The simplest form of such records looks as follows:
TXT "v=spf1 mx -all"
This record reflects that the sender policy framework version used is 1, and that the server systems that are also listed as the MX records for the domain are allowed to send email from your domain. Lastly, the “-all” is used to exclude all other server systems.
However, you may have a application server hosted some place else, that is supposed to be allowed to send out email messages as well; the best thing to do is to configure those applications to send email through Kolab Now;
- Create a Lite account called applications@yourdomain.tld,
- Add the necessary email addresses as aliases for this account,
- Configure your applications to submit messages using SMTP using the same settings as for any desktop client or mobile device.
If your applications do not allow you to configure a submission account, or you wish to save yourself the additional expense of a Lite account, alternative SPF configurations are available.
Allow recipients to mark the email as potentially violating your policies, but do not reject the message delivery;
TXT "v=spf1 mx ~all"
Designate particular servers to send email from your domain:
TXT "v=spf1 mx ip4:10.11.12.0/24 -all"
For a more complete definition of what is possible in your policies, please refer to open-spf.org.
DMARC Policy Definition
Outbound email submitted through Kolab Now is signed with DKIM. Sender domains define DMARC policies to define how receivers should treat mail that cannot be verified as to originate from the designated infrastructure. For more information on DMARC specifics, please refer to dmarc.org.
Customers of Kolab Now can add DMARC policy definitions to their DNS zones. A liberal definition of such records would look as follows:
_dmarc TXT (
"V=DMARC1; "
"p=none; "
"adkim=r; "
"aspf=r; "
"rua=mailto:dmarc-rua@your.domain; "
"ruf=mailto:dmarc-ruf@your.domain"
)
The email addresses listed here receive occasional reports from receiving parties, that summarize success and/of failure of verification and authentication routines.
A more strict policy would look as follows. You can slowly move the adkim and aspf settings from r (relaxed) to s (strict), and upgrade the p (policy) from none to quarantine to reject if you so wish.
Note though, that email through Kolab Now infrastructure will be signed with a d=kolabnow.com DKIM parameter, voiding alignment validation between third party domains and the DKIM signature. To avoid this problem, keep adkim=r, or keep p=quarantine (but never escalate to adkim=s in combination with p=reject).
_dmarc TXT (
"V=DMARC1; "
"p=quarantine; "
"adkim=s; "
"aspf=s; "
"rua=mailto:dmarc-rua@your.domain; "
"ruf=mailto:dmarc-ruf@your.domain"
)
DNS Entries for Automatic Configuration and Discovery
Depending on the clients used, either one or all of the following DNS entries are required, or recommended for some or all of the supported desktop client applications. Various versions of client applications may have implemented different routines or use a different order to attempt to get to automatic configuration of the client. Long story short, it’s best to include all of them in your DNS zones.
autodiscover CNAME apps.kolabnow.com. _autodiscover._tcp SRV 0 0 443 apps.kolabnow.com. _caldav._tcp SRV 0 0 80 apps.kolabnow.com. _caldavs._tcp SRV 0 1 443 apps.kolabnow.com. _carddav._tcp SRV 0 0 80 apps.kolabnow.com. _carddavs._tcp SRV 0 1 443 apps.kolabnow.com. _imap._tcp SRV 0 0 143 imap.kolabnow.com. _imaps._tcp SRV 0 1 993 imap.kolabnow.com. _pop3._tcp SRV 10 0 110 imap.kolabnow.com. _pop3s._tcp SRV 10 1 995 imap.kolabnow.com. _sieve._tcp SRV 0 0 4190 imap.kolabnow.com. _submission._tcp SRV 0 1 587 smtp.kolabnow.com. _webdav._tcp SRV 0 0 80 apps.kolabnow.com. _webdavs._tcp SRV 0 1 443 apps.kolabnow.com.