How to Set Up an SRV Record so Players Join Without a Port

An SRV record lets a player type play.example.com and connect, instead of memorizing an IP with :25565 stuck on the end. It's a DNS record that tells the game which host and port to actually use, so you can hide a non-default port behind a clean address. That's the whole point of it: a short address is easier to share, and it makes for a tidier listing entry, since the thing players copy from your page is short and reads cleanly.

This works fully on Java Edition. Bedrock has some real caveats, and I'll get to those. You'll need a copy of Minecraft on hand to test the connection at the end. Once the address is clean, the whole act of joining a Minecraft server gets simpler for everyone who finds you.

What an SRV record actually does

Without an SRV record, your address is just a hostname that resolves through an A record to an IP, and the client tries the edition's default port — 25565 for Java, 19132 for Bedrock — unless the player appends :port themselves. That's fine if you're on the default port. The trouble starts when you're not.

Plenty of setups don't run on the default. If you've got several servers on one machine, or you're on a shared host that hands out ports, your server might be bound to something like 25571. Without SRV, every player has to type that port, and most won't get it right or won't bother. The SRV record hides it.

The two records work together rather than one replacing the other. An A record maps a hostname to the server's IP. The SRV record points players' clients at that hostname plus the correct port. Java Edition does the _minecraft._tcp lookup automatically the moment someone connects, with no setting to toggle — that's what makes the port disappear from the address. Worth being clear on the boundary, though: SRV only controls how the host and port get resolved. It doesn't proxy traffic or touch anything inside the server — that's all handled elsewhere.

Before you start: the A record comes first

An SRV record's target has to point at a hostname that resolves to an IP, so you create that hostname first with an A record (or AAAA if you're on IPv6). The usual pattern is to make something like mc.example.com as an A record pointing to your server's public IP. That host becomes the SRV target.

There's a gotcha worth knowing up front. The SRV target should resolve through an A or AAAA record, not a CNAME, and you can't put a CNAME on the apex (naked) domain anyway. That's exactly why the subdomain-target pattern is the standard, reliable approach — mc.example.com is a plain A record, so it sidesteps the CNAME problem entirely.

The address players actually type — play.example.com, or the apex example.com — is the one the SRV record sits on. The target host (mc.example.com) is internal plumbing nobody types or sees. Before you touch DNS, grab two things: the server's public IP, and the exact port the server is bound to. Check the server config or your host panel for the port so you're working from the real number, not a guess.

Set up the Java SRV record step by step

Step 1 — create the A record target. Add an A record for mc.example.com pointing to the server's public IPv4. This is the host the SRV record will aim at.

Step 2 — create the SRV record. Registrar UIs split the fields differently, so go field by field:

• Service = _minecraft
• Protocol = _tcp
• Name / host = the subdomain players will type, like play (or @ for the apex)

Put together, that gives the full record name _minecraft._tcp.play.example.com.

Step 3 — fill priority, weight, port, and target. Priority and Weight can both be 1 (or 0 — they only matter when you list several records to balance between). Port is your actual server port. Target is mc.example.com, the A record from step 1.

Here's where panels diverge, so read the labels instead of copying a format blindly. Cloudflare and cPanel give you four separate boxes. Others, like Porkbun, want the value typed as one string — priority and weight, then the port, then the target — so you'd enter something like 1 1 25565 mc.example.com in a single field. Same data either way.

The one rule you can't get wrong: the Port in the SRV record has to exactly match the port your server is actually running on, and the Target has to be a host that resolves. A mismatch here is the most common reason the clean address connects to nothing. Once it's right, players type play.example.com with no port and Java works out the rest on its own.

Bedrock Edition: the caveats

Bedrock doesn't officially support SRV records the way Java does, so you can't lean on SRV alone to hide the port for Bedrock players. There's a partial workaround — a Bedrock-style record uses _minecraft._udp rather than _tcp, since Bedrock runs over UDP on 19132 — and some clients and launchers will honor it. But support is inconsistent across Bedrock platforms, so it's not something to depend on.

The practical move is to keep the server reachable on a port Bedrock players can enter by hand, and to show the address plus port on your listing so they can fill the separate Port field. Run the default 19132 wherever you can, and most Bedrock players connect without typing a port at all.

If you bridge Java and Bedrock together, set expectations accordingly. Java players get the clean SRV address; Bedrock players will likely still need to type the port. The join guide walks through Bedrock's separate address and port fields, which is the screen those players are working with.

Wait for propagation, then verify

DNS changes aren't instant. Caches around the world refresh over time — often within a few hours, but it can take 24 to 48 hours for everything to catch up. So if a test fails in the first few minutes, don't assume the record is wrong; it may just not have spread yet. A lower TTL on the records makes changes take effect faster, which is handy if you think you might tweak the port later.

When it's had time to settle, check it from the command line. On macOS or Linux:

dig SRV _minecraft._tcp.play.example.com +short

On Windows:

nslookup -type=SRV _minecraft._tcp.play.example.com

A correct answer returns the priority, weight, the port, and the target hostname. The real test, though, is in-game: add play.example.com with no port in the Java multiplayer screen and confirm the ping and player count show up. That proves the SRV record, the A record, and the port all line up.

If something's off, this short checklist covers most of it:

• No SRV answer at all — the record hasn't propagated yet, or it's named wrong. Check the _minecraft._tcp prefix and the subdomain.
• Resolves but won't connect — the port in the record is wrong, or the target host doesn't resolve.
• Connects only with the port typed — the client isn't reading SRV (that's Bedrock), or the record name doesn't match the address players are using.

Tie it back to your listing

Once the SRV record works, put the clean address — play.example.com, no port — on your listing. The thing players copy is now short and memorable, which makes it easier to share in a video, a post, or just word of mouth. A branded address also reads as more established than a raw IP and port, and that can be enough to nudge a first-time visitor into clicking join.

That feeds your ranking too. A memorable address is one players actually remember, so they come back and keep voting, which is what moves you up the live monthly board. If you want the details on how that count works, how server rankings work lays it out.

Last thing: keep the A record's IP and the SRV record's port current if you ever migrate hosts or change ports. A stale record breaks the clean address, and because the old IP and port might still work for you, you may not notice the branded address is dead until a player tells you.

FAQ

What TTL should I set on the SRV and A records?

A shorter TTL — say 300 seconds — means changes propagate faster, so it's worth lowering before a planned port change or host migration so the new value spreads quickly. Once everything's stable, you can raise it again to ease the load on resolvers. The tradeoff is only ever speed of change versus query overhead, so for a record you rarely touch, the default your registrar suggests is fine.

Why does my address work with the port but not without it?

That means the client isn't picking up the SRV record. On Java, check that the record is named exactly _minecraft._tcp.<the subdomain players type>, that it's finished propagating, and that the Port in the record matches the server's real port. If it's Bedrock, that's expected — Bedrock doesn't reliably honor SRV records, so Bedrock players usually still need the port in the separate Port field.

My local test says no SRV record but I'm sure I added it — what now?

Your machine or router may be serving a cached answer, especially if you checked once before the record finished propagating. The quickest way around your own cache is to test from a phone on cellular data instead of your home network — a different resolver, no local cache to clear. If the phone sees the record and your computer doesn't, it's a stale cache on your end, not a problem with the record itself.