Getting started with DMARC Engine

10 May 2026 · DMARC Engine · 40 min read

Welcome to DMARC Engine

If you are reading this, you have almost certainly just signed up, or you are weighing up whether to. Either way, this guide will take you from an empty account to a fully hosted email-authentication stack - DMARC, SPF, DKIM, MTA-STS/TLS-RPT and BIMI - running on your domain, with reports arriving in your inbox and dashboard, alerts wired up, and your teammates invited. It is long on purpose: rather than a two-minute quick-start that leaves you guessing at step six, this is the whole path, written so you can follow it top to bottom on day one, or jump to the section you need on day thirty.

Before we get into the mechanics, it is worth being precise about what DMARC Engine actually is, because it changes how you should think about every step that follows.

What "hosted" means, and why it matters

DMARC Engine is a hosted email-authentication platform. That is a specific technical choice, not marketing language, and it is the single idea that makes the rest of this guide make sense.

With a traditional DIY approach to DMARC, SPF, DKIM, MTA-STS and BIMI, you write the actual DNS record values yourself - a v=DMARC1 policy string, a v=spf1 mechanism list, a DKIM public key, and so on - and you are responsible for keeping them correct forever. SPF records rot as you add and remove mail senders. DKIM keys need periodic rotation for security hygiene. DMARC policy needs a slow, careful ramp from p=none to p=quarantine to p=reject, watched over report by report. Get any of it wrong and mail silently fails, or worse, silently succeeds when it shouldn't.

DMARC Engine takes a different approach: instead of publishing the record value yourself, you publish a single CNAME (or a TXT pointer, for SPF) that delegates the record to us. We then serve the live record content from our infrastructure and manage it on your behalf - flattening SPF automatically as you add senders, rotating DKIM keys, tightening DMARC enforcement as your reports show it is safe, keeping MTA-STS policy in sync with your provider, and serving BIMI logo assets in the format mailbox providers expect. Your DNS zone gets one tidy line per service; we do the ongoing work behind it.

Note: Every service below has a "self-managed" alternative - publishing the record's value directly at your own nameservers instead of delegating via CNAME. This guide focuses on the hosted path because it is what most customers use and because it is where DMARC Engine adds the most value (automatic SPF flattening, DKIM rotation, and so on). If you would rather self-manage a given record, the equivalent value is shown on each service's builder page in the app, and you publish that instead of the CNAME.

Five services, five delegation targets. Here is the full picture in one place before we walk through each one individually:

Two values do all the work in that table: your slug (a per-domain hosting identifier the app generates for you) and your token (your unique rua reporting token). You will meet both in the next section, and you will see them again on every builder page.

Tip: Keep this guide open in one tab and your DNS provider's control panel open in another. Every step below tells you exactly what to type into that second tab.

Who this guide is for

This guide assumes you can log in to your domain's DNS zone (at your registrar, or at Cloudflare, Route 53, GoDaddy, or wherever your nameservers live) and add or edit records there. You do not need to know anything about DMARC theory going in - we will explain enough as we go - but if you want the conceptual background on DMARC enforcement, alignment and reporting, our sibling guide on the enforcement journey covers it in depth and is worth reading in week two, once your first reports have arrived.

If you get stuck at any point, the troubleshooting guide and the in-app support page are both one click away.

---

Before you begin

A short checklist saves a lot of back-and-forth later. Gather these before you create your account:

1. Access to DNS. You need permission to add/edit records in the zone for the domain(s) you want to protect - either directly, or via a colleague or your DNS provider's support desk.
2. A list of everything that sends mail as your domain. Your own mail servers, Google Workspace or Microsoft 365, marketing tools (Mailchimp, HubSpot, SendGrid), helpdesk software (Zendesk, Intercom), CRM systems, invoicing tools, and anything else that sends "From: yourdomain.com". You do not need this list to be perfect on day one - the whole point of aggregate reports is to discover what you missed - but the more complete it is, the smoother your rollout.
3. A work email address for your DMARC Engine account, ideally one that several people can act on (a shared inbox or a distribution alias), since this account will end up owning security-sensitive DNS delegation for your domain.
4. Ten to fifteen minutes for the initial setup, plus a few minutes per service as each one activates (DNS propagation is not instant - more on that below).

Warning: Do not delete or replace an existing DMARC, SPF or DKIM record until you understand what it currently does. If you already have a working SPF record that includes several senders, note it down before you touch anything - you will want to make sure DMARC Engine's SPF builder accounts for every one of those senders, so no legitimate mail starts failing.

---

Step 1: Create your account

1. Go to app.dmarcengine.com and choose Sign up.
2. Enter your work email address, choose a strong password, and confirm.
3. Check your inbox for a verification email and click the confirmation link. If it hasn't arrived within a few minutes, check spam - a slightly ironic first hurdle for an anti-spoofing product, but mail systems everywhere are still catching up.
4. Once verified, you will land on the dashboard with no domains added yet.

Turn on two-factor authentication

Because your DMARC Engine account controls DNS delegation for your domain - effectively, who is and isn't allowed to send mail as you - it is a high-value target for account takeover. Two-factor authentication (2FA) is not mandatory, but you should treat it as step one, not an optional extra.

1. Open the account menu (top right) and choose Security settings.
2. Select Enable two-factor authentication.
3. Scan the QR code with an authenticator app (Google Authenticator, Authy, 1Password, or similar).
4. Enter the six-digit code the app generates to confirm the pairing.
5. Store the backup/recovery codes shown on screen somewhere safe - a password manager, not a sticky note. If you lose your authenticator device and have no recovery code, regaining access requires a manual identity check through support.

Tip: If your organisation has more than one person who might need account access, set up 2FA now and invite teammates later (covered near the end of this guide) rather than sharing one login and one authenticator between several people.

While you're in Security settings, it's also worth noting the IP allowlist option if your organisation works from a fixed set of office or VPN egress IPs - it's an extra layer, not a requirement, and can be added at any time, so don't let it block you from moving on to your first domain.

---

Step 2: Add your first domain

With an account and 2FA in place, the next step is telling DMARC Engine which domain you want to protect.

1. From the dashboard, go to Domains and click Add domain.
2. Type the domain exactly as it appears in your organisation's email addresses - for a company sending as @example.com, enter example.com, not www.example.com or a specific subdomain, unless that subdomain genuinely sends mail independently and needs its own policy.
3. Submit the form. DMARC Engine creates a domain record and, crucially, generates two values you will use repeatedly for the rest of this guide:
4. - A hosting slug - a short, unique identifier for this domain within DMARC Engine (referred to as <slug> throughout this guide and throughout the app's own instructions).
5. - A rua token - a unique identifier used in your DMARC reporting address (referred to as <token>).
6. You'll be prompted to verify ownership of the domain before any hosted service goes live. This is a deliberate security control: it stops someone from adding a domain they don't control and either receiving reports meant for someone else, or claiming hosted DNS services for a domain they don't own.

Verifying domain ownership

1. On the domain's page, find the Verification panel. It will show a TXT record to publish, in the form:

   Host:  _dmarcengine-verify.example.com
   Type:  TXT
   Value: dmarcengine-verify=<a long unique code>
   TTL:   Auto (or 300)
   

1. Log in to your DNS provider and add that exact TXT record to your zone.
2. Return to the app and click Check verification (or wait - most zones propagate within a few minutes, and the app also checks periodically in the background).
3. Once verified, the domain's status changes from Pending verification to Verified, and every hosted-service builder page for that domain becomes available.

Note: DNS propagation is not instantaneous. Most changes are visible within a few minutes, but TTL caching on resolvers around the world means it can occasionally take up to 24-48 hours for every resolver to catch up, particularly if the zone's previous TTL on that hostname was set high. If verification doesn't succeed immediately, wait 10-15 minutes and try again before assuming something is wrong.

Tip: Adding more than one domain? Repeat this step for each one - every domain gets its own slug, its own token, and its own independent set of five hosted services. There's a per-domain workflow throughout the rest of this guide; run through it once per domain you own.

For a deeper walk-through of this exact step with more screenshots and edge cases (subdomains, apex vs. www, multi-brand organisations), see adding your first domain.

---

Step 3: A guided tour of the dashboard

Before diving into DNS records, it's worth spending five minutes getting oriented. DMARC Engine's app is organised around one idea: each domain has five hosted services, each with its own builder page, plus shared views that work across all your domains.

The main navigation

The domains list

The Domains page is your home base. For each domain you'll see:

• Verification status - Pending or Verified.
• A five-icon service rollup - one icon each for DMARC, SPF, DKIM, MTA-STS and BIMI, coloured to show whether that service is Active (the CNAME is published and DMARC Engine is serving records), Pending (CNAME not yet detected), or Not configured (you haven't started that service's builder yet).
• A quick link into the domain's detail view, which is really just the same five builder pages filtered to that domain.

Get into the habit of using this page as your checklist - by the end of this guide, every domain you manage should show all five icons green.

The five builder pages

Each of /dmarc, /spf, /dkim, /mta-sts and /bimi follows the same pattern, which is worth internalising once so the rest of this guide reads as "the same steps, five times" rather than five unrelated flows:

1. Choose the domain (if you manage more than one) from the domain selector at the top.
2. The page shows you the exact DNS record to publish - hostname, type, and value, pre-filled with your slug and, for DMARC, your token.
3. A status indicator shows whether DMARC Engine currently sees that record published and correctly pointed at us: typically Not detected, Detected - propagating, or Active.
4. Underneath, service-specific configuration lives: DMARC's page has your policy and alignment settings; SPF's page has your list of approved senders; DKIM's page has your selectors and rotation history; MTA-STS's page has your enforcement mode; BIMI's page has your logo upload and VMC status.
5. A "self-managed" toggle or link shows the raw record value, for anyone who'd rather publish it directly instead of delegating via CNAME.

With that pattern understood, the rest of this guide is mostly mechanical: publish a record, wait for Active, repeat.

For the conceptual background on why delegation works this way - and what "hosted" buys you over the lifetime of the record, not just on day one - read delegating your DNS and hosted DMARC when you have a spare ten minutes. Neither is required to finish this guide, but both explain the "why" behind the "how."

---

Step 4: Delegate DMARC

DMARC is the anchor record - it tells receiving mail servers what to do when SPF and/or DKIM checks fail, and where to send reports about what happened. It's also the one that unlocks aggregate reporting, so it's the natural first service to set up.

1. Go to /dmarc and select your domain.
2. Copy the CNAME record shown on the page. It will look like this (with your actual slug substituted):

   Host:  _dmarc.example.com
   Type:  CNAME
   Value: acme7f2.dmarcengine.com
   TTL:   Auto (or 3600)
   

Note the naming convention: the hostname you publish is _dmarc.<domain> and it points to <slug>._dmarc.dmarcengine.com - the app will show you this fully expanded, but the underlying pattern is what you'll see repeated (with the service name shuffled around) for every other service too.

1. Log in to your DNS provider, open the zone for your domain, and add the record exactly as shown - same host, same type, same value. Do not add quotes, trailing dots, or a policy string of your own; the whole point of delegation is that DMARC Engine serves the actual v=DMARC1... content, not you.
2. If a _dmarc.example.com record already exists (a common scenario if you or a previous provider set up basic DMARC before), you must replace it rather than add a second one - DNS resolvers only expect a single record type per name in most configurations, and a duplicate _dmarc entry will confuse things. Delete the old TXT record for _dmarc.example.com and add the new CNAME in its place.
3. Save the change and return to the DMARC builder page in DMARC Engine.
4. While you're there, take a moment to set your starting policy. Almost everyone should start at p=none - monitoring only, no enforcement - regardless of ambition, because you want to see a full reporting cycle (at least a week, ideally two to four) before you tighten anything. The DMARC builder defaults new domains to p=none for exactly this reason.
5. Confirm your reporting address. This is generated for you automatically as r-<token>@reports.dmarcengine.com and is already wired into the record DMARC Engine serves - you don't need to add anything extra to your own mailbox to receive reports; they're captured, parsed and shown on the Analytics page automatically.

Verify it worked

1. On the DMARC builder page, the status indicator should move from Not detected to Detected - propagating within a few minutes of saving the DNS change, and to Active typically within 15 minutes to a few hours, depending on your zone's previous TTL on that hostname.
2. Independently, run a lookup against your own domain using the free Lookup tool - enter example.com and confirm it shows a live DMARC record with your intended policy.
3. From a terminal, you can also check directly:

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

The first command should return your slug's _dmarc.dmarcengine.com hostname; the second (which follows the CNAME automatically on most resolvers) should return a v=DMARC1; p=none; rua=mailto:r-<token>@reports.dmarcengine.com... style string.
4. Do not expect an aggregate report immediately - most mailbox providers batch and send DMARC aggregate reports once every 24 hours, so the first one typically appears in Analytics the following day, not the same afternoon.

Note: DMARC on its own does nothing to your mail flow while it's at p=none. It only starts recording data - receivers keep delivering mail as normal and simply tell you, via reports, whether each message passed or failed SPF/DKIM alignment. Enforcement (quarantine/reject) is a later, deliberate step, covered in the enforcement journey.

---

Step 5: Delegate SPF

SPF (Sender Policy Framework) lists which mail servers are allowed to send as your domain. It's the record most likely to already exist in some form, and the one most likely to be broken or close to broken, because every time someone in your organisation signs up for a new marketing or transactional email tool, it should be added to SPF - and in practice, often isn't.

1. Go to /spf and select your domain.
2. The page will show the TXT record to publish at your domain's apex:

   Host:  example.com
   Type:  TXT
   Value: v=spf1 include:acme7f2.spf.dmarcengine.com ~all
   TTL:   Auto (or 3600)
   

1. If you already have an SPF record, this replaces it - you cannot have two SPF (v=spf1) TXT records on the same hostname; RFC 7208 explicitly says a domain must publish exactly one, and having two causes an automatic permerror, which behaves like a fail for many receivers. Delete your existing v=spf1... TXT record and publish the one shown above instead.
2. Before you delete the old record, copy its contents somewhere safe. You'll want it for the next step.
3. Back on the SPF builder page, add every sender your organisation actually uses to the approved senders list - this is the step that replaces manually editing include: mechanisms yourself. Typical entries: your email platform (_spf.google.com for Google Workspace, spf.protection.outlook.com for Microsoft 365), your marketing platform, your helpdesk, your CRM, and any transactional mail service (SendGrid, Postmark, Mailgun, Amazon SES). Use the senders you noted from your old SPF record as your starting checklist, then add anything new you know about.
4. DMARC Engine automatically flattens this list - resolving every included domain's own SPF mechanisms down to IP ranges where needed - and keeps the total DNS lookup count under the RFC 7208 hard limit of 10. This is the main ongoing benefit of hosting SPF with us rather than managing an include: chain by hand: as you add senders over time, we keep the record valid instead of it silently breaking once you cross the lookup limit.
5. Save your sender list.

Warning: Don't guess at your sender list and call it done. An incomplete SPF list won't necessarily break mail immediately - DMARC can still pass on DKIM alignment alone - but it does mean genuine mail from an un-listed sender will fail SPF, and if that sender doesn't also sign with DKIM, mail from it may be rejected once you move DMARC to enforcement later. Cross-check your sender list again after your first week of aggregate reports (see Step 8) - the reports themselves are the best way to discover senders you forgot.

Verify it worked

1. On the SPF builder page, the status indicator should show Active once DMARC Engine detects your TXT record resolving through to the include: correctly.
2. Check directly:

   dig example.com TXT +short
   

Confirm exactly one v=spf1... string is returned, and that it references your slug's SPF hostname.
3. Use the Lookup tool to fetch and render your domain's SPF chain, including the flattened result - it will show you the effective IP ranges after following every include:, which is useful for a sanity check.
4. Send a test email from each sender on your list to a mailbox you control (Gmail is a convenient, free choice) and check the message headers for spf=pass. In Gmail, open the message, click the three-dot menu, choose Show original, and look for the Authentication-Results header.

---

Step 6: Delegate DKIM

DKIM (DomainKeys Identified Mail) cryptographically signs outgoing mail so receivers can verify it wasn't altered in transit and genuinely came from a server authorised to sign for your domain. Unlike DMARC and SPF, DKIM is set up per sending platform - each mail source that signs with DKIM uses its own selector (a short label identifying which key pair to use), so you'll typically repeat this step once per sender.

1. Go to /dkim and select your domain.
2. Add a new selector for the sending platform you're configuring (for example, google for Google Workspace, or s1 if your provider assigns a generic default). The builder will generate a key pair and show you the record to publish:

   Host:  google._domainkey.example.com
   Type:  CNAME
   Value: google.acme7f2._domainkey.dmarcengine.com
   TTL:   Auto (or 3600)
   

1. Publish that CNAME in your DNS zone.
2. Repeat for every platform that supports DKIM signing - most major providers (Google Workspace, Microsoft 365, SendGrid, Mailchimp) do, and most will separately ask you to "enable" or "turn on" DKIM signing in their own admin console once they detect the public key is published, so check your sending platform's own settings after the DNS record is live.

Tip: Selector naming matters only in that it must be unique per sender and match whatever your sending platform expects to find. Some platforms (Google Workspace in particular) generate their own selector name and DKIM value for you to publish - in that case, use their selector name when creating the entry in DMARC Engine's DKIM builder, so the hostname lines up with what they're actually signing with.

1. DMARC Engine manages key rotation for hosted DKIM selectors automatically, replacing the underlying key pair on a schedule without requiring you to touch DNS again - a meaningful security improvement over a DKIM key that sits unrotated for years, which is the default state for most DIY setups.

Verify it worked

1. On the DKIM builder page, each selector's status should read Active once DMARC Engine detects the CNAME resolving correctly.
2. Check directly:

   dig google._domainkey.example.com CNAME +short
   dig google._domainkey.example.com TXT +short
   

The second command should return a v=DKIM1; k=rsa; p=... public key string.
3. Send a real test email through the platform you just configured, to a Gmail (or similar) mailbox, and check Show original for dkim=pass in the Authentication-Results header, along with the matching selector (d=example.com; s=google, for instance).
4. If DKIM shows dkim=none after a sensible propagation window, double-check that you also enabled DKIM signing inside the sending platform's own admin settings - publishing the DNS record makes verification possible, but most platforms need a separate toggle turned on before they'll actually start signing with it.

---

Step 7: Delegate MTA-STS and TLS-RPT

MTA-STS (Mail Transfer Agent Strict Transport Security) is a different kind of protection from the other four services: rather than authenticating who sent a message, it enforces that mail to your domain is delivered over an encrypted, certificate-verified connection - preventing downgrade and interception attacks in transit. TLS-RPT is its reporting companion, telling you when a sending server couldn't establish a secure connection to you.

MTA-STS involves two records rather than one, plus a policy file (which DMARC Engine hosts for you, so you don't need to run your own web server for it - a common stumbling block with DIY MTA-STS).

1. Go to /mta-sts and select your domain.
2. Publish the first record - a CNAME that lets DMARC Engine serve your MTA-STS policy file over HTTPS at the well-known location receivers expect:

   Host:  mta-sts.example.com
   Type:  CNAME
   Value: mta-sts.dmarcengine.com
   TTL:   Auto (or 3600)
   

1. Publish the second record - a CNAME that delegates the MTA-STS policy discovery TXT record itself:

   Host:  _mta-sts.example.com
   Type:  CNAME
   Value: acme7f2._mta-sts.dmarcengine.com
   TTL:   Auto (or 3600)
   

1. Publish the third record - a CNAME for TLS-RPT, so failure reports come to us for parsing and display:

   Host:  _smtp._tls.example.com
   Type:  CNAME
   Value: acme7f2._smtp._tls.dmarcengine.com
   TTL:   Auto (or 3600)
   

1. Back on the MTA-STS builder page, choose your enforcement mode. As with DMARC, start in testing mode (the MTA-STS equivalent of monitor-only) rather than jumping straight to enforce - testing mode reports on TLS failures without ever refusing to deliver mail, giving you a safety net while you confirm every legitimate inbound mail server on your domain genuinely supports TLS.

Warning: MTA-STS in enforce mode can cause mail to be rejected or deferred if your domain's own inbound mail servers (the ones in your MX records) don't reliably support TLS 1.2+ with a valid, matching certificate. Don't move to enforce mode until you've reviewed at least a week of TLS-RPT reports with no unexpected failures.

Verify it worked

1. On the MTA-STS builder page, both the policy and reporting components should show Active once DMARC Engine detects all three CNAMEs.
2. Check directly:

   dig mta-sts.example.com CNAME +short
   dig _mta-sts.example.com CNAME +short
   dig _smtp._tls.example.com CNAME +short
   

1. Fetch the live policy file in a browser or with curl, to confirm it's being served correctly:

   curl https://mta-sts.example.com/.well-known/mta-sts.txt
   

You should see a plain-text policy beginning version: STSv1 with a mode: line matching what you selected in the builder.
4. Give it a few days, then check the Analytics page (or the MTA-STS builder page directly, which surfaces TLS-RPT summaries) for incoming TLS-RPT reports - these arrive daily from participating receivers, similar in cadence to DMARC aggregate reports.

---

Step 8: Delegate BIMI

BIMI (Brand Indicators for Message Identification) is the odd one out in that it's not primarily a security control - it's a reward for having one. Once your domain enforces DMARC at p=quarantine or p=reject (BIMI's prerequisite at most participating mailbox providers), you become eligible to display your logo next to your messages in supporting inboxes, which is both a trust signal to recipients and a small but real deliverability and brand benefit.

Because of that prerequisite, BIMI is usually the last of the five services you activate, not the first - it's included here for completeness and because there's no harm in setting up the DNS delegation early, but the logo won't actually display anywhere until your DMARC policy is enforcing.

1. Go to /bimi and select your domain.
2. Upload your logo as an SVG in the BIMI-required Tiny PS profile (the builder will validate the file and tell you if it doesn't meet the spec - common issues are embedded raster images, scripts, or the wrong SVG profile).
3. Choose a selector (commonly default, unless you have a reason to run more than one BIMI record) and publish the CNAME shown:

   Host:  default._bimi.example.com
   Type:  CNAME
   Value: default.acme7f2._bimi.dmarcengine.com
   TTL:   Auto (or 3600)
   

1. Some mailbox providers (notably Google) also require or reward a Verified Mark Certificate (VMC) - a certificate proving trademark ownership of the logo - before they'll display it, on top of the DMARC enforcement requirement. The BIMI builder page shows your current VMC status and links to the certificate authorities that issue them; a VMC is an optional paid add-on from those authorities, not something DMARC Engine can substitute for you, but we serve it alongside your logo once you have one.

Note: Don't be discouraged if your logo doesn't appear immediately in your own test messages even after the DNS is Active - BIMI display depends on the receiving mailbox provider's own support and rollout, on your DMARC policy being at enforcement, and (for some providers) on a VMC. Treat BIMI as a milestone you build towards over the enforcement journey, not a same-day win.

Verify it worked

1. On the BIMI builder page, the record status should show Active once the CNAME is detected, independent of whether the logo is actually displaying anywhere yet (that's gated by DMARC enforcement, as above).
2. Check directly:

   dig default._bimi.example.com CNAME +short
   dig default._bimi.example.com TXT +short
   

The second command should return a v=BIMI1; l=https://... string pointing at your hosted logo.
3. Once your DMARC policy is at p=quarantine or p=reject, send a test email to a BIMI-supporting mailbox (Yahoo Mail, Apple Mail, and some Gmail configurations are common test targets) and check whether your logo appears next to the sender name.

---

Step 9: Read your first aggregate report

Once DMARC is Active (Step 4) and at least a day has passed, head to Analytics. This is where the actual value of DMARC monitoring shows up - not the DNS record itself, but the visibility it buys you into every source sending mail as your domain, legitimate or not.

1. Select your domain from the selector at the top of the page.
2. The headline view is a pass/fail summary over a selectable date range (default is usually the last 7 days): total message volume seen across all reporting mailbox providers, and what proportion passed DMARC alignment (via SPF, DKIM, or both) versus failed.
3. Below that, a sending sources breakdown lists every IP address or sending infrastructure that sent mail as your domain during the period, with per-source pass/fail rates. This is the single most useful table on day one - it's where you'll spot:
4. - Legitimate senders you forgot to add to SPF or DKIM (showing as failing, but recognisably yours - a known marketing platform's IP range, for instance).
5. - Genuinely unauthorised senders - spoofing attempts, old ex-employee tools, or shadow-IT senders nobody remembers signing up for.
6. A geography view shows where reporting mail volume originates, useful for spotting spoofing campaigns concentrated in unexpected regions.
7. Drilling into any individual source shows the underlying aggregate report detail - SPF and DKIM alignment results, the envelope and header domains involved, and message counts - for anyone who wants to go one level deeper than the summary.

Tip: Your first report will very likely include failures. That is normal and expected - it does not mean anything is broken. It means DMARC is doing exactly its job: showing you, for the first time, everything that has always been sending mail as your domain. Work through the sending-sources list, add anything legitimate to SPF/DKIM (Steps 5 and 6), and re-check after a few more days of reporting.

Warning: Resist the urge to jump straight to p=reject because the first report looked mostly clean. A short reporting window can miss senders that only run monthly (an annual-renewal invoicing tool, a quarterly newsletter platform) - give it at least two to four weeks of reports, ideally across a full billing/reporting cycle, before tightening enforcement. The enforcement journey guide covers pacing this properly.

---

Step 10: Invite your teammates

DMARC is rarely a one-person job for long - IT, marketing (who own several sending platforms), and security all tend to have a stake. DMARC Engine supports multiple users per account with role-based permissions, so you don't have to share one login.

1. Open the account/organisation menu and choose Team (or Members, depending on where you are in the app).
2. Click Invite member.
3. Enter their email address and choose a role.
4. Send the invite. They'll receive an email with a link to set their own password (and, ideally, their own 2FA) rather than using yours.

Note: Exact role names and the precise permission matrix are configurable per organisation plan - check the Team page for your account's current set before assuming the table above is exhaustive. The pattern that holds everywhere: at least one role can view-only, which is the right fit for anyone who just needs to watch the Analytics dashboard (a marketing lead checking their platform isn't the one failing, for instance) without being able to change a live DNS delegation.

Tip: Give your marketing and IT contacts read-only or member access to Analytics early, even before you've finished delegating every service. The sending-sources breakdown is often the fastest way for them to self-diagnose "is my tool the one that's failing SPF" without a round trip through you.

---

Step 11: Set up your first alert

Reports are only useful if someone actually looks at them. Alerts close that gap by pushing notifications when something changes, rather than requiring anyone to remember to check the dashboard.

1. Go to Alerts and select your domain.
2. Click New alert (or Create alert rule).
3. Choose a trigger type. Common starting points:
4. - New sending source detected - fires when mail arrives claiming to be from your domain via an IP or infrastructure not seen before. This is your earliest warning for both "someone signed up for a new tool and forgot to tell you" and genuine spoofing attempts.
5. - Failure rate spike - fires when the proportion of failing mail jumps meaningfully above its recent baseline.
6. - Enforcement milestone reached - fires when a domain's DMARC policy changes tier (e.g., moves from none to quarantine), useful for teams that want a record of the ramp without watching it manually.
7. - Service delegation dropped - fires if a previously Active service (say, your MTA-STS CNAME) stops resolving correctly, which usually means someone changed DNS elsewhere and accidentally broke the delegation.
8. Choose delivery - typically email, with the option to route to a shared address or distribution list so the alert doesn't depend on one person's inbox.
9. Save the rule. It applies going forward; it does not retroactively notify you about historical data.

Tip: Set up "new sending source" and "service delegation dropped" alerts first - they are the two that catch problems before they become expensive (an unnoticed spoofing campaign, or a silently broken delegation after an unrelated DNS cleanup) rather than after.

---

Suggested plan: week 1, week 2, month 1

Here is a sensible pace for a typical single-domain rollout. Multi-domain organisations should run this same plan per domain, though domains sharing infrastructure (same mail platforms) will move faster on the second and subsequent domains.

Note: This plan assumes a single, moderately complex sending environment. If your organisation sends from a dozen platforms across several regional teams, stretch the week 1-2 phase longer - the aggregate-report review is the part that shouldn't be rushed, because it's the only thing standing between "safe enforcement" and "legitimate mail starts bouncing."

---

Common first-run problems

If none of these match what you're seeing, the troubleshooting guide goes deeper on DNS propagation edge cases, split-horizon DNS, and provider-specific quirks (Cloudflare proxying, GoDaddy's record-type restrictions, and so on). The in-app Lookup tool is also worth using liberally throughout - it shows exactly what a resolver sees for any domain, which is often faster than reasoning about it from your DNS provider's own control panel.

---

Frequently asked questions

Do I have to delegate via CNAME, or can I just publish the records myself?
Delegation is the default and recommended path, but every service has a self-managed alternative - each builder page shows the equivalent value to publish directly if you'd rather manage the record at your own nameservers. The trade-off is that self-managed records don't benefit from automatic SPF flattening, DKIM rotation, or MTA-STS/BIMI content updates - you take that maintenance back on yourself.

Will setting up DMARC break my email?
Not at p=none, which is where every new domain starts and where the DMARC builder defaults you. At p=none, DMARC only observes and reports; it never blocks or quarantines mail. Enforcement (p=quarantine/p=reject) is a deliberate later step you choose to take once reports show it's safe - see the enforcement journey.

How long until I see my first report?
DMARC's status typically goes Active within minutes to hours of publishing the CNAME, but the first aggregate report usually doesn't appear until the following day, because most mailbox providers batch and send DMARC reports on a roughly 24-hour cycle rather than in real time.

What's the difference between the slug and the token?
The slug is your domain's hosting identifier within DMARC Engine, used across all five service delegation targets (<slug>._dmarc..., <slug>.spf..., and so on). The token is specific to DMARC reporting - it forms your unique r-<token>@reports.dmarcengine.com address, ensuring aggregate reports sent by mailbox providers route back to the right account. You'll see both on your domain's builder pages; you never need to type either by hand, since the app fills them into every record shown to you.

Can I add more than one domain to one account?
Yes - add each domain from the Domains page and repeat verification and delegation per domain. Each domain gets its own slug, token, and independent set of five hosted services, and team members' roles typically apply account-wide, though check your plan's specifics on the Team page.

Do subdomains need their own DMARC record?
Not necessarily - DMARC policy at the organisational domain applies to subdomains by default unless a subdomain publishes its own _dmarc record (which takes precedence for that subdomain specifically). Whether you need a subdomain-specific policy depends on whether that subdomain sends mail with meaningfully different risk or senders than your main domain; adding your first domain covers this in more detail.

What happens if I forget a sender in SPF but it does sign with DKIM?
DMARC alignment only requires SPF or DKIM to pass (with matching alignment) - not both. So a sender missing from SPF but correctly configured with DKIM will still pass DMARC overall. That said, it's best practice to configure both where possible, since SPF still affects that individual mechanism's own pass/fail result and some receivers weight it independently.

Is BIMI worth setting up if I'm a small organisation?
It's low-cost once DMARC is enforcing (the CNAME delegation itself is simple, per Step 8), but the return depends on how many of your recipients use mailbox providers that display BIMI logos, and whether you're willing to pay for a VMC where required. Most organisations treat it as a nice-to-have milestone at the end of the enforcement journey rather than a day-one priority.

Can I self-manage some services and host others through DMARC Engine?
Yes - each of the five services is delegated independently, so it's entirely normal to, for example, host DMARC and SPF with us while self-managing DKIM if you have an existing key-rotation process you're attached to. The Domains page's five-icon rollup will simply show a mix of Active (delegated) and Not configured (self-managed elsewhere) per domain.

What if my DNS provider doesn't support CNAME records at a subdomain like _dmarc?
This is rare with modern DNS providers but does occasionally come up with older or more restrictive control panels. Some providers alias this as "CNAME flattening" or have restrictions on CNAMEs at reserved-looking hostnames. If you hit this, use the self-managed value shown on the relevant builder page instead, or raise a ticket with your DNS provider - nearly all mainstream providers (Cloudflare, Route 53, Google Domains successors, GoDaddy, Namecheap) support standard CNAMEs at underscore-prefixed hostnames without issue.

I made a mistake and deleted the wrong record - what now?
Re-publish it. Every builder page always shows the currently-correct value for its service, so you can re-copy the exact record at any time - there's no state you can get into by deleting a record that isn't fixed by simply publishing the right one again per the instructions on the relevant builder page.

Where do I go if this guide doesn't cover my situation?
Start with troubleshooting for DNS and propagation issues, the enforcement journey for anything about pacing DMARC policy changes, and delegating your DNS / hosted DMARC for the conceptual "why" behind the hosted model. For anything account-specific, support is staffed and ticketed, not just a help-article dead end.

---

Free tools, if you want to check before you commit

If you're reading this before creating an account - or if you want to check a domain you don't manage in DMARC Engine, such as a vendor or a domain you're evaluating for a security review - the free tools on the public site let you run one-off DMARC, SPF, DKIM, MTA-STS and BIMI lookups without signing up for anything. They're the same underlying lookup logic as the in-app Lookup tool, just without the account, the history, or the alerting - useful for a quick "what does this domain currently publish" check, less useful for ongoing monitoring of your own domain, which is what the rest of this guide has walked you through.

---

Where to go next

At this point you should have: an account with 2FA enabled, at least one verified domain, all five hosted services delegated (or well on the way to Active), a first look at your aggregate reports in Analytics, teammates invited with sensible roles, and at least one alert rule watching for new sending sources.

From here, the natural next reads are:

• The enforcement journey - how to move from p=none to p=reject safely, at a pace your reports justify.
• Delegating your DNS - the deeper technical picture of what CNAME delegation buys you over the life of the record, not just at setup.
• Hosted DMARC - the case for hosted vs. DIY, if you want the fuller argument behind Step 0 of this guide.
• Troubleshooting - keep this bookmarked; DNS issues have a way of resurfacing months later when something unrelated changes in your zone.

Welcome aboard - the hardest part, in most rollouts, really is just the first CNAME. Everything after that is patience and reading reports.