Domains

Part ofSet up Soveryne for your organisation

Soveryne uses the word "domain" for five different things. Each has its own purpose and its own way of being checked, and you may need some of them but not others. This page explains each one and what you need to do for it.

At a glance

Kind of domain	What it is for	Product	How it is checked	What you do
Sign-in email domains	Which people may sign in, and the role they get	All	Your identity provider confirms each person's email address	Give your email domains to Soveryne or your partner. See Single sign-on.
Workspace web address	Where each product opens in the browser	All	Set up by Soveryne	Nothing, unless you want your own domain (see below)
Receiving domains (BAIT calls them Sending domains)	The domains your staff receive email on. BAIT sends simulations only to addresses on these domains.	BAIT	A DNS TXT record that you publish	Publish one TXT record for each domain
Simulation sender domain	The domain BAIT simulations are sent from	BAIT	SPF and DKIM records	Agreed with your Soveryne contact
Scan scope	The domains, IP addresses and ranges ATLAS may examine for you	ATLAS	A DNS TXT record, another ownership proof, or a recorded attestation	Publish one TXT record for each domain, or provide another proof

Note

Start the DNS steps early. A new DNS record can take from a few minutes to an hour to become visible.

These are the email domains your people sign in with, for example example.com and example.nl. They decide who is let in and which role people get by default. They are not checked through DNS. Trust comes from your identity provider, which confirms each person's email address at sign-in.

Add every domain your staff use, including subsidiaries and aliases. Anyone on a domain that is not listed must be invited personally.

Public email services such as gmail.com can never be a sign-in domain.

You manage them in Command under Departments › Single sign-on (Allowed email domains).

Command also uses your organisation's email domain to deliver published policies to your staff in Counsel. Set it under Organisation › Customer email domain.

Workspace web address

Each product you use has its own web address. Soveryne, or your partner, gives you the addresses when your workspaces are created. You don't need to do anything in DNS for the standard addresses.

Using your own domain. If you want the products to open on your own domain, for example command.example.com, Soveryne gives you a DNS record to create for each product address. Each address gets its own certificate once its record points to Soveryne. Single sign-on keeps working without any change in your identity provider.

Receiving domains (BAIT)

BAIT sends a simulation only to an address on a domain you have proved you own. In BAIT these are listed under Settings › Sending domains, but they are the domains your staff receive email on.

To prove a domain:

In BAIT, open Settings › Sending domains, enter the domain your staff receive mail on, and choose Add domain.

BAIT shows the exact record to publish. It looks like this: `` TXT _bait-verify.example.com "bait-site-verification=<token shown in BAIT>" `` The record sits on its own name, so your existing SPF and DMARC records are never touched.

Publish the record with your DNS provider.

In BAIT, choose Check DNS. BAIT asks your domain's own name servers, so a new record is found as soon as they have it.

The domain then shows Verified. BAIT checks the domain again for every recipient when it sends.

If the record is not found, BAIT tells you: "TXT record … was not found at your domain's own nameservers. DNS changes can take up to an hour to publish." Wait, then choose Check DNS again.

See BAIT setup for the full procedure.

Simulation sender domain (BAIT)

Simulations are delivered through a mail route agreed with you during onboarding. The domain that route sends from must publish SPF and DKIM records. BAIT also reports DMARC. Your Soveryne contact tells you which records are needed.

Scan scope (ATLAS)

ATLAS examines only the domains, IP addresses and ranges you add under Settings › Scope & consent. Before ATLAS sends a single request to anything under a domain, ownership of that domain must be proved. Passive research, which reads only public records, can start before that.

To prove a domain, add the TXT record ATLAS shows, then choose Verify:

Type	Name	Value
TXT	the domain itself, or `@` if it is the root of your DNS zone	`atlas-verification=<token shown in ATLAS>`

For IP addresses and ranges, any one of these proofs is enough:

a TXT record in the reverse DNS zone;

a reverse DNS name that contains the token;

reverse DNS that resolves to a host under a domain you have already verified;

registry contact details under a verified domain.

When a signed mandate is on file, ATLAS can also accept a challenge file on the web server, or a publicly trusted TLS certificate.

When DNS cannot be changed, an ATLAS administrator can record an attestation. It names where your authorisation is recorded, for example "Rules of engagement v2, signed …". The posture report shows who attested.

See ATLAS scope and consent for the full procedure.

← PreviousPeople and departments Next →Command