Port 5269 – XMPP Server

TCP

Port 5269 is the XMPP server-to-server (S2S) federation port. When a user on domain-a.com messages [email protected], domain-a's XMPP server connects to domain-b on port 5269. S2S connections use TLS and SASL EXTERNAL (mutual certificate auth) or dialback for identity verification.

Port Number

5269

Protocol

TCP

Service

XMPP Server-to-Server

Range

IANA Registered (1024–49151)

Description

XMPP server federation on port 5269 enables cross-domain messaging – the equivalent of SMTP relay but for instant messaging. When a message is destined for a remote domain, the local server performs DNS SRV lookup (_xmpp-server._tcp.domain) to find the target server and connects on port 5269. S2S connections should require TLS with valid certificates. Without certificate verification, an attacker who controls DNS can impersonate any domain. Modern XMPP servers (Prosody, ejabberd) support DANE/TLSA for certificate pinning via DNS. If you run a private XMPP server without federation needs, block port 5269 entirely to reduce attack surface.

Security risks

1Federation impersonation: without proper certificate verification (dialback + TLS), a malicious server can claim to be any domain and send messages appearing to come from that domain's users
2Dialback weakness: XMPP's original server authentication (dialback, XEP-0220) verifies via DNS only – DNS spoofing allows server impersonation without TLS
3Spam via federation: any internet XMPP server can send messages to your users if federation is open. Spambots create disposable XMPP servers and blast messages before being blocked
4Resource exhaustion: remote servers can open many s2s connections simultaneously. Without connection limits, a malicious server can DoS your XMPP server by exhausting file descriptors
5Information disclosure via presence probes: federated servers can probe for user presence (online/offline status) and JID existence without the user's consent

Firewall guidance

If federation is not needed (private company chat): block port 5269 entirely. If federation is needed: enforce TLS (s2s_require_encryption = true), require valid certificates (s2s_secure_auth = true in Prosody), implement server blocklist/allowlist for known federation partners. Rate-limit s2s connections per remote domain.

Diagnosis commands

Test s2s TLS to a federated server

shell

openssl s_client -connect remote-server:5269 -starttls xmpp -xmpphost yourdomain.com

Prosody: list active server-to-server connections

shell

prosodyctl s2s

ejabberd: count incoming federation connections

shell

ejabberdctl incoming_s2s_number

Check DNS SRV record for XMPP federation (how other servers find you)

shell

dig SRV _xmpp-server._tcp.domain.com

Usage examples

Port 5269 – XMPP Server

shell

dig _xmpp-server._tcp.example.com SRV
prosodyctl s2s
ejabberdctl incoming-s2s-number

Common services on this port

ejabberd (federation)Prosody (federation)Openfire (federation)Tigase

Related ports

5269

XMPP server-to-server (this port)

5222

XMPP client-to-server

5270

XMPP s2s TLS (some deployments)

History

XMPP federation (s2s on port 5269) was inspired by email's federated model – any server can talk to any other server, enabling user@serverA to message user@serverB. This was revolutionary in 1999 when every IM protocol (AIM, ICQ, MSN) was proprietary and siloed. Google Talk's federation (2005-2014) was the high point. Most large deployments (WhatsApp, Zoom) abandoned federation for control. The protocol remains relevant for decentralized/privacy-focused communities.

FAQ

Should I enable XMPP federation for my organization?

Usually no for enterprise deployments. Federation adds: spam from external servers, complexity of certificate management for s2s TLS, compliance risks (messages leaving your server to unknown destinations), and a larger attack surface. Enable only if: you need to communicate with specific partner organizations via XMPP, or you're running a public community server where openness is a feature.

Specification

RFC 6120 – Port 5269 specification →