Sovereign Seal Documentation � DNS Identity Protocol

What is Sovereign Seal?

Traditional email authentication answers several important questions: where mail is authorised to originate, whether a message has a valid cryptographic signature, and what policy should be applied. Sovereign Seal introduces another layer: a discoverable domain identity.

SPF / MX

Establishes mail infrastructure and authorised sending paths.

DKIM

Provides cryptographic message signing and domain alignment.

DMARC

Defines domain-level policy and reporting behaviour for authenticated mail.

Sovereign Seal

Adds a machine-readable identity signal that compatible systems can discover and surface.

How it works

The basic model is deliberately simple: publish the identity record, allow compatible infrastructure to discover it, retrieve the public key and associate the result with the domain identity.

DOMAIN

?

DNS

?

SEAL1

?

PUBLIC KEY

?

SOVEREIGN SEAL

?

EMAIL CLIENT

DNS is the discovery layer. The public key is published through DNS. The corresponding private key remains under the control of the domain owner or signing system.

DNS Setup

To publish a Sovereign Seal identity, create a TXT record under the _seal label of the domain.

DNS RECORD

Host / Name:
_seal

Type:
TXT

Value:
v=SEAL1; l=https://authorize.email/assets/logo.png; k=YOUR_PUBLIC_KEY

FIELD	VALUE	PURPOSE
Type	`TXT`	DNS publication mechanism.
Host	`_seal`	Discovery location for the domain's Sovereign Seal identity record.
v	`SEAL1`	Identifies the Sovereign Seal record version.
l	Identity resource URL	Declared visual or identity resource.
k	Public key	Public verification material.

SEAL1 Record Format

The current Sovereign Seal identity record uses a semicolon-separated parameter structure.

SEAL1

v=SEAL1;
l=https://authorize.email/assets/logo.png;
k=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A...

Example

_seal.example.com TXT

"v=SEAL1; l=https://authorize.email/assets/logo.png; k=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A..."

Keep the public key public. The DNS record is intentionally public. It must never contain private signing material.

Key Architecture

Sovereign Seal uses asymmetric cryptography: the verification key can be published while the corresponding signing key remains private.

DNS PUBLIC KEY


                MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A...

Safe to publish. Used by verification systems.

?

SIGNING SYSTEM PRIVATE KEY


                ***********************

Never publish. Keep under operator control.

NEVER PUBLISH YOUR PRIVATE KEY A private key should never be placed in DNS, HTML, JavaScript, email headers, public repositories or other publicly accessible locations.

Key Generation

Generate the signing keypair on infrastructure under your control. The exact algorithm and encoding should match the implementation supported by your Sovereign Seal verifier.

EXAMPLE � OPENSSL RSA KEYPAIR

# Generate private key
openssl genrsa -out sovereign-seal-private.pem 2048

# Extract public key
openssl rsa \
  -in sovereign-seal-private.pem \
  -pubout \
  -out sovereign-seal-public.pem

The DNS record receives public material only. Keep sovereign-seal-private.pem outside the web root and protect it with appropriate filesystem and operational controls.

Key Rotation

Keys should be replaceable without destroying the underlying domain identity. Plan rotation before production deployment.

01

Generate a new keypair

Create the replacement signing and verification keys.

02

Publish the new public key

Update the Sovereign Seal DNS identity record with the new public verification key.

03

Transition signing

Move the signing system to the new private key.

04

Retire the previous key

Remove obsolete public material after the applicable DNS caching period and operational transition window.

Authorize.email

Authorize.email acts as the identity discovery and verification layer in the Sovereign Seal architecture. Compatible systems can inspect a sender domain, discover its Sovereign Seal DNS record and associate the resulting identity with the sender.

SENDER

?

DOMAIN

?

_seal TXT

?

AUTHORIZE.EMAIL

?

IDENTITY

Identity can be surfaced separately from message content. The purpose of the layer is to provide a consistent, machine-readable domain identity signal that compatible infrastructure can understand.

Roundcube Integration

The Authorize.email Roundcube integration can inspect the sender domain of an incoming message, discover the Sovereign Seal record and present the resulting identity information inside the mailbox interface.

EMAIL

?

SENDER DOMAIN

?

DNS

?

SOVEREIGN SEAL

?

ROUNDcube

Example mailbox result

Sender:
Example Company <hello@example.com>

Sovereign Seal:
VERIFIED

Domain:
example.com

Identity:
Declared

Public Key:
Discovered

Visual Identity:
Available

Website Badge

A verified domain can expose a Sovereign Seal badge linking back to the verification service.

HTML

<a href="https://sovereignseal.co.uk/verify?target=yourdomain.co.uk"
   target="_blank"
   rel="noopener">

    <img
        src="https://sovereignseal.co.uk/badge.php?id=YOUR_SEAL_ID"
        alt="Sovereign Seal Verified"
        style="width:170px;height:auto;"
    >

</a>

Always link the badge back to verification. The badge should provide a path for a visitor to independently inspect the domain's current verification result.

Verification

A compatible verifier can perform the following discovery sequence.

01

Extract the sender domain

Determine the domain associated with the sender identity being evaluated.

02

Query DNS

Resolve the domain's _seal TXT record.

03

Parse SEAL1

Validate the protocol version and supported parameters.

04

Retrieve public verification material

Obtain and validate the public key associated with the record.

05

Produce verification result

Return a machine-readable and human-readable identity status.

Verification API

Sovereign Seal verification can be exposed through a JSON endpoint for applications, email clients and infrastructure services.

REQUEST

GET /api/verify?target=example.com

EXAMPLE RESPONSE

{
    "domain": "example.com",
    "seal": {
        "version": "SEAL1",
        "verified": true,
        "identity": "https://authorize.email/assets/logo.png",
        "public_key": "MIIBIjANBgkqhkiG9w0BAQEFA..."
    },
    "mail": {
        "mx": true,
        "spf": true,
        "dkim": true,
        "dmarc": true
    },
    "status": "VERIFIED"
}

API consumers should treat verification as current state. DNS records and identity resources can change. Applications should not assume a previous result remains valid indefinitely.

Security Considerations

Protect private keys

Private signing material must remain outside public DNS and publicly accessible application assets.

Respect DNS caching

DNS answers may be cached. Plan key changes around the TTL and deployment window.

Do not confuse identity with message authenticity

A domain identity signal should complement, not replace, established email authentication controls.

Support key lifecycle management

Production systems should have a defined process for generation, rotation, revocation and recovery.

PROTOCOL BOUNDARY Sovereign Seal is an identity layer. It should be evaluated alongside SPF, DKIM, DMARC, TLS and the security controls of the underlying mail infrastructure.

Frequently Asked Questions

Does Sovereign Seal replace SPF?

No. SPF addresses authorised sending infrastructure. Sovereign Seal provides an additional identity signal.

Does it replace DKIM?

No. DKIM provides cryptographic message signing. Sovereign Seal should be treated as complementary.

Where is the private key stored?

The private key remains under the control of the domain owner or signing service. It should never be published through DNS.

What does DNS publish?

DNS publishes the Sovereign Seal identity record and its public verification material.

Can an email client use Sovereign Seal?

Yes. A compatible client or plugin can resolve the sender domain's identity record and surface the resulting status to the user.

Can websites use Sovereign Seal?

Yes. A website can display a verification badge that links visitors back to the Sovereign Seal verification service.

What is SEAL1?

SEAL1 is the version identifier used by the current Sovereign Seal identity record format documented here.

SOVEREIGN SEAL Domain ? DNS ? Identity ? Public Key ? Verification ? Compatible Infrastructure

DNS-backed identity.