When you sell enterprise software, one of the uncomfortable questions is: what stops someone from copying the deployment to another server? License keys are trivially shared. IP based restrictions break when infrastructure changes. Phone home verification fails in air gapped environments. AgenticMail Enterprise uses a cryptographic domain lock that solves all of these problems.
The Core Mechanism
Every deployment is bound to a specific domain using a 256 bit key. During initial setup, the system generates a key pair. The private key stays on the deployment server. The public key gets published as a DNS TXT record on the customer’s domain.
At startup, the system reads the DNS TXT record for the configured domain, retrieves the public key, and verifies it against the locally stored private key. If the keys match, the deployment is authorized. If they don’t, or if the TXT record is missing, the system refuses to start.
This is conceptually similar to how DKIM works for email authentication, but applied to software licensing. The domain itself becomes the license.
Why Domain Binding Works
Domains are uniquely owned. Unlike IP addresses (which can be reassigned), server hostnames (which can be spoofed), or MAC addresses (which can be cloned), a domain’s DNS records can only be modified by someone with administrative access to that domain.
If someone copies the entire deployment to another server, they can duplicate every file, every configuration, every database. But they can’t duplicate the DNS TXT record on a domain they don’t control. The copied deployment will fail verification at startup.
If someone registers a different domain and tries to redirect, that also fails because the private key was generated for the original domain. A new domain would need its own key pair, and generating a valid private key without access to the deployment tooling isn’t possible.
The Verification Flow
The verification happens in three stages. First, the system reads the domain from its configuration and performs a DNS TXT lookup for a specific record name (prefixed to avoid collision with other TXT records). Second, it extracts the public key from the record and verifies the cryptographic signature against the local private key. Third, it generates a short lived session token that’s valid for a configurable period (default: 24 hours).
That session token means DNS isn’t queried on every request. After initial verification, the system runs normally for the token’s lifetime. When the token expires, verification runs again. This handles temporary DNS outages gracefully. A brief DNS blip during off hours won’t take down a production system.
Recovery CLI
Keys can be lost. Servers can fail. DNS records can be accidentally deleted. The recovery CLI handles these scenarios without requiring a support ticket.
If the local private key is corrupted or lost, the administrator runs the recovery tool, which generates a new key pair. They update the DNS TXT record with the new public key, and verification resumes. The recovery process requires proof of domain ownership (the ability to set DNS records) and proof of deployment ownership (access to the server’s filesystem and the deployment’s master password).
If the DNS record is accidentally removed, the system continues operating on its cached session token until expiration. This gives the administrator time to restore the record without any downtime. If the token expires before the record is restored, the system enters a grace period (configurable, default 72 hours) where it operates in a limited mode with warnings rather than shutting down entirely.
Offline After Verification
Once verified, the system works 100% offline. No phone home servers. No license validation APIs. No telemetry that could fail and take down the deployment. The DNS lookup at verification time is the only external network call the licensing system makes, and even that is resilient to temporary failures.
This matters enormously for enterprise customers. Many run AgenticMail in private networks, behind strict firewalls, or in environments with no internet access at all. After the initial domain verification (which can be performed during setup when network access is temporarily available), the system operates entirely self contained.
Why This Matters for Enterprise
Traditional license enforcement creates fragility. A license server goes down, and suddenly your customer’s production deployment stops working because it can’t phone home. Internet connectivity hiccups become software outages. Firewall changes break licensing. Every one of these scenarios erodes customer trust.
Domain lock eliminates the fragility while maintaining protection. The verification is cryptographically strong. The offline operation is genuinely offline. The recovery path exists for every failure scenario. And the whole mechanism is transparent; customers can inspect exactly what’s happening because it’s just DNS records and key pairs.
No external dependencies. No single points of failure. No trust me, it’ll work. Just math and DNS.