Set up single sign-on (SAML or OIDC)

Single sign-on lets your people sign in to DMARCLoop with your organisation’s identity provider, such as Microsoft Entra ID, Okta or Google Workspace. It is an add-on: if your plan doesn’t include it, the page says so and links to plans.

Owners and admins set it up under Single sign-on in the left sidebar. There are three parts: the identity provider, the domains it covers, and whether it is the only way in.

Connect your identity provider

Each organisation has one identity provider. Choose SAML 2.0 or OpenID Connect; your identity team will know which.

SAML 2.0

1. Under Give your identity provider these values, copy the Entity ID (audience) and the ACS URL (reply URL) into a new SAML application in your identity provider. Some providers can read them from the Metadata URL instead.
2. Have it send the person’s email address as the NameID, or as an email attribute, and sign the assertions.
3. Back in DMARCLoop, enter your identity provider’s Identity provider metadata URL, or paste the XML under Or paste the metadata XML. Without metadata, open No metadata? Enter the values instead and give its entity ID, sign-in URL and signing certificate.
4. Choose Save identity provider.

Every assertion must be signed with that certificate. Responses your identity provider sends without a sign-in having started here are refused.

OpenID Connect

1. Copy the Redirect URI into a new web application in your identity provider, and allow the openid, email and profile scopes.
2. Enter its Issuer URL, Client ID and Client secret, and choose Save identity provider.

We read the issuer’s OpenID configuration when you save, so a mistyped issuer is caught then. The client secret is encrypted before it is stored and is never shown again; leave the field blank when you edit the other settings to keep it.

Remove identity provider removes it. Nobody can then sign in with single sign-on, and SSO only is turned off.

Verify your domains

Sign-in goes to your identity provider only for email addresses on a domain you have proved is yours.

1. Under Verified domains, enter the domain, such as example.com, and choose Add domain.
2. Add the TXT record shown to that domain’s DNS. Its name is _dmarcloop-sso.example.com and its value starts with dmarcloop-sso=.
3. Choose Check. DNS changes can take a few minutes to show; check again if it isn’t found yet.

A verified domain covers its subdomains too, so verifying example.com also covers eu.example.com. A domain belongs to one organisation: if another has already verified it, or a domain above or below it, contact support.

Signing in

Your people choose Use SSO on the sign-in page, enter their work email and choose Continue. Their identity provider signs them in and sends them back.

Someone signing in for the first time gets a DMARCLoop account on the spot, with no email to confirm, and joins your organisation as Read-only while your plan has room for another person. Change their role under People; see invite people and roles.

Make single sign-on the only way in

With an identity provider saved and at least one verified domain, Turn on SSO only refuses every other way in for people with an address on your verified domains: password, passkey, Google and Microsoft sign-in, and resetting a password. They are told to choose Use SSO on the sign-in page. New accounts on those domains can’t be created with a password either.

So that your identity provider failing can’t lock everyone out, owners keep their password and passkeys as long as they have an authenticator app (see two-factor authentication) or a passkey. Emailed sign-in codes don’t count, because your mailbox may depend on the same identity provider. Turn on SSO only needs at least one owner with one of them. If no owner can get in, support can turn SSO only off once we have confirmed who you are.

SSO only also stops applying if the identity provider is removed, the last verified domain is removed, or your plan no longer includes single sign-on.

Every change here is recorded in the audit log.

MSP clients

Single sign-on belongs to each organisation. A client organisation sets up its own identity provider and domains; your MSP staff keep signing in the way they do today.