Nobody should have to look up an IMAP port. The SRV records, well-known URLs and redirects that let Apple Mail, Thunderbird and a phone set themselves up from an email address alone, and the two places it still asks you to type something.
There is a small, deeply unglamorous test that tells you whether an email provider respects your time. Add the account to Apple Mail, or Thunderbird, or the mail app on an Android phone. Type the address, type the password. Does it work?
If it does, someone published the right records and served the right endpoints. If it does not, you are now looking up IMAP port numbers, and so is every colleague you migrate after you. This post is about the machinery that makes the first version happen, because it is one of those features nobody notices when it works and everybody feels when it does not.
When you type you@yourcompany.eu into a mail app, the app does not yet know a single thing about your provider. It knows a domain. So it goes looking, in a fixed order defined by internet standards rather than by any one vendor, and it asks your domain a series of questions.
It looks for SRV records, small DNS entries that name the server and port for a given service. There is one for modern JMAP, and there are older ones for IMAP, for outgoing mail, for calendars and for contacts. It looks for a well-known URL on your domain, a fixed path that returns a machine-readable description of where the real service lives. And depending on the client, it looks for a configuration document at a conventional hostname on your domain, the mechanism Thunderbird and Outlook each have their own version of.
Any one of those answering correctly is enough. The catch is that they all have to be answered by your domain, not by ours, because your domain is what the user typed.
| The client asks | Answered by | Set up how |
|---|---|---|
| SRV records for mail, calendars and contacts | DNS on your domain | Records in the set we generate |
| A well-known URL over HTTPS | Whatever hosts your domain | A redirect on to the mail server |
| A configuration document at a conventional hostname | DNS on your domain | Records in the set we generate |
This is the detail that makes autodiscovery harder than it looks. The domain in an email address is usually also a company website, and a website is not a mail server. When a client asks yourcompany.eu where its calendars live, the thing that receives that question is whatever is hosting your homepage.
There are two clean ways out, and we use both.
The first is DNS, which does not care what your website is. The SRV records that point clients at the right hosts and ports ship inside the record set we generate for your domain, along with the hostnames that Thunderbird-style and Outlook-style clients look for. You publish the zone once when you set the domain up, and discovery is handled from then on. No web server involved.
The second is a redirect, for the well-known URLs that have to be answered over HTTPS by the domain itself. Those are one-line redirects that send the client on to the mail server, which serves the real document. We run exactly that on email.eu: ask our marketing site where our calendars are, and it bounces you to the mail server, which answers properly. It is two hops and it takes milliseconds, and it is the difference between a phone that syncs and a phone that says "cannot verify account".
The modern answer to all of this is JMAP, which is what our webmail speaks and what the mail server was built for. JMAP has clean discovery baked into the standard.
The modern answer is not what is installed on your team's phones. So the discovery records we publish cover the old world as well: IMAP and submission for anything from the last twenty years, CalDAV and CardDAV for calendars and contacts, all of it advertised alongside the new one. A provider that only supports the future is asking every one of your colleagues to change their habits on the day they change providers, which is the day they have the least patience for it.
This is the same reasoning behind supporting every standard protocol at all. Autodiscovery is that principle applied to the first sixty seconds.
Two honest limits.
Some clients, on some platforms, will find the server perfectly and then ask for a password anyway rather than opening a browser to sign you in. That is a client-side choice about how it authenticates, not something a DNS record can fix. If the client is old enough to want a plain password, it wants an app password, which takes about ten seconds to create in your account settings and is safer than handing it your real one.
And Outlook is its own weather system. Its discovery behaviour has changed repeatedly across versions and across the desktop, web and mobile builds, so "it works in Outlook" is a claim with a version number attached. We publish what the standards say to publish, which is the part we control, and it works with the current builds we test against.
We would rather say that plainly than promise a universal experience and let you discover the exception on the morning you switch.
Migrations do not fail on the big decisions. They fail on the twentieth person who could not get their phone working and quietly kept using the old account, which means the old account cannot be turned off, which means the migration is not finished six months later.
Automatic configuration is what stops that happening at scale. Every person you onboard types an address and a password once. Nobody opens a documentation page. Nobody asks IT for a port number.
If you want to see it work with your own client before committing to anything, that is a fair test to run during a trial. The weekend migration guide sets up exactly that: everything working and testable while your old provider is still delivering your mail.