Input Plesk Apple Mail .mobileconfig and per-domain mail hostnames

[sawyernutsov]

Server operating system version

Ubuntu 22.04

Plesk version and microupdate number

Obsidian 18.0.80.8

Hi everyone,

I'm running Plesk Obsidian on a multi-domain hosting server and have been trying to get Plesk's Apple Mail .mobileconfig profiles to use the conventional per-domain mail hostname:

domain-a.example → mail.domain-a.example
domain-b.example → mail.domain-b.example

rather than the bare domain or one common mail hostname shared across every domain.

After quite a bit of digging, I found that this can be achieved by adding the following to panel.ini:

[mail]
clientConfig.incomingServer="mail.<domain>"
clientConfig.outgoingServer="mail.<domain>"

The panel.ini file is typically located at:

/usr/local/psa/admin/conf/panel.ini

If the [mail] section already exists, just add the two clientConfig.* lines beneath it.

The interesting part

What confused me initially is that this isn't surfaced in the Plesk UI, and I couldn't initially find an obvious way to tell Plesk:

"For every domain, use mail.<domain> for the generated Apple Mail profile."

I initially investigated the Mail Autodiscover settings and found the following CLI option:

plesk bin mailserver --set-mail-autodiscover-domain-name <hostname> -reconfigure-dns true

This appeared to solve the Apple .mobileconfig problem because the generated profile started using the specified mail hostname.

However, this is a completely different mechanism.

Because it is a server-wide custom autodiscover hostname, using it with:

-reconfigure-dns true

changed the SRV records of unrelated domains on the same Plesk server so that they pointed to the same custom hostname.

For example, instead of:

mail.customer-a.example

and

mail.customer-b.example

they could end up pointing to:

mail.example-a.test

Removing the custom autodiscover hostname afterwards did not automatically restore those existing SRV records.

This is quite an important distinction on a multi-domain/multi-tenant Plesk server.

The solution

After restoring the affected DNS zones to their Plesk defaults and using:

[mail]
clientConfig.incomingServer="mail.<domain>"
clientConfig.outgoingServer="mail.<domain>"

Plesk behaved exactly as I originally wanted.

Existing domains generated Apple Mail profiles using their own:

mail.<domain>

hostname for both incoming and outgoing mail.

I then performed the really useful test: I created a completely new domain.

I didn't make any domain-specific changes.

Plesk automatically generated the new domain's .mobileconfig using:

mail.<new-domain>

for both IMAP and SMTP.

So the per-domain configuration works correctly.

What I think is confusing

There appear to be two very different Plesk mechanisms:

Per-domain client configuration:

[mail]
clientConfig.incomingServer="mail.<domain>"
clientConfig.outgoingServer="mail.<domain>"

This gives:

domain-a → mail.domain-a
domain-b → mail.domain-b
domain-c → mail.domain-c

Server-wide custom autodiscover hostname:

plesk bin mailserver --set-mail-autodiscover-domain-name <hostname> -reconfigure-dns true

This gives all domains the same autodiscover hostname and can modify existing DNS SRV records.

The distinction wasn't obvious to me when I was trying to solve the Apple Mail .mobileconfig issue.

A couple of notes
The <domain> placeholder is substituted per-domain by Plesk.
mail.<domain> obviously needs to resolve correctly.
The hostname needs an appropriate TLS certificate.
A wildcard certificate such as *.example.com covers mail.example.com.
Existing domains may need their DNS zone reset to apply the configuration, whereas newly created domains appear to pick it up automatically.
My question for Plesk

Is clientConfig.incomingServer="mail.<domain>" / clientConfig.outgoingServer="mail.<domain>" the intended supported solution for a multi-domain Plesk server where every domain should use its own mail.<domain> hostname?

If so, I think this deserves much more prominent documentation.

In particular, I think there should be a very clear distinction between the per-domain clientConfig.* settings and the server-wide custom Mail Autodiscover hostname.

The latter can have significant consequences when used with -reconfigure-dns true, so it would be useful for Plesk to make that distinction explicit.

I spent quite a while investigating the Apple .mobileconfig generation and even went down the wrong path before finding the panel.ini solution.

Hopefully this saves someone else the same headache.

 

[sawyernutsov]

UPDATE: I have now confirmed the behaviour with a second Plesk server

I have now been able to perform a clean A/B test, which makes the situation much clearer.

I have a second Plesk server, running:

Plesk Obsidian 18.0.80.9
Ubuntu 24.04 x86_64

Unlike my first server, this second server has no panel.ini:

/usr/local/psa/admin/conf/panel.ini

does not exist. It only has:

/usr/local/psa/admin/conf/panel.ini.sample

I generated an Apple Mail .mobileconfig profile for a test domain on this completely standard Plesk installation.

The generated profile contains:

IncomingMailServerHostName
example.com

OutgoingMailServerHostName
example.com

So stock Plesk generates:

IMAP: example.com:993
SMTP: example.com:465

It does not generate:

mail.example.com

I then compared this with my first Plesk server.

On that server I have:

[mail]
clientConfig.incomingServer="mail.<domain>"
clientConfig.outgoingServer="mail.<domain>"

With that configuration in place, the generated Apple Mail profiles use:

IMAP: mail.<domain>:993
SMTP: mail.<domain>:465

I also created a completely new domain on that server after adding the configuration, without making any domain-specific changes.

The new domain's .mobileconfig automatically used:

mail.<new-domain>

for both incoming and outgoing mail.

So we now have a clean A/B test:

Stock Plesk
domain.example
↓
Apple .mobileconfig
↓
domain.example

versus:

Plesk + panel.ini

[mail]
clientConfig.incomingServer="mail.<domain>"
clientConfig.outgoingServer="mail.<domain>"

↓

Apple .mobileconfig
↓
mail.domain.example

This confirms that the

clientConfig.*

settings are what change the Apple Mail profile from the bare domain to the per-domain

mail.<domain>

hostname.

This also clarifies my original confusion.

I initially tried to achieve this using:

plesk bin mailserver --set-mail-autodiscover-domain-name <hostname> -reconfigure-dns true

That did make the Apple profile use the specified hostname, but it is a completely different mechanism.

Because that setting is server-wide, using

-reconfigure-dns true

changed the SRV records of unrelated domains to use the same hostname.

That is not what I was trying to achieve.

What I actually needed was:

domain-a.example → mail.domain-a.example
domain-b.example → mail.domain-b.example
domain-c.example → mail.domain-c.example

The

clientConfig.*

configuration achieves exactly that.

Therefore, my question to Plesk is now more specific:

Is:

[mail]
clientConfig.incomingServer="mail.<domain>"
clientConfig.outgoingServer="mail.<domain>"

the officially intended/supported way to configure Apple Mail .mobileconfig profiles to use a per-domain

mail.<domain>

hostname?

If it is, I think this deserves much more prominent documentation.

In particular, the distinction between:

1. Per-domain client configuration

clientConfig.incomingServer="mail.<domain>"
clientConfig.outgoingServer="mail.<domain>"

and:

2. Server-wide custom Mail Autodiscover hostname

plesk bin mailserver --set-mail-autodiscover-domain-name <hostname>

is quite important.

An administrator trying to make Apple Mail use

mail.<domain>

could quite easily find the second option first, which has very different consequences on a multi-domain hosting server.

The second server test also confirms that stock Plesk does not use mail.<domain> by default. It uses the bare domain in the generated Apple Mail profile.

So the

panel.ini

setting appears to be the missing piece for anyone wanting conventional per-domain mail hostnames.

I'd be particularly interested in confirmation from Plesk staff that this is the recommended configuration.