Deploying autodiscover records in public DNS simplifies adding a Zimbra account to any device. This blog post will show you how.
Introduction
Yes, we like the Zimbra web client very much (and are even starting to like the Modern UI too — though that’s another blog post…). But, sometimes you need to configure an IMAP, ActiveSync, CardDAV or CalDAV email client. Without autodiscover records, it’s a pain to add such accounts. It forces users to enter a lot of information, and presents opportunities for users to make mistakes, causing frustration for the users and more tickets for the Help Desk.
With proper autodiscover records in public DNS, configuring those new IMAP, ActiveSync, CardDAV or CalDAV email clients is seamless. You’ll need to enter your username and password, and on iOS for example, choose “Manual Configuration”. After doing so, you’ll be taken immediately to the Verify screen, which will immediately display successful verification checkmarks.
You are done! Easy-peasy!
Technical Background
Autodiscover records tell an email, calendar or address book client where to go to get its data.
Autodiscover records are deployed in the same email domain where the user’s email address lives. So if the user’s email address is like john.doe@mycompany.com, you’d need to deploy the autodiscover records in the public DNS zone file for the mycompany.com domain.
The FQDN in each autodiscover record doesn’t have to be on the same domain; that FQDN is typically the Zimbra Proxy server (or F5, AWS NLB or other Layer 4 load balancer) that john.doe@mycompany.com would normally connect to if using the Zimbra web client.
For our hosting environment, our Amazon Web Services Layer 4 Network Load Balancer has the FQDN “mail.missioncriticalemail.com” (and is also the PublicServiceHostname for all of the domains we host).
The DNS record examples below are all in BIND9 format. Do note the period at the end of the FQDN at the end of most of the records. In BIND9, this is required to prevent BIND9 from appending the domain to the entry. In other words, without the period at the end, BIND9 thinks the entry is a hostname, and appends the domain name of the domain where you are adding these records. To be clear, if we were deploying the below autodiscover records on the mycompany.com domain, and didn’t include the period, the FQDN presented to the client would be “mail.missioncriticalemail.com.mycompany.com“. No server lives there, so autodiscover would fail.
Implementation – IMAP
We need two autodiscover records for IMAP: one for the IMAP client to fetch email, and one for the IMAP client to send email via SMTP-Auth, using the Submission port TCP/587. Both are SRV records, and the records should look like those below. Note that it’s a good idea to start with a short TTL like we have done here (300 seconds), and then when you are comfortable that you got it right and that things are working OK, you should increase the TTL to like a day or so (86400 seconds for example).
_imaps._tcp 300 IN SRV 0 0 993 mail.missioncriticalemail.com. _submission._tcp 300 IN SRV 0 0 587 mail.missioncriticalemail.com.
Implementation – ActiveSync
Here we also need two records, but one is a CNAME and one is an SRV. Same deal… start with a short TTL and then increase once you’ve tested and satisfied yourself that all is good.
autodiscover 300 IN CNAME mail.missioncriticalemail.com. _autodiscover._tcp 300 IN SRV 0 0 443 mail.missioncriticalemail.com.
Implementation – DAV
The DAV protocol is well-supported by Zimbra, and also by Apple products and almost all third-party email/calender/contacts clients with which I am familiar. If you are running Open Source Zimbra and don’t have ActiveSync, deploying IMAP, CardDAV and CalDAV on your workstation or mobile is a reliable way to go — especially if you have a large mailbox. (In our experience, ActiveSync is a bit fragile and doesn’t handle large mailboxes all that well all the time, especially on high-latency cellular connections).
For each of CardDAV and CalDav, you need two autodiscover records. The first as above tells the client where to find the server holding the user’s account. The second is to tell the client where on the server the user’s data lives within the user’s account:
_caldavs._tcp 300 IN SRV 0 0 443 mail.missioncriticalemail.com. _caldavs._tcp 300 IN TXT "path=/dav/%u" _carddavs._tcp 300 IN SRV 0 0 443 mail.missioncriticalemail.com. _carddavs._tcp 300 IN TXT "path=/dav/%u"
Conclusions
Configuring autodiscover records simplifies account setups for all users, and will reduce your Help Desk tickets for sure (unless of course you make a mistake in one of the records and deploy the record with a long TTL…)!
It’s straightforward in every DNS system we’ve used to configure these records, and the benefits are immediate.
If you’d like help with your autodiscover or other email-related DNS records, fill out the form and we’ll get right back in touch:
Hope that helps,
L. Mark Stone
Mission Critical Email LLC
22 July 2025
The information provided in this blog is intended for informational and educational purposes only. The views expressed herein are those of Mr. Stone personally. The contents of this site are not intended as advice for any purpose and are subject to change without notice. Mission Critical Email makes no warranties of any kind regarding the accuracy or completeness of any information on this site, and we make no representations regarding whether such information is up-to-date or applicable to any particular situation. All copyrights are reserved by Mr. Stone. Any portion of the material on this site may be used for personal or educational purposes provided appropriate attribution is given to Mr. Stone and this blog.