By default, other homeservers will expect to be able to reach yours via
server_name, on port 8448. For example, if you set your
example.com (so that your user names look like
other servers will try to connect to yours at
Delegation is a Matrix feature allowing a homeserver admin to retain a
example.com so that user IDs, room aliases, etc continue
to look like
*:example.com, whilst having federation traffic routed
to a different server and/or port (e.g.
To use this method, you need to be able to alter the
server_name 's https server to serve the
URL. Having an active server (with a valid TLS certificate) serving your
server_name domain is out of the scope of this documentation.
return a JSON structure containing the key
m.server like so:
In our example, this would mean that URL
Note, specifying a port is optional. If no port is specified, then it defaults to 8448.
With .well-known delegation, federating servers will check for a valid TLS
certificate for the delegated hostname (in our example:
It is also possible to do delegation using a SRV DNS record. However, that is
considered an advanced topic since it's a bit complex to set up, and
delegation is already enough in most cases.
However, if you really need it, you can find some documentation on how such a record should look like and how Synapse will use it in the Matrix specification.
If your homeserver's APIs are accessible on the default federation port (8448)
and the domain your
server_name points to, you do not need any delegation.
For instance, if you registered
example.com and pointed its DNS A record at a
fresh server, you could install Synapse on that host, giving it a
example.com, and once a reverse proxy has been set up to proxy all requests
sent to the port
8448 and serve TLS certificates for
wouldn't need any delegation set up.
However, if your homeserver's APIs aren't accessible on port 8448 and on the
server_name points to, you will need to let other servers know how to
find it using delegation.
We no longer actively recommend against using a reverse proxy. Many admins will find it easier to direct federation traffic to a reverse proxy and manage their own TLS certificates, and this is a supported configuration.
See reverse_proxy.md for information on setting up a reverse proxy.
This is no longer necessary. If you are using a reverse proxy for all of your
TLS traffic, then you can set
no_tls: True in the Synapse config.
In that case, the only reason Synapse needs the certificate is to populate a legacy
tls_fingerprints field in the federation API. This is ignored by Synapse 0.99.0
and later, and the only time pre-0.99 Synapses will check it is when attempting to
fetch the server keys - and generally this is delegated via
is running a modern version of Synapse.
No. There is nothing stopping you from using different certificates, particularly if you are using a reverse proxy.