Adding your first domain

31 May 2026 · The DMARC Engine Team · 28 min read

Who this guide is for

This guide walks you through adding your first domain to DMARC Engine, verifying you own it, and understanding the dashboard that appears once it's in the system. It assumes you can log in to your DNS provider (your registrar or a service like Cloudflare, GoDaddy, or Route 53) and edit records there. You don't need to know DMARC, SPF, DKIM, MTA-STS, or BIMI in depth - we'll explain each as it comes up - but if you want the full background on any one of them, see the sibling guides linked throughout this article.

DMARC Engine is a hosted email-authentication platform. For every record type we support, the fastest and lowest-maintenance option is to delegate that record to us with a single CNAME, and let us serve and auto-manage the contents from then on. Every record type also has a manual, self-managed alternative, where you publish the value yourself and keep it up to date. This guide covers both paths, but leads with the hosted one because it's what most customers should use.

Note: Nothing in this guide changes your mail flow. Adding a domain and even publishing DMARC/SPF/DKIM records does not, by itself, affect delivery - DMARC in particular is designed to be introduced safely, starting in monitor-only mode. You control when (and whether) you move to enforcement.

Why delegate a CNAME instead of publishing the record yourself?

Every record covered in this guide - DMARC, SPF, DKIM, MTA-STS, BIMI - is, underneath, just a TXT (or HTTPS-hosted file) with a specific syntax that has to be kept correct and current. Delegating with a CNAME means the content lives on our infrastructure rather than in your zone file, so:

• SPF stays under the 10-lookup limit automatically. As you add or change sending sources (a new ESP, a helpdesk tool, a marketing platform), we re-flatten the resolved record - you don't recount lookups by hand.
• DKIM keys can be rotated without a DNS edit. Rotating a manually published key means publishing the new TXT, waiting for propagation, then removing the old one - three separate DNS changes for one rotation. With hosted DKIM, rotation happens behind the CNAME.
• MTA-STS certificate renewal isn't your problem. The policy is served over our SSL-for-SaaS certificate for your hostname, renewed on our schedule, not yours.
• Policy and reporting-address changes happen in the app, not in your DNS console - useful if DNS changes at your organisation go through a change-control process and you'd rather tune DMARC policy without filing a ticket every time.

The trade-off is a dependency on our infrastructure being up - which is why the manual, self-managed alternative is documented for every record type in this guide, and why nothing stops you from moving a given record from hosted to manual (or back) later.

---

Before you start

You'll need:

1. Access to your DNS zone for the domain you're adding (the ability to create TXT and CNAME records).
2. A DMARC Engine account at app.dmarcengine.com. If you don't have one yet, sign up from dmarcengine.com.
3. The domain's exact spelling - apex domain (e.g. example.com) or a subdomain you send mail from (e.g. mail.example.com). Each is added and verified separately.
4. Ten minutes, plus however long your DNS provider's changes take to propagate (usually minutes, occasionally up to a few hours).

Tip: If you're not sure what's currently published for a domain - or want to sanity-check a record before or after you make a change - the free DNS Lookup tool and the in-app Lookup page will resolve and interpret DMARC, SPF, DKIM, MTA-STS, and BIMI records for any domain, no login required for the public version.

---

Step 1: Add the domain in DMARC Engine

1. Log in and open Domains from the left-hand navigation.
2. Click Add domain.
3. Enter the domain name exactly as it appears in your DNS zone - no http://, no trailing dot, no www. unless you genuinely send mail from www.example.com. Use the apex (example.com) in almost all cases; DMARC policy is set at the organisational domain and covers subdomains by default.
4. Optionally assign the domain to a domain group (see Domain groups below) - useful immediately if you're onboarding more than a handful of domains, otherwise skip it and organise later.
5. Click Create domain.

DMARC Engine creates a record for the domain and immediately generates two things you'll use throughout the rest of setup:

• A verification TXT value, proving to us that you control the domain.
• A hosting slug - a short, unique identifier for this domain used in every CNAME target we ask you to publish.

The domain now appears on your Domains list with a status of Pending.

Warning: Adding a domain does not automatically protect it. Nothing changes in your DNS until you publish the records described in the next steps. A domain that's only been added, with no records published, sits at Pending indefinitely and provides no protection.

Understanding your hosting slug

Every domain you add gets its own hosting slug - a short alphanumeric string, unique to that domain, that appears in the CNAME targets we give you (for example a1b2c3._dmarc.dmarcengine.com). It's how our edge servers know which customer's records to serve when a mailbox provider queries _dmarc.yourdomain.com.

You'll see the slug on the domain's overview page and again on each per-service builder page (/dmarc, /spf, /dkim, /mta-sts, /bimi), pre-filled into the exact CNAME value you need to copy. You never need to construct it yourself - copy it from the app.

Note: The slug is stable for the life of the domain in your account. If you ever remove and re-add a domain, you'll be issued a new slug and will need to republish any CNAMEs pointing at the old one.

---

Step 2: Verify domain ownership

Before DMARC Engine will serve any hosted record on your behalf, you need to prove you control the domain. This is a one-time step per domain.

Method A: TXT verification record (default, recommended)

1. On the domain's page, open the Verification panel.
2. Copy the TXT record shown. It will look like this (your token will differ):

Host:  _dmarcengine-verify.example.com
Type:  TXT
Value: dmarcengine-verify=8f2a1c9d4e7b6053a1f0c2e9b7d4a615

1. Log in to your DNS provider and add exactly that TXT record at that host name, under the domain's zone.
2. Save the change in your DNS provider.
3. Back in DMARC Engine, click Check verification on the domain's page.

Verification usually completes within a few minutes, limited mostly by your DNS provider's propagation time and the TTL you (or the previous record owner) set. If it doesn't pass on the first check, wait 10-15 minutes and try again - see Common problems and fixes if it's still failing after that.

Tip: You can leave the verification TXT record in place indefinitely - it does no harm - but you're free to remove it once the domain shows Verified, since it isn't consulted again for day-to-day operation.

Method B: Verify via an existing hosted CNAME

If you'd rather go straight to publishing your first hosted record (most commonly DMARC) instead of a separate verification-only TXT, you can do that too:

1. Publish the _dmarc.<domain> CNAME described in Step 4: set up your first service before running verification.
2. Return to the domain's Verification panel and click Check verification.

Because that CNAME resolves through our infrastructure and is unique to your slug, its presence is itself proof of control, and DMARC Engine will mark the domain Verified the moment it resolves correctly - no separate TXT record needed. This is a convenient shortcut if you're confident you'll be publishing the DMARC CNAME immediately anyway.

Method C: Domain-level DNS delegation (advanced)

If you manage DNS for the domain inside Cloudflare and are comfortable delegating the whole zone or using Cloudflare's own API access for verification workflows, talk to Support about account-level API verification for bulk onboarding - this is typically only worth setting up for agencies or MSPs managing dozens of client domains, and isn't required for a single domain.

Warning: Until a domain shows Verified, none of its hosted CNAME targets (*.dmarcengine.com) will resolve to real content - they exist as inert placeholders. Verify first, then publish the service records; doing it in the other order just means a short wait before things "light up," not an error.

---

Step 3: Bulk import domains (optional)

If you're onboarding more than a few domains - for an agency, a group of subsidiaries, or a large sending estate - you don't need to repeat Step 1 by hand for each one.

1. From Domains, click Import.
2. Download the CSV template if you don't already have a domain list in the right shape. The template expects one domain per row, with an optional second column for a domain group name.
3. Fill in your domains (one per line, apex or subdomain as appropriate) and save as CSV.
4. Upload the file.
5. Review the preview screen - it flags duplicates and anything that isn't a syntactically valid domain name before import.
6. Click Import domains to confirm.

Every imported domain lands in Pending with its own verification TXT and hosting slug generated automatically, exactly as if you'd added it one at a time. You'll still need to publish a verification record (or the first hosted CNAME) per domain - bulk import saves you the domain-creation step, not the DNS work, since DNS access is inherently per-zone.

Tip: Assign a domain group during import (see below) so a large batch doesn't land as one undifferentiated list.

---

Organising domains with domain groups

Domain groups are simple folders for your domain list - there's no behavioural difference between a domain in a group and one that isn't; grouping only affects how domains are filtered and displayed across Domains, Analytics, and Reports.

Typical uses:

• Separating production sending domains from parked/defensive domains you own but never send from.
• Grouping domains by business unit, brand, or client (agencies and MSPs).
• Isolating a pilot group of low-risk domains while you learn the platform, before rolling out to your full portfolio.

To create and use a group:

1. Go to Domains and click Manage groups.
2. Click New group, give it a name (e.g. Marketing subsidiaries), and save.
3. Assign domains to the group either individually (open a domain → Edit → Group) or in bulk (select multiple domains on the list → Add to group).
4. Use the group filter at the top of the Domains list, and on Analytics, to scope your view.

Note: A domain can belong to only one group at a time. Moving it to a new group removes it from the old one; it doesn't duplicate.

---

Understanding domain status

Once a domain exists in DMARC Engine, it moves through a small number of states. These appear as a badge next to the domain name on the Domains list and at the top of the domain's own page.

Note: "Fully protected" is a status about record health, not a guarantee that every message from your domain passes authentication at every receiver. Use Analytics and Threats to see how your real mail streams are actually authenticating - that's a separate, ongoing signal from the record-configuration status shown here.

---

The per-service tiles

Open any domain from Domains and you'll land on its overview page: five tiles, one per service, each showing a status (not configured / needs attention / hosted / manual-OK) and a Configure or Manage button that takes you to that service's dedicated builder.

Each tile is independent - you don't have to configure all five before any of them takes effect, and there's no required order beyond DMARC and SPF/DKIM logically coming first (BIMI, in particular, requires DMARC already at enforcement). Most customers start with DMARC in monitor mode, add SPF and DKIM, watch reports for a few weeks, then move DMARC to enforcement and finally layer on MTA-STS and BIMI.

Step 4: set up your first service (DMARC)

This is normally the first tile you configure, since it's what unlocks aggregate reporting - the data that tells you what's actually sending mail as your domain.

1. From the domain's overview page, click Configure on the DMARC tile (or go directly to /dmarc and pick the domain).
2. Choose the hosted (recommended) option. DMARC Engine shows you the exact CNAME to publish:

Host:   _dmarc.example.com
Type:   CNAME
Value:  a1b2c3._dmarc.dmarcengine.com

1. Add that CNAME at your DNS provider, under the host shown (replace example.com with your actual domain; your provider may want just _dmarc as the host if it auto-appends the zone).
2. Save the change and allow a few minutes for propagation.
3. Back in the app, click Check record.

Once live, we serve the actual DMARC policy TXT content on your behalf from a1b2c3._dmarc.dmarcengine.com, and aggregate (RUA) reports mailbox providers send back are delivered to an address unique to your account - r-<your-token>@reports.dmarcengine.com - and processed automatically into Reports and Analytics. You choose the policy (none, quarantine, reject) and reporting options from the same builder page; changing your mind later just means updating settings in the app - you never touch DNS again for this record while it stays hosted.

If you'd rather self-manage DMARC: the builder also shows the equivalent record to publish directly, if you'd prefer not to delegate:

Host:  _dmarc.example.com
Type:  TXT
Value: v=DMARC1; p=none; rua=mailto:you@example.com; fo=1

With the manual route, you own that record going forward - any future change to policy or reporting addresses means editing the TXT yourself.

For the full detail on policy tags, ramp-up strategy, and reading aggregate reports, see the dedicated guide: Understanding DMARC policy and reports.

Step 5: set up SPF

1. From the domain overview, click Configure on the SPF tile, or go to /spf.
2. Add the sending sources you use (your mail provider, ESPs, ticketing/CRM systems, etc.) - the builder has a search-as-you-type list of common providers' SPF includes.
3. Choose hosted (recommended). Publish the single TXT record shown:

Host:  example.com
Type:  TXT
Value: v=spf1 include:a1b2c3.spf.dmarcengine.com ~all

1. Save at your DNS provider and click Check record in the app.

Behind that one include, we flatten all the sources you selected into a single resolved set and keep the served record under SPF's hard 10-DNS-lookup limit - even as you add more sending sources over time, or as your ESPs change their own SPF includes upstream. This is one of the more common SPF failure modes we exist to remove: exceeding 10 lookups causes receivers to treat the entire SPF check as a permanent error, regardless of whether the sending IP was actually authorised.

Manual alternative: publish your own v=spf1 … TXT record directly at the apex, listing every include yourself, and re-count your lookups by hand every time a source changes. Fine for a domain with one or two static senders; painful as soon as you add a fourth ESP.

Warning: A domain can only have one SPF record. If you already have a v=spf1 TXT published, publishing the hosted include alongside it (rather than replacing it) creates two competing SPF records, which most receivers treat as a hard fail for everyone. Replace, don't add.

See also: SPF flattening explained.

Step 6: set up DKIM

1. From the domain overview, click Configure on the DKIM tile, or go to /dkim.
2. Add a selector - either one your existing mail platform already issues (Google Workspace, Microsoft 365, and most ESPs give you a selector and key pair to publish), or generate a new keypair in the builder if you're setting up DKIM signing for the first time on a self-hosted MTA.
3. Choose hosted (recommended). Publish the CNAME shown for that selector:

Host:   selector1._domainkey.example.com
Type:   CNAME
Value:  selector1.a1b2c3._domainkey.dmarcengine.com

1. Save and click Check record.
2. Repeat for each additional selector you send with (most domains only need one active selector at a time, plus a second briefly during key rotation).

Manual alternative: publish the provider-issued public key directly as a TXT record at selector1._domainkey.example.com with a value like v=DKIM1; k=rsa; p=MIGfMA0.... This is the only option if your sending platform requires you to publish its exact key value rather than pointing a CNAME at it - check with your ESP first; most modern platforms (Google Workspace, Microsoft 365, SendGrid, etc.) are CNAME-friendly.

DKIM selectors and hosted DKIM key rotation are covered in more depth here: DKIM selectors and key rotation.

Step 7: set up MTA-STS and TLS-RPT

1. From the domain overview, click Configure on the MTA-STS tile, or go to /mta-sts.
2. Choose your enforcement mode (testing to start, then enforce once you've watched TLS-RPT reports for a while) and the domains covered by your policy.
3. Choose hosted (recommended). Three records are shown together - publish all three:

Host:   mta-sts.example.com
Type:   CNAME
Value:  mta-sts.dmarcengine.com

Host:   _mta-sts.example.com
Type:   CNAME
Value:  a1b2c3._mta-sts.dmarcengine.com

Host:   _smtp._tls.example.com
Type:   CNAME
Value:  a1b2c3._smtp._tls.dmarcengine.com

1. Save all three at your DNS provider and click Check record.

The first CNAME points browsers/mail servers fetching your policy file at https://mta-sts.example.com/.well-known/mta-sts.txt to our infrastructure, where the policy is served over our SSL-for-SaaS certificate for your hostname - you don't need to obtain or renew a TLS certificate yourself. The second is the _mta-sts TXT (served via CNAME) that carries the policy ID senders use to detect changes. The third sets up TLS-RPT so you receive reports about any TLS failures on inbound connections to your domain.

Manual alternative: host your own .well-known/mta-sts.txt policy file on a web server reachable at mta-sts.example.com over valid HTTPS, and publish the _mta-sts and _smtp._tls TXT records yourself. This means you're responsible for renewing that certificate and keeping the policy file's id in sync with the TXT record every time you change the policy.

Note: MTA-STS is about protecting inbound mail to your domain (forcing senders to use TLS to reach you) - it's a different direction of protection from DMARC/SPF/DKIM, which govern how receivers judge mail claiming to be from you.

Step 8: set up BIMI

1. Make sure DMARC is already at enforcement (p=quarantine or p=reject) - BIMI requires this, and the /bimi builder will tell you if it isn't yet.
2. From the domain overview, click Configure on the BIMI tile, or go directly to /bimi.
3. Upload your logo - we handle conversion to the required square SVG (Tiny PS profile) and, if your plan/CA path requires it, generation of the VMC-ready raster asset.
4. Choose hosted (recommended). Publish the CNAME for the selector shown (typically default):

Host:   default._bimi.example.com
Type:   CNAME
Value:  default.a1b2c3._bimi.dmarcengine.com

1. Save and click Check record.

Manual alternative: publish the BIMI TXT yourself, pointing l= at a logo SVG and, optionally, a= at a Verified Mark Certificate you've obtained from a CA - you're then responsible for hosting the logo file and renewing the VMC.

---

Choosing hosted vs manual, at a glance

You can mix and match per record type and even per domain - there's no requirement to be all-hosted or all-manual across your estate.

Tip: If you're not sure which to pick, start hosted. You can always switch a given record to manual later from its builder page - nothing about the hosted CNAME locks you in.

---

Verify it worked

After publishing any record - verification TXT, or any per-service CNAME/TXT - confirm it two ways:

1. In the app. On the domain's overview page, each tile shows a green "Live" state once its record resolves and validates; the Check record button on each builder re-runs that check on demand rather than waiting for the next scheduled poll.
2. Independently, at the DNS level. Use the in-app Lookup page (enter your domain, it checks DMARC/SPF/DKIM/MTA-STS/BIMI in one pass) or the public DNS Lookup tool for a check that doesn't depend on our app's own cache. From a terminal, you can also query directly, for example:

dig CNAME _dmarc.example.com +short
dig TXT example.com +short
dig CNAME selector1._domainkey.example.com +short

A correctly hosted DMARC record should show your CNAME resolving to <slug>._dmarc.dmarcengine.com, and a plain dig TXT _dmarc.example.com +short (which follows the CNAME) should return a v=DMARC1; … string - even though you never published a TXT record yourself.

Once the domain shows Verified and at least one service tile is green, check that reports are actually arriving by watching Reports over the next 24-48 hours - aggregate reports are typically sent daily by most large mailbox providers, so don't expect data within minutes of publishing DMARC.

---

Common problems and fixes

Verification keeps failing (Check verification returns not found)
- Confirm you added the record at the verification host shown in the app (_dmarcengine-verify.<domain>), not _dmarc.<domain> - they're different hosts unless you used Method B.
- Query it yourself: dig TXT _dmarcengine-verify.example.com +short. If nothing comes back, the record either hasn't propagated yet or was saved under the wrong host (a common mistake: your DNS provider auto-appends the zone, so entering _dmarcengine-verify.example.com as the host when the provider already appends .example.com produces _dmarcengine-verify.example.com.example.com).
- Wait out the previous record's TTL if you're replacing an old value at the same host.

A CNAME "isn't resolving" per the app, but dig shows it fine
- Check for a second, conflicting record at the same host - most commonly an old TXT record left at _dmarc.<domain> from a previous DMARC setup that's now competing with the new CNAME. A host can have a CNAME or other record types, never both (per DNS's rules) - some providers will silently reject the CNAME, others will let you create both and cause unpredictable resolution.
- Some DNS providers apply their own proxying/rewriting (e.g. Cloudflare's orange-cloud proxy) even to CNAME records meant purely for DNS resolution. Hosted-record CNAMEs must resolve as plain DNS (grey-clouded in Cloudflare's terms) - proxying a _dmarc, _domainkey, or similar record breaks it.
- Give it one full TTL cycle before assuming it's broken. If the host previously had any record (even an unrelated one) at that exact name, resolvers that cached the old answer will keep serving it until that record's TTL expires, independent of how quickly you published the new one. The app's own status check queries fresh, but your own dig from a machine that queried recently may be reading a local or ISP resolver's cache - try dig @1.1.1.1 … to bypass it.

Everything looks right in the app, but a specific mailbox provider still doesn't seem to trust the record
- Some large mailbox providers (particularly for BIMI, and occasionally for DMARC report submission) apply their own additional requirements - a VMC for BIMI, or a domain-verification step for RUF forensic reports - that sit on top of a technically valid DNS record. Check the provider-specific notes in the /bimi and /dmarc builders before assuming the record itself is at fault.
- Confirm you're checking the record at the organisational domain the mail actually claims to be from - a message signed and sent as news.example.com is evaluated against news.example.com's own DMARC record (or, if none exists, its organisational domain's), not against an unrelated sibling subdomain's.

SPF shows a permerror / "too many DNS lookups"
- This is exactly what hosted SPF flattening exists to prevent. If you're on manual SPF and seeing this, either move the record to hosted, or manually reduce your include: chain. Check current lookup count on the /lookup page or free tool.
- Confirm there's only one SPF (v=spf1) TXT record at the apex - two SPF records is a hard fail on most receivers, and looks superficially similar to a lookup-limit failure in some report summaries.

DMARC reports aren't arriving
- Give it 24-48 hours; most senders batch aggregate reports daily, some weekly.
- Confirm the domain shows Verified and the DMARC tile is green - reports can't route anywhere useful if the CNAME isn't resolving yet.
- Check Alerts for any ingestion warnings tied to the domain.

BIMI logo not showing in inbox
- Confirm DMARC is at p=quarantine or p=reject, not p=none - BIMI is intentionally gated on DMARC enforcement.
- Not every mailbox provider that supports BIMI requires a VMC, but several major ones do; check the /bimi builder for which of your target providers need one.
- Logo display can lag behind record publication by hours to a couple of days as inbox providers cache BIMI lookups.

MTA-STS shows "policy fetch failed"
- If hosted, this is almost always the mta-sts.<domain> CNAME missing or proxied - it needs to serve our certificate over plain HTTPS, so anything that intercepts or rewrites TLS on that hostname (a proxying CDN, a catch-all redirect) will break the fetch.
- If manual, check that your own certificate for mta-sts.<domain> is valid and that the policy file is reachable at exactly /.well-known/mta-sts.txt over HTTPS on port 443.

A domain won't move past "Partially protected"
- Open the domain overview and look at which tile is still amber/red - it lists the specific reason (record not found, record found but invalid, record found but pointing at the wrong slug, etc.) rather than requiring you to guess.

---

FAQ

Do I have to use the hosted CNAME, or can I just publish everything myself?
Manual is fully supported for every record type - see the "manual alternative" in each step above. Hosted just removes ongoing maintenance (SPF flattening as you add senders, DKIM key rotation, MTA-STS certificate renewal, and so on) in exchange for a single CNAME you set once.

Can I add a subdomain instead of my main domain?
Yes. Add it exactly as you'd add an apex domain from Domains. It gets its own status, slug, and per-service records, independent of any parent domain also in your account. Note that DMARC policy set at the organisational (apex) domain applies to subdomains by default unless the subdomain publishes its own DMARC record - so in many cases you only need DMARC hosted at the apex, and just SPF/DKIM at the subdomain level for a subdomain that sends its own mail.

What happens if I remove a domain from DMARC Engine?
Its hosting slug is retired and any CNAMEs still pointing at *.dmarcengine.com for that domain will stop resolving to useful content. Remove or repoint those DNS records before or immediately after deleting the domain to avoid a dangling CNAME.

Does adding a domain or publishing DMARC in monitor mode (p=none) affect my mail delivery?
No. p=none is purely observational - it asks receivers to report back on authentication results without instructing them to quarantine or reject anything. This is the recommended starting policy; see Understanding DMARC policy and reports for the ramp-up path to enforcement.

How is my hosting slug different from my rua/reporting token?
The slug identifies the domain in every hosted CNAME target (e.g. a1b2c3._dmarc.dmarcengine.com). The rua token identifies your account for the mailbox address aggregate reports are delivered to (r-<token>@reports.dmarcengine.com) and is shared across the domains in your account, whereas the slug is per-domain.

Can I bulk import domains that already have DMARC/SPF/DKIM published elsewhere?
Yes - import brings domains in at Pending regardless of their current DNS state; existing records aren't touched until you actively configure a service and choose hosted or manual. You can run each domain's overview through Lookup after import to see what's already live before deciding whether to switch it to hosted.

What's the difference between "Verified" and "Fully protected"?
Verified means we've confirmed you own the domain - a prerequisite for any hosted record to work at all. Fully protected means every service tile you've enabled for that domain has a valid, resolving record. A domain can be Verified for weeks while you work through DMARC, then SPF, then DKIM, before reaching Fully protected.

Do I need MTA-STS and BIMI, or just DMARC/SPF/DKIM?
DMARC, SPF, and DKIM are the core trio almost every domain needs for basic anti-spoofing protection and are where most customers start. MTA-STS and BIMI are valuable add-ons - MTA-STS hardens inbound transport security, BIMI adds brand logo display - but neither is required to get real protection and reporting value from the first three.

Where do I go if a record won't verify after following the troubleshooting steps?
Contact Support with the domain name and, if you have it, the output of a dig query against the relevant host - that's usually enough for us to spot a proxying or zone-configuration issue on our side of the investigation.

I manage dozens of client domains - is there a faster path than adding them one at a time?
Yes, use bulk import to create all the domain records at once, and domain groups to keep client portfolios separate in the UI. Each domain still needs its own DNS change made in its own zone (there's no way around that - DNS is inherently per-domain), but the app-side setup is a single CSV upload rather than dozens of "Add domain" clicks.

Can two people in my organisation work on the same domain at once?
Yes - anyone with access to your DMARC Engine account and the appropriate role can view and edit any domain in the account, including the ones added by a colleague. There's no per-domain ownership lock; domain groups are for organisation, not access control.

What happens to historical reports if I switch a record from hosted to manual, or back?
Nothing is lost. Report ingestion is tied to the RUA/RUF addresses configured for the domain (which persist across a hosted/manual switch unless you deliberately change them), not to whether the underlying record happens to be a CNAME or a directly published TXT at the time. Switching modes changes how the record is served, not where reports are delivered.

Is there a limit to how many domains I can add?
Limits are governed by your subscription plan rather than anything in this workflow - see your plan's details in-app, or reach out via Support if you're planning a large-scale rollout and want to confirm headroom before you start bulk importing.