DNS Settings for Group Managers
Knowledge Base > Documentation > DNS Settings for Group Managers
By Jeroen van Meeuwen on September 16, 2017

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 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

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;

  1. Create a Lite account called applications@yourdomain.tld,
  2. Add the necessary email addresses as aliases for this account,
  3. 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.

Tags: Tags: , , , , , , ,