skip to content

How does Sonatype namespace (groupId) verification work for Maven Central, and what must you do before you can publish under a given group?

level: middleimportance: must knowfreq 55%

answer

  1. group = namespace you must own
  2. domain group -> DNS TXT token
  3. io.github.user -> code-host proof
  4. sub-namespaces inherited
  5. one-time, permanent, anti-squatting

basics

~20 s

Your groupId is a namespace you must prove you control. For a domain-based group you add a TXT DNS record; for a code-host group (io.github.user) you verify via the matching account. Central won't accept artifacts until the namespace is verified.

solid answer

~40 s

Maven Central ties every `groupId` to a **namespace** you must own. Before publishing, you register the namespace in the Central Portal and prove control: for a reverse-domain group like `com.example`, the Portal gives you a verification key to publish as a **DNS TXT record** on `example.com`; for code-host namespaces like `io.github.<user>` or `io.gitlab.<user>` you verify by creating a matching public repository (or the Portal checks account ownership). Once verified, the namespace (and its sub-namespaces — `com.example.foo` is covered by `com.example`) is permanently associated with your account, and only you can stage/release under it. This prevents anyone from squatting another organization's coordinates. Verification is a one-time, per-namespace step independent of any individual artifact or version.

go deeper

for a junior

Know that the groupId must be owned/verified and that you can't publish to Central without it.

for a middle

Explain both verification paths (DNS TXT for domains, code-host for io.github.*) and that sub-namespaces inherit verification.

for a senior

Discuss choosing the namespace early, the anti-squatting rationale, and migration cost of changing groups.

for a principal

Address org-wide namespace governance: who owns the domain/DNS, delegating sub-namespaces to teams, and provenance policy.

## What a namespace is In Maven coordinates `group:artifact:version`, the **group** is a reverse-DNS-style identifier (e.g. `com.fasterxml.jackson.core`). Maven Central treats the group as a **namespace** that must map to something you provably control, so that `com.google.*` can only be published by Google, etc. This is the anti-squatting / provenance backbone of Central. ## How verification proves ownership Verification depends on the namespace shape: - **Reverse domain** (`com.example`, `org.acme`): the Central Portal generates a unique verification token. You add it as a **DNS TXT record** on the corresponding domain (`example.com`). The Portal queries DNS and, on a match, marks the namespace verified. This proves you control the domain. - **Code-host namespaces** (`io.github.<username>`, `io.gitlab.<username>`, `io.bitbucket.<username>`): you prove ownership of the account, typically by creating a public repository whose name matches the verification token (or the Portal checks the account). This lets developers without a domain still publish. ## Scope and inheritance A verified namespace **covers its sub-namespaces**: verifying `com.example` lets you publish `com.example`, `com.example.tools`, `com.example.tools.cli`, and so on — you don't verify each artifact or each child group separately. Verification is **per namespace, one-time**, and survives across all future versions. ## Where it sits in the workflow ```text 1. Register namespace in Central Portal 2. Portal issues verification token 3a. Domain group -> add DNS TXT record -> Portal verifies 3b. io.github.user -> create matching repo -> Portal verifies 4. Namespace marked VERIFIED (permanent) 5. Now staging/publishing under that group is accepted ``` Until the namespace is verified, any attempt to deploy under that group is rejected regardless of how perfect the bundle is. The Gradle build itself doesn't perform verification — it only uploads the bundle; verification is account/Portal state. ## Practical tip If you don't own a domain, `io.github.<your-github-username>` is the path of least resistance — it requires only a GitHub account and a token-named repo, no DNS. Choosing your group early matters because changing it later means re-verifying a new namespace and breaking consumer coordinates.

  • You verified com.example — do you need to separately verify com.example.tools?
    No. A verified namespace covers all of its sub-namespaces, so com.example.tools (and deeper) is automatically allowed.
  • A developer has no domain. What group should they pick and how do they verify it?
    Use io.github.<their-github-username>; verification is done through the matching code-host account/repo rather than DNS, so no domain is needed.
  • Does the Gradle build perform the namespace verification?
    No. Verification is account/Portal state established once via DNS or code-host proof; the build only uploads artifacts and will be rejected if the namespace isn't already verified.

saying these in an interview costs you the question

  • Saying you verify per-artifact or per-version rather than per-namespace.
  • Claiming a DNS record is needed for io.github.* groups (it's account-based).
  • Thinking the Gradle plugin handles ownership verification.

context

resolving links…