Single sign-on (SSO)

21 June 2026 · 17 min read

Single sign-on (SSO) lets your team get into the DMARC Engine dashboard at app.dmarcengine.com using the same identity provider they already use for everything else: Okta, Microsoft Entra ID, Google Workspace, Auth0, or any other provider that speaks OpenID Connect. Instead of each colleague holding a separate DMARC Engine password, sign-in is handed to your provider, your provider decides who is allowed in, and DMARC Engine trusts that decision. When someone leaves your company and you disable them in your provider, they lose access to DMARC Engine at the same moment, without anyone having to remember to remove them from a second system.

This page is the practical guide to setting that up: which providers work, how the OpenID Connect (OIDC) configuration fits together, what happens when you enforce SSO, and exactly how a person's role inside DMARC Engine is decided when they sign in through your provider for the first time. SSO is an organisation-level setting, so configuring it once covers every member of your DMARC Engine organisation, across every domain that organisation manages.

What SSO actually does here

When SSO is configured, the login page gains a "Sign in with SSO" option. A team member enters their work email, DMARC Engine looks up which organisation owns that email domain, and if that organisation has SSO enabled it redirects the browser to your identity provider. Your provider authenticates the person (password, passkey, push prompt, hardware key, whatever you have configured), then redirects back to DMARC Engine with a signed proof of who they are. DMARC Engine verifies that proof cryptographically, checks the email is in your configured domain, and starts a session.

The important point is that DMARC Engine never sees your users' passwords. It only ever receives a short-lived, signed token from your provider that says "this is alice@acme.com, verified, here is when this token expires". Authentication policy, multi-factor requirements, device posture, conditional access: all of that stays in your provider where you already manage it.

SSO is independent of the dashboard's own two-factor authentication. If you do not use SSO, individual members can still protect their accounts with the built-in 2FA. Once you enforce SSO, your provider's own MFA policy is what protects sign-in, so you generally rely on that rather than the local 2FA.

Supported providers

DMARC Engine implements the relying-party side of OpenID Connect (OIDC), the authentication layer built on top of OAuth 2.0. Any provider that exposes a standard OIDC discovery document works without a bespoke connector. The providers we have tested and that appear in the dashboard's own guidance are:

Okta
Microsoft Entra ID (formerly Azure Active Directory)
Google Workspace
Auth0

In practice the list is much broader, because OIDC is a standard rather than a vendor feature. OneLogin, JumpCloud, Ping Identity, Keycloak, and most other modern identity platforms expose an OIDC application type and will work the same way. If your provider can give you an issuer URL, a client ID, and a client secret for a web application, and it publishes a discovery document at https://your-issuer/.well-known/openid-configuration, it is compatible.

A note on SAML versus OIDC

Many enterprise SSO conversations start with SAML, because SAML 2.0 has been the long-standing standard for browser-based single sign-on. DMARC Engine uses OIDC rather than SAML for the connection itself. This is a deliberate choice: OIDC is JSON and HTTPS based, it carries identity in a signed JWT (the id_token), and it maps cleanly onto a modern relying party running on Cloudflare's edge.

This is rarely a limitation in practice, because the major identity providers all expose both. The same Okta org, Entra tenant, Google Workspace, or Auth0 tenant that you might connect to other tools over SAML also offers an OIDC application type. You create an OIDC (sometimes labelled "OpenID Connect" or "Web") application instead of a SAML one, and you are connecting to the same directory, the same users, and the same MFA policy. If you have an internal standard that mandates SAML specifically for every integration, raise it with us before you start so we can talk through the options; for almost everyone, creating an OIDC app alongside your SAML apps is straightforward.

What you need before you start

You will configure SSO from the dashboard under Settings, Security. Only an organisation admin can change SSO settings, so make sure you are signed in as an admin first. Gather these four things from your identity provider:

Issuer URL. The base URL of your provider's OIDC service, for example https://acme.okta.com or https://login.microsoftonline.com/<tenant-id>/v2.0. DMARC Engine appends /.well-known/openid-configuration to discover the rest of the endpoints automatically, so you do not need to copy individual authorize, token, or JWKS URLs.
Client ID. The public identifier of the OIDC application you create in your provider for DMARC Engine.
Client secret. The confidential credential that pairs with the client ID. Treat this exactly as you would a password; DMARC Engine stores it encrypted at rest.
Email domain. The domain your team signs in with, for example acme.com. This is how DMARC Engine routes a sign-in attempt to the right organisation and your provider.

You will also need one value going the other way, from DMARC Engine into your provider: the redirect (callback) URL.

The redirect URL

Every OIDC application requires you to register the exact URL the provider is allowed to send users back to after authentication. For DMARC Engine that URL is always:

https://app.dmarcengine.com/api/auth/sso/callback

The Settings, Security page shows this value with a copy button so you do not have to type it. Paste it into your provider's allowed redirect URIs (the field is variously named "Sign-in redirect URIs", "Redirect URI", "Authorized redirect URIs", or "Callback URL" depending on the provider). It must match character for character, including the https://, with no trailing slash. A mismatch is the single most common cause of a failed first connection, and providers deliberately reject anything that does not match exactly, because a loose redirect URL is a real security hole.

Step by step: configuring OIDC

The flow is the same for every provider; only the wording in their admin console differs.

1. Create an OIDC application in your provider

In your identity provider, create a new application of type OIDC / OpenID Connect, for a web application (the kind that can hold a confidential client secret, also called a "regular web app" or "confidential client"). Set the redirect URI to the callback URL above. Request the standard scopes openid, email, and profile; these are what DMARC Engine asks for, and they let it read the verified email and display name. You do not need any directory or admin API scopes; DMARC Engine never reads your wider directory.

Provider-specific notes:

Okta: create an "OIDC, Web Application", grant the relevant users or groups access to the app, and copy the client ID and secret from the General tab. Your issuer is your Okta org URL, often with /oauth2/default for the default authorization server.
Microsoft Entra ID: register a new application, add the redirect URI under the Web platform, and create a client secret under "Certificates and secrets". Your issuer is typically https://login.microsoftonline.com/<tenant-id>/v2.0. Entra issues tenant-specific issuer values in its tokens, and DMARC Engine validates those correctly.
Google Workspace: create an "OAuth 2.0 Client ID" of type "Web application" in the Google Cloud console, add the redirect URI, and use Google's issuer https://accounts.google.com.
Auth0: create a "Regular Web Application", add the callback URL, and use your tenant issuer such as https://acme.eu.auth0.com/.

2. Enter the details in DMARC Engine

Back in Settings, Security, open the Single Sign-On card and enter the Issuer URL, Client ID, Client Secret, and Email domain. Choose the default role for new users (covered in detail below) and decide whether to allow just-in-time provisioning. Save.

When you save with SSO switched on, DMARC Engine immediately fetches your issuer's discovery document to confirm the provider is reachable and that the issuer is valid. If the issuer is wrong or unreachable, the save is refused with a clear message rather than silently storing a broken configuration. This pre-flight check means that if the save succeeds, the connection genuinely works, and you are not left discovering a typo only when a colleague tries to log in.

3. Test, then enforce

Save with SSO enabled but before announcing it to your team, then test the login yourself: go to the login page, choose "Sign in with SSO", and enter an email on your configured domain. You should be bounced to your provider and back into the dashboard. Confirm a session starts and you land on the dashboard home. Only once that round trip works for you should you tell the rest of the team to switch over.

For the security-minded, here is what actually happens on each SSO login, because it explains several of the behaviours and error messages you might encounter.

Domain routing. The user enters their email. DMARC Engine takes the domain part and looks up which organisation has claimed it for SSO. An email domain can be claimed by only one organisation, so routing is unambiguous; if two tenants tried to claim acme.com, logins could be sent to the wrong provider, so the second claim is refused at configuration time.
Authorization request with PKCE. DMARC Engine generates a random state and nonce, plus a PKCE code verifier and challenge (PKCE is the OAuth 2.1 protection that stops an intercepted authorization code from being replayed). It stores the verifier server-side for ten minutes and redirects the browser to your provider's authorization endpoint.
Authentication at your provider. Your provider does whatever your policy requires: password, MFA, conditional access, device checks. DMARC Engine is not involved and never sees any of it.
Callback and token exchange. Your provider redirects back to the callback URL with an authorization code. DMARC Engine checks the state matches, exchanges the code (with the PKCE verifier and the client secret) for an id_token, and verifies that token: the RS256 signature is checked against your provider's published signing keys (JWKS), and the issuer, audience, expiry, and nonce claims are all validated. A token that fails any check is rejected.
Email verification and domain match. DMARC Engine requires the token to carry a verified email, and that email's domain must match your configured domain. An identity provider cannot assert an arbitrary address into your organisation, because the domain is pinned.
Session. If everything checks out, DMARC Engine finds or creates the user, applies your IP allowlist if you have one configured (the allowlist applies to SSO logins exactly as it does to password logins), records the sign-in in the audit log, and issues a session.

Because the whole exchange is signed and bound by state, nonce, and PKCE, an attacker who intercepts a redirect or replays a stale code cannot get a session out of it.

How roles map from your provider

This is the part teams most often get wrong elsewhere, so it is worth being precise. DMARC Engine has three roles inside an organisation:

Admin: full control. Manage domains, change DNS and authentication settings, move policies towards enforcement, invite and remove team members, view and download billing invoices, manage API keys, the IP allowlist, and SSO itself.
Editor: can manage domains and records (SPF, DKIM, DMARC, MTA-STS, BIMI) and act on findings, but cannot change organisation-level security settings or manage other members.
Viewer: read-only. Can see domains, aggregate report data, and the dashboard, but cannot change anything.

When a new person signs in via SSO for the first time and no account exists for them yet, DMARC Engine creates one (if you have just-in-time provisioning on) and assigns it the default role you chose in the SSO settings. That is the whole of the automatic mapping: everyone provisioned through SSO starts on the same default role, and an admin promotes individuals afterwards from Settings, Team.

DMARC Engine does not read group or role claims from your provider's token and translate them into DMARC Engine roles. There is no rule engine that says "members of the dmarc-admins group in Okta become admins here". The reasons for keeping it simple are deliberate:

No silent privilege escalation. If role assignment were driven by a provider claim, a misconfigured group or a token quirk could hand someone admin rights without anyone in DMARC Engine choosing to grant them. By keeping promotion an explicit action inside DMARC Engine, the person who grants admin is recorded in the audit log.
The default role is capped below admin. For exactly this reason, the just-in-time default role can only be viewer or editor, never admin. Even if you try to set the default to admin, a freshly provisioned SSO user is created as an editor at most. New people therefore never arrive with the keys to your DNS and organisation settings; an existing admin has to deliberately promote them.

Choosing your default role

Pick viewer if most people who sign in should only watch reports and dashboards, and you will promote the few who need to make changes. This is the safest default and the one we recommend for larger teams.
Pick editor if your SSO population is a small, trusted operations team where everyone is expected to manage records. You still promote to admin manually.

If you ever need to change someone's role, an admin does it under Settings, Team: select the member and pick a new role. Role changes take effect on their next request; there is no need for them to sign out and back in.

Just-in-time provisioning

The just-in-time (JIT) provisioning toggle controls what happens the first time an unknown user from your domain signs in:

JIT on (the default): the account is created automatically with the default role. This is the low-friction option; you do not have to pre-invite anyone, and access is governed entirely by who your provider lets through. If you remove someone in your provider, they can no longer authenticate, so they can no longer reach DMARC Engine.
JIT off: an SSO sign-in only succeeds for people who already have a DMARC Engine account in your organisation. A brand-new user is turned away with a message telling them to ask an admin to invite them. Choose this if you want an explicit allowlist of members inside DMARC Engine in addition to access in your provider, for example to keep your seat count tightly controlled.

Either way, the email in the token must be verified and in your configured domain, and an email that already belongs to a different organisation is refused, so you cannot accidentally pull a user out of another tenant.

Enforcing SSO

There are two related but distinct ideas here, and it helps to keep them apart:

Enabling SSO makes the "Sign in with SSO" route available for your domain. Saving the configuration with the toggle on does this.
Enforcing SSO is the operational decision to make SSO the only way your team signs in.

In the current model, the SSO toggle is labelled "Enforcing SSO" when on, and once your domain is claimed and SSO is enabled, your members sign in through your provider. The practical way to enforce SSO cleanly is:

Configure and enable SSO, and test it yourself.
Have each existing team member sign in once via SSO so their account is matched to your provider.
Tell the team to stop using password login and use "Sign in with SSO" from then on.

Because access is ultimately gated by your provider once SSO is in use, deprovisioning is centralised: disabling a user in Okta, Entra, Google Workspace, or Auth0 cuts off their DMARC Engine access too. If you want every byte of account lifecycle to run through your provider, leave JIT on and never invite people manually; the provider becomes the single source of truth for who is in your DMARC Engine organisation.

A sensible safety habit while you roll this out: keep at least one admin who can still recover the account if your provider has an outage, and make sure that admin has tested the SSO path. If your provider is down and SSO is your only route, you want a known-good fallback rather than discovering the problem mid-incident. Talk to us if you need a break-glass arrangement for your organisation.

SCIM and automated user lifecycle

DMARC Engine does not currently offer SCIM provisioning (the protocol some platforms use to push user and group changes from your directory in real time). User lifecycle is handled through the simpler model above: JIT creates accounts on first sign-in, and removing access in your provider stops future sign-ins. Existing sessions are not instantly killed by a provider-side change, so for an immediate lockout of a specific person, an admin should also remove that member under Settings, Team, which revokes their access on the next request. If SCIM is a hard requirement for your environment, let us know what you need, because the demand shapes what we build next.

Troubleshooting

A few errors come up often enough to list with their real cause:

"SSO is not configured for your email domain." The domain in the email you entered is not claimed by any organisation with SSO enabled. Check the Email domain field in your SSO settings matches the part after the @ exactly (no leading @, lower case).
"Could not load the IdP discovery document" or "Could not reach your identity provider." The issuer URL is wrong, or your provider's discovery endpoint is not reachable. Confirm https://<issuer>/.well-known/openid-configuration loads in a browser and returns JSON. Remember Entra issuers usually end in /v2.0.
Redirect URI mismatch (an error shown by your provider, not by DMARC Engine). The callback URL registered in your provider does not exactly match https://app.dmarcengine.com/api/auth/sso/callback. Copy it again from the Security settings and paste without edits.
"Your IdP did not provide a verified email." Your provider sent a token without an email, or with email_verified set to false. Make sure the email scope is granted and the user's email is verified in your directory.
"Your email domain is not permitted for this organization." The verified email in the token is not in your configured domain. This is the domain-pinning protection working as intended; it means your provider returned an address outside the domain you claimed.
"This email already belongs to another organization." That email address is registered to a different DMARC Engine organisation. An address can belong to one organisation only.
"Access is not permitted from your current network." Your organisation has an IP allowlist enabled and the sign-in came from an address outside it. The allowlist applies to SSO logins as well as password logins.
"That email domain is already configured for SSO by another organization" (seen when saving settings). Another tenant has already claimed this domain. Contact us if you believe the domain is rightfully yours.

If a sign-in fails for a reason not listed here, an admin can check the audit log under Settings for the recorded SSO events, and you can always reach support with the approximate time and the email domain involved.

Where SSO fits in your wider setup

SSO governs who gets into the dashboard; it does not change anything about the email authentication work the platform does for you. The same admins and editors who sign in through your provider still drive the journey from p=none to p=reject, manage hosted SPF, DKIM and DMARC, and read the aggregate reports that confirm enforcement is safe. If you automate domain onboarding through the API as well, note that API keys are a separate credential to SSO: keys authenticate machines and are scoped by permission, whereas SSO authenticates people in the browser. Most enterprise teams use both, SSO for humans in the dashboard and scoped API keys for their provisioning pipelines.

If you are still deciding whether your team needs the dashboard at all, or what is involved technically, the short answer is that the heavy lifting is done for you; see do I need technical knowledge and what is DMARC Engine. When you are ready to connect your provider, head to Settings, Security in the dashboard, and if you hit anything this page does not cover, contact support and we will get your provider connected.