Team and Roles

21 June 2026 · 13 min read

Email authentication is rarely a one-person job. Someone owns the DNS, someone reads the aggregate reports, someone signs off on tightening a policy to p=reject, and someone in finance just wants the invoices. DMARC Engine lets you bring those people into your organisation with the right level of access, so the person reading reports cannot accidentally change a live record, and the person who pays the bill does not need to learn what an SPF lookup is.

This guide covers the Team tab in Settings: inviting members, the three roles (admin, editor and viewer) and exactly what each one can and cannot do, changing someone's role later, and removing a member when they leave. It also explains how the Team tab sits alongside the other Settings tabs, so you know which controls belong to your whole organisation and which are personal to you.

If you have not signed in yet, head to https://app.dmarcengine.com and log in. New to the platform overall? Start with Getting started first, then come back here once you are ready to bring colleagues on board.

Where Team lives: the Settings tabs

Open Settings from the left-hand navigation, or go straight to the path /settings. Settings is organised into a row of tabs across the top. From left to right they are:

Profile: your personal details on this account.
Organization: the shared details for your whole organisation.
Security: your sign-in protections, sessions and login history.
Notifications: where and how alerts are delivered.
API Keys: programmatic access tokens for the API.
Team: the people in your organisation and their roles.
Billing: your plan, usage and invoices.

It is worth being clear about the split before you start inviting people. Profile and Security are personal: they only ever affect you, the signed-in user. Organization, Team, Billing, Notifications and API Keys are shared across the organisation, which is why who can reach them depends on your role. The rest of this guide focuses on Team, but the two tabs either side of it matter for context, so they are covered briefly first.

Profile (personal)

The Profile tab holds your own account details. It has:

Profile Name: the display name other members see beside your entries in the team list and in activity logs. Edit it freely.
Email: shown read-only. This is the address you sign in with and the one invitations were sent to. It cannot be changed from this field; if you need a different sign-in address, contact support.
Save Profile: writes any change to Profile Name.

Every member, whatever their role, can edit their own Profile. Changing your own profile name does not touch anyone else's access.

Organization (shared)

The Organization tab holds the details that describe your whole account rather than you personally:

Organization Name: the name that appears across the dashboard and on reports for your account.
Organization Email: the primary contact address for the organisation, used for account-level correspondence.
Timezone: the timezone the dashboard uses when it shows dates and times, including report timestamps and renewal dates. Set this to your team's working timezone so that "yesterday" in a report means what you expect.
Save Organization: writes your changes.

Because these settings affect everyone, only an admin can change them. Editors and viewers can see the organisation details but the Save Organization action is reserved for admins. Getting the timezone right early is a small thing that saves a lot of confusion when several people are reading the same aggregate reports.

The three roles

DMARC Engine uses three roles. They are deliberately simple, so there is never any doubt about what a given person can do. Every member of your organisation has exactly one role at a time.

Admin

An admin has full control of the organisation. An admin can:

Add, verify and delete domains, and run the full setup for DMARC, SPF, DKIM, MTA-STS and BIMI.
Change live records and move a domain's policy along the enforcement journey, including the decision to go to p=quarantine and p=reject.
Manage the whole Team tab: invite members, change roles and remove people.
Edit the Organization tab, including the organisation name, email and timezone.
View Billing: see the current plan and usage, and view and download invoices. Plan changes, payment methods and subscription matters are arranged with our team rather than self-served in the dashboard.
Create and revoke API Keys, and manage Notification Channels.

In short, anything in the dashboard is open to an admin. Keep the number of admins small. Two or three is healthy: enough that you are never locked out if one person is away, few enough that high-impact actions such as deleting a domain or changing a policy stay with the people accountable for them.

Editor

An editor can do the day-to-day authentication work but cannot manage the organisation itself. An editor can:

Add and configure domains, and run service setup for DMARC, SPF, DKIM, MTA-STS and BIMI.
Make changes to records, work through alignment, and read every report and analytic.
Acknowledge alerts and carry out the operational tasks that keep a domain healthy.

An editor cannot reach the organisation-management controls. That means an editor cannot invite or remove team members, cannot change anyone's role, cannot see Billing, and cannot change Organization settings. This is the right role for the engineer or consultant who does the hands-on work but should not be moving people in and out of the account or seeing the invoices.

Viewer

A viewer has read-only access. A viewer can:

Open the dashboard, see every domain and its current status, and read the analytics and aggregate reports.
Review the compliance gauge, the pass/fail trend and the threat view to understand where things stand.

A viewer cannot change anything. They cannot add or edit domains, cannot alter records, cannot manage the team, billing or organisation settings. Viewer is ideal for a stakeholder who needs visibility (a manager, an auditor, a client, or a colleague in security or compliance) without any risk of an accidental change to a live record. It is also the safest default if you are unsure: you can always raise someone's role later, and that is far easier than undoing an unwanted change.

A quick way to remember it: viewers read, editors do, admins govern. If a person's job is to make changes to your email authentication, they are an editor. If their job is to decide who has access, they are an admin. Everyone else is a viewer.

The Team tab

Open the Team tab in Settings. The page is built around a single table of the people in your organisation, with one button above it to bring new people in.

The members table

Each row in the table is one member of your organisation. The columns are:

Name: the member's display name, taken from their Profile Name. Until someone has accepted their invitation and set up their profile, this shows the name you entered when inviting them.
Email: the address they sign in with and the address their invitation was sent to.
Role: their current role, shown as admin, editor or viewer. This is the single field that decides what they can do.
Status: where the member is in their lifecycle. A member who has accepted their invite and signed in shows as active; a member you have invited but who has not yet accepted shows as pending. Use this column to tell at a glance whether someone is genuinely set up or still has an invitation waiting in their inbox.

At the end of each row are the actions you can take on that member: Change Role and Remove. Both are covered below. These actions only appear, and only work, if you are an admin; an editor or viewer sees the table as read-only.

Inviting a team member

To bring someone new into your organisation, select Invite Team Member. This opens a modal with the following fields:

Email: the email address of the person you are inviting. The invitation is sent here, and this becomes the address they sign in with, so type it carefully. Each email can belong to one member of your organisation.
Role: the role the new member will start with: admin, editor or viewer. Choose the least access that lets them do their job. You can change it later from the table, so when in doubt, start with viewer.
Name: the name to show for this member in the table and in activity logs before they have set up their own profile. Once they accept and edit their Profile Name, that takes over.

When the fields are right, select Send Invite. DMARC Engine emails an invitation to the address you entered. The new member appears in the table straight away with a pending status while they accept.

To accept, the invited person opens the email and follows the link, then signs in or creates their sign-in for that email address. As soon as they have accepted, their status moves to active and the Name column fills in from their own profile. If the invitation does not arrive, ask them to check spam, confirm you typed the Email correctly, and if needed remove the pending entry and invite again. An invitation is tied to the exact address you entered, so a typo means the email goes nowhere.

Only admins can send invitations. If you do not see the Invite Team Member button, your role is editor or viewer; ask one of your organisation's admins to invite the person, or to raise your role.

Changing a member's role

People's responsibilities change. Someone who started as a viewer may take on the hands-on work and need to become an editor; an editor leaving the project may step back to viewer; you may need to promote a trusted colleague to admin so you are not the only one who can manage the account.

To change a role, find the member's row in the table and select Change Role. Pick the new role (admin, editor or viewer) and confirm. The change takes effect immediately: the member's permissions update the next time they act in the dashboard, with no need for them to be re-invited or to sign in again for the new role to apply.

A few points worth keeping in mind:

Promoting to admin is a meaningful step. An admin can see billing, remove other members (including you) and change any record. Only promote people you would trust with the whole account.
Demoting an admin to editor or viewer immediately removes their access to Team, Billing and Organization. If you are reducing someone's access because they are leaving, consider whether Remove is the cleaner action.
Make sure at least one admin always remains. If you are the only admin, the platform will not let you demote yourself into a position where the organisation has no admin at all, because that would leave the account ungovernable. Promote someone else to admin first, then change your own role if you need to.

Removing a member

When someone leaves your team, a project ends, or a client engagement closes, remove their access promptly. Find their row in the table and select Remove, then confirm. Removal takes effect immediately: the person can no longer sign in to your organisation or see any of your domains, reports or settings.

Removing a member does not delete or change any of your domains, records or reports; it only revokes that person's access. If the member had a pending invitation that they never accepted, Remove simply cancels the invitation so the link no longer works.

As with role changes, you cannot remove the last remaining admin, because every organisation must keep at least one. If you are winding the account down to a single admin, remove the other members first and keep one admin in place. When a member with admin rights leaves, the safe order is: promote or confirm another admin, then remove the departing one.

Security tip: removing a member ends their access to the organisation, but it does not retire any API Keys that were created under your account, since keys belong to the organisation rather than to a person. If a departing member generated keys, open the API Keys tab and use Regenerate or Delete on anything they touched. The same applies to any Notification Channels they set up.

How roles interact with the rest of Settings

Because roles gate the shared tabs, it helps to know what each role sees across the whole of Settings. This keeps expectations clear when you invite someone and they ask why a tab looks read-only.

Profile and Security are personal and available to everyone. Every member manages their own profile name and their own sign-in protections regardless of role. See Security and 2FA for two-factor authentication, session management, the password change and the login activity log on the Security tab.
Notifications lets admins (and editors, for operational alerts) manage the channel list, where each channel has a name, a type, an on/off toggle, a Test action and a delete control, plus a Create Notification Channel button. Getting alerts to the right place is covered in Setting up alerts.
API Keys is an admin-level area. The table lists each key by Name, its Permissions (read or read-write), when it was Created and when it was Last used, with Regenerate and Delete actions per key. Create API Key opens a modal where you set a Key Name and tick the Permissions you want; the raw key is shown once, at creation, and never again, so copy it immediately.
Billing is reserved for admins, and it is read-only. It shows your current plan, the renewal date and your usage, and lists your invoice history so you can view and download invoices. There is no self-serve plan upgrade, downgrade, cancellation or payment-method management in the dashboard; those are arranged with our team. If an editor or viewer needs a copy of an invoice, an admin can download it for them.

Granting the right role therefore does more than control who edits a record: it quietly decides who can see your invoices, who can issue API keys and who receives operational alerts. Match the role to the responsibility and these controls take care of themselves.

A sensible starting structure

If you are setting up your team for the first time, a structure that works for most organisations is:

Keep yourself, and one trusted colleague, as admin. That covers you for holidays and handovers without spreading high-impact access too widely.
Invite the people who will do the hands-on authentication work (your IT staff, an MSP, or a consultant) as editor. They can add domains, fix alignment and move policies along the enforcement journey without being able to see billing or manage membership.
Invite everyone who only needs to watch (managers, security and compliance colleagues, or clients) as viewer. They get full visibility into status and reports with zero ability to break anything.

You can revisit this at any time from the Team tab. Start narrow, widen access only when a real need appears, and remove people the moment they no longer need access. That discipline keeps your account both easy to run and hard to misuse.

Next steps

New here? Work through Getting started and then Adding your first domain.
Decide where alerts go for your newly invited editors and viewers in Setting up alerts.
Lock down your own access with Security and 2FA before you hand the keys to anyone else.
Want to check a domain's posture before inviting a client to view it? Run the free DMARC checker or the DMARC report analyzer, or read the requirements the major mailbox providers now enforce. If a term here is new, the glossary has plain-English definitions.