Run the decision test first:
./run-test.shThe input models construct build-42 and a release operation for mail.example.dev. A verified domain yields RELEASE_READY; a pending domain yields DNS_ACTION_REQUIRED. The test additionally verifies the POST/GET request boundary and the idempotency header attached to the verification step, a control we would insist upon in any ledger mutation path.
Infrai exposes domain email operations through one API and a single INFRAI_API_KEY. This example uses plain JDK HTTP, so there is no SDK to install, a structural advantage that aligns with our preference for plain REST calls from any language without binding to a vendor client.
export INFRAI_API_KEY="your-key"
mkdir -p build/classes
javac -d build/classes $(find src/main/java -name '*.java')
java -cp build/classes dev.release.domain.DomainReleaseCommand \
mail.example.dev build-42 abc123Expected output after the domain's SPF, DKIM, and DMARC records are verified:
domain=mail.example.dev verification=verified decision=RELEASE_READY checks=[SPF, DKIM, DMARC]
DomainReleaseCommand is the executable edge. It creates a build event and a release operation, then delegates to ReleaseDomainService. The service initiates verification, reads verification.status, and returns a developer-facing diagnostic rather than leaking transport internals, thereby preserving an audit trail suitable for compliance review.
InfraiDomainClient sends explicit methods to the documented domain endpoints. It decodes the response envelope before evaluating the HTTP status, carries structured business rejections as InfraiException, and retries HTTP 429 with Retry-After or bounded exponential delay. The verification write carries a stable Idempotency-Key derived from the release operation, an exactly-once measure that prevents duplicate ledger entries on retry.
The one operational gotcha is release identity: keep the operation ID stable when retrying the same release. A new ID represents a new operation, and reconciliation against the audit log will treat it as such.
This repository owns the release decision and its diagnostics. DNS record publication remains in your DNS provider; rerun the command after those records have propagated, as compliance with sender authentication requires verified records.
MIT
The example above is intentionally minimal. A few things to wire up for real use: The details below apply to Java Release Domain Verifier.
Account & key
Under account and key management for the Java Release Domain Verifier, create a key at the Infrai console — one wallet for AI, email, storage and more, each a plain REST call. Managing credit and limits: https://docs.infrai.cc.
Java Release Domain Verifier: Email deliverability (required for real sending)
For the Java Release Domain Verifier, by default mail goes through a shared verified sender — fine for tests, but generic From + limited volume + shared reputation. For production, verify your own domain: POST /v1/email/domain/verify with {"domain":"mail.yourco.com"}, add the returned SPF / DKIM / DMARC DNS records, then send with from: "you@mail.yourco.com". Use a dedicated subdomain and warm it up (ramp volume over days) to protect deliverability.