How Maven Central verifies a groupId, and what to check yourself

Maven Central expects a groupId to reverse a domain name the publisher owns or controls, or to use a code hosting form such as io.github.username. Ownership is proven through a DNS record or a temporary repository. A matching groupId is a useful clue, but you should still compare it with the project's real home.

The naming rule

Sonatype's guidance on coordinates says the groupId should reverse the domain name exactly. Hyphens are allowed. Subgroups under an approved groupId do not need new tickets.

You must own or control the domain. If you do not have a public domain, you can use a personal groupId tied to a supported hosting account, with the form io.github.myusername.

How ownership is checked

The page describes two methods, though it does not use the phrase namespace verification.

• Domain based. The Central team asks for proof of ownership by having you create a TXT record with your domain registrar's DNS service.
• Hosting account based. You create a temporary public repository named after your ticket number under your account. Once the groupId is registered, you can delete it.

Both methods show control of something at the time of the check. They do not show that the control lasts.

Reading a groupId as a consumer

When you add a Java dependency, take thirty seconds with the groupId.

1. Does it map to a domain you can recognize? com.example.tools should lead to example.com. If you cannot find a link, find out why.
2. Is it a hosting account form? An io.github name tells you the publisher controls that account. Check that the repository there is the project you intend to use.
3. Is it close to a well known groupId? Lookalike groupIds can exist, for example a changed top level domain or a swapped word. Compare to the project's documentation.
4. Does the artifact belong? An artifactId under a groupId should fit what the organization does.

Risks that remain

• Expired domains. If a domain lapses and someone else buys it, they may be able to claim control of that namespace in the future. Look into publisher changes if a library has not seen releases for a long time and then suddenly does.
• Account takeover. A hosting account based groupId depends on that account's security.
• Shared repositories. Declaring the right groupId does not prevent a bad release from a legitimate publisher whose credentials were stolen.

Controls on your side

1. Pin exact versions and verify checksums or signatures in your build.
2. Prefer a single approved repository and avoid adding extra repositories for convenience. The requirements page itself discourages repositories sections in published POMs.
3. Record the groupIds you trust, and flag anything new in a pull request for review.
4. Review dependency changes, not only code changes.

Safeguard scans Maven and Gradle dependencies and applies policy gates, which makes the "flag anything new" step part of your pipeline.

Quick check

Sources

• Maven Central coordinates requirements
• Maven Central publishing requirements

Last reviewed: 19 October 2026.