A groupId on Maven Central is a namespace that the publisher has proven they control. For a reverse domain name, they add a DNS TXT record. For a code hosting account, they create a temporary public repository. It proves control of a domain or account, not that the code is safe.
What a namespace is
Sonatype's documentation calls the namespace the groupId, one of the three required coordinates for any component, alongside artifactId and version. Namespaces identify a top level project or organization uniquely across all publishers on Central. By convention it reverses a domain: a project at example.com publishes under com.example, and any groupId beginning with that prefix.
How verification works
| Namespace type | Example | Proof of ownership |
|---|---|---|
| Domain based | com.example | A DNS TXT record on the exact domain with the key Sonatype assigns |
| Code hosting | io.github.username | Automatic for GitHub sign in, otherwise a temporary public repository named with the verification key |
Details from the documentation worth knowing:
- The check looks at the exact domain. For com.example it checks example.com, not a subdomain or variation.
- The groupId should reverse the domain exactly, even when the domain has a hyphen. Hyphens are fine in groupIds.
- Supported code hosting services listed are GitHub, GitLab, Gitee and Bitbucket, each with an io dot service dot username pattern.
- After verification, the temporary repository can be deleted.
What it tells you when you read a dependency
A verified namespace gives you something real: the account that published com.example artifacts controls the example.com domain at the time of verification. That helps you tell the real project from a lookalike published under a different, personal namespace.
It does not tell you:
- That the code has been reviewed, since Central says it does not evaluate source code.
- That the domain is still controlled by the same people today.
- That a dependency's maintainers are the ones who published a given version.
For that last point, signatures and checksums help, and our post on whether a signed artifact is safe explains where they stop.
How to use this when choosing a library
- Look at the groupId and ask whether it matches the project's real domain or hosting account.
- Be careful with near matches in spelling, a different top level domain, or a personal github namespace for something that claims to be an official library.
- Compare the groupId in the project's own documentation with the one in your POM.
- Check the release history and how long the namespace has been in use.
- Scan the library like any other.
A control to add in your own build
Whatever the namespace rules are, your build can narrow its own trust. Gradle's repository content filters let you say which groups come from which repository, and Maven mirrors can route everything through a repository manager that you control. See Gradle exclusiveContent and one internal repository for Maven.
Safeguard dependency scanning and SBOMs record the groupId, artifactId and version of every component your build resolves, which makes lookalike names easier to spot in review. Free scan: gold.safeguard.sh/scan.
Quick check
Does a verified namespace mean the library is audited?
No. It shows control of a domain or hosting account. The documentation says Central does not evaluate the source code.
Can I use a hyphenated domain as a groupId?
Yes. The documentation says the groupId should reverse the domain exactly, and hyphens are acceptable.
Sources
Last reviewed: 19 October 2026.
