Domains & invitation policy

A domain is how your organization says "these addresses are ours". Claiming one proves nothing on its own — you prove it by publishing a DNS record only someone who controls the domain can publish. Once a domain is verified, it becomes the set your invitation policy is measured against.

Both halves live on one screen — Organization → Domains & invitations — because "verified domains only" names a set, and choosing that mode without seeing whether the set is empty tells you nothing.

Claim a domain#

1. Open Organization → Domains & invitations.
2. Type the domain in Claim a domain — the apex, with no scheme: acme.com, not https://www.acme.com.
3. Choose Claim domain. It is created as Awaiting DNS and its record is shown immediately.

Once one of your domains is verified, the Claim a domain form is no longer shown — the screen then shows your domains and the policy that rests on them.

These claims are refused, and each says so:

Refusal	Why
'gmail.com' is a public mailbox provider and cannot be claimed by an organization.	No one owns a consumer mailbox provider, and admitting everybody at one is not a domain policy
You have already claimed 'acme.com'.	Your organization already has this claim — use Show record on its row
An organization can claim at most 50 domains. Remove one you no longer use first.	The limit per organization

A verified domain covers exactly that domain. Proving acme.com does not cover eu.acme.com: if people are invited at a subdomain, claim and verify that subdomain too.

Claims are not exclusive — proof is#

Typing a domain reserves nothing. Several organizations can claim the same domain, and the first to verify it holds it: once one organization has proved a domain, nobody else can verify it. This is what stops a domain being held hostage by an organization that claimed it and never published a record.

Publish the record#

The claim issues a one-time challenge string. Publish it as a TXT record at the apex of the domain — not on a subdomain, and not on www:

Field	Value
Record name	the domain itself, e.g. acme.com. Some registrars call this the host and want @ for the apex
Record type	TXT
Value	pulsvault-verification=… — copy it exactly from the screen

Use Show record on the row and the copy buttons next to each field. Never retype the value or assemble it yourself: it is the exact string the verifier looks for, and one transposed character is indistinguishable from not having published it at all.

Then choose Verify.

Three other answers are possible, and none of them changes the domain's status:

Message	Means
'acme.com' is already verified by another organization.	Someone else proved it first. If that is wrong, the domain's DNS is not only in your hands
We couldn't reach DNS for 'acme.com' just now. Try again in a moment.	The lookup itself failed. Nothing was recorded — a DNS outage is never read as a missing record
This domain was checked a moment ago. Try again in 12 seconds.	One check per domain every 15 seconds. The number counts down to the next one allowed

What each status means#

Status	Means
Verified	The record was found. The domain counts towards your invitation policy
Awaiting DNS	Claimed, record issued, not yet found
Record not found	It was checked and the record was not there — either never published, or it stopped resolving

Every verified and previously verified domain is re-checked once a day, so a domain that stops resolving is noticed without anyone pressing anything — which is why a verified domain has no button to check it again. If DNS cannot be reached during that check, nothing changes — only a record that is genuinely absent demotes a domain. Two things follow from a demotion, and the second is the one worth knowing:

• Losing verification stops new invitations at that domain.
• It removes nobody. A domain is how a person was admitted, not a continuing condition of their membership.

A record that comes back — a DNS migration, usually — restores the domain on the next daily check, with nothing to re-claim. Both changes, verified to not-verified and back, are written to your audit log; repeated unsuccessful re-checks of an already-failed domain are not, so one broken domain does not produce a row a day forever.

Removing a domain has the same shape: it stops being usable for new invitations, and members who joined through it stay members. The screen asks you to confirm first, and says so when the domain is your only verified one — removing it means invitations are no longer restricted by domain. Then it asks for your master password: nothing is removed until it has been checked, and one password removes one domain.

Who you can invite#

The policy is checked against the domain of the address being invited, and nothing else.

Mode	Who may be invited
Verified domains only	(default) addresses at a domain you have proved you own
Verified domains, plus a list	those, plus the additional domains you list — for contractors and subsidiaries at a domain that is not yours
Any address	no restriction; every invitation is recorded in the audit log as a policy exception

Additional domains is one domain per line, up to 200, and it is kept whichever mode you are in — so you can build the list first and switch the mode on afterwards.

Public mailbox providers cannot be added to it:

'gmail.com' is a public mailbox provider. To invite any address, choose 'Any address' instead.

Listing gmail.com would mean "anyone with a Gmail address" — Any address under another name, without the audit record Any address writes for every invitation it lets through.

What a verified domain also buys you#

A verified domain is the only place PulsVault will tell you that an address already has an account. Adding somebody at sarah@acme.com with acme.com verified answers immediately:

That address already has an account.

Off a verified domain — an allowlisted contractor domain, or anything admitted while nothing is verified — the invitation is sent and the person is told when they open it. You run the mail server at a domain you have proved you own, so answering you there reveals nothing you could not already find out; answering anywhere else would let anybody with a Team plan test which addresses are registered with PulsVault.

An allowlisted domain is a preference, not a proof, and buys none of this. See Members for what to do with an address that is already taken.

Before your first domain verifies#

A brand-new organization has no verified domain, and proving one takes a DNS change that somebody has to be invited to make. So while nothing is verified, the restrictive modes restrict nothing: every invitation is admitted, and each one is recorded as a policy exception, exactly as under Any address. The screen says so in a banner rather than showing you a policy that is not running.

The moment a domain verifies, the mode starts meaning what it says. There is nothing to change and nothing to turn on.

What a refused invitation says#

The Add a member drawer lists your accepted domains in a note at the end of the form, and flags any other address before you send it. If the policy changes while the drawer is open, the server refuses the address with:

This organization's invitation policy does not admit addresses at this domain.

That names your own configuration and nothing about the person you tried to invite — not whether they have an account, what plan they are on, or whether they belong to another organization. This is deliberate: an invite response that varied with the invitee would be a way to test whether an address is registered here.

During a trial#

Domains are part of your paid plan. While your organization's subscription is a trial:

• you cannot claim or verify a domain, or change the list of additional domains — the screen shows a notice in their place;
• invitations are not restricted by domain: they are admitted and recorded as policy exceptions, exactly as before your first domain verifies;
• you can still choose the policy mode, and remove a domain.

Anything already on the screen is kept. Once the subscription is active, it applies again, and the daily re-check keeps its status honest in the meantime. A request made during a trial is refused with:

Domains are available once your subscription is active — not during a trial.

Who can do this#

Claiming, verifying, removing a domain and changing the policy all require business:config:manage — the owner and organization admins, and a permission the owner can delegate.

Reading the policy is open to any member, and only that one setting is. Someone whose invitation the policy refused is entitled to see which rule refused them and which domains it names.

Signing up for a business plan#

Separate from your policy, and applied by PulsVault to everyone:

• Disposable and temporary addresses are refused on every plan.
• Consumer mailbox providers — Gmail, Outlook, Yahoo and the rest — are refused when signing up for Team, Business or Enterprise. They remain fine on personal and family plans.

Someone joining through an invitation is not subject to the second rule. They are joining your organization, not buying a business plan, and their address is already governed by the policy above.

Addresses are also compared in a canonical form, so casey+billing@acme.com and casey@acme.com are recognised as one mailbox rather than two accounts. Mail is still delivered to the address as typed.

Related#

• Roles & permissions — who holds business:config:manage
• Audit logs — where domain claims, verification changes and policy exceptions are recorded