Knowledge base

DMARC Engine is a hosted subscription: you pay for the platform that monitors your domains and manages your DMARC, SPF, DKIM, MTA-STS and BIMI records, with optional done-for-you enforcement on top. There's no single flat fee. What you pay depends on how many domains you protect and which capabilities you need. For current figures, see our pricing page.

In broad terms, the model has two parts:

• Hosted plans scale with the number of domains you manage and the depth of features: aggregate (RUA) and forensic report processing, hosted records, MTA-STS and TLS-RPT, BIMI support, alerting and team access. SMBs protecting one domain pay considerably less than an MSP managing many.
• Done-for-you enforcement is an optional service where our team drives you safely from p=none through quarantine to p=reject without breaking legitimate mail. This suits teams that want the outcome without doing the analysis themselves.

You can start for free with our DMARC checker and SPF checker to see where you stand before committing to a plan.

Next steps

Check the pricing page for live plan details, or run a free DMARC check to scope what you'll actually need.

Yes. You can see exactly where your domain stands before you commit to anything, and our public diagnostic tools are free to use with no account required.

Start with the DMARC checker, SPF checker and DKIM lookup. They parse your live DNS records, flag syntax errors, surface the SPF 10 DNS-lookup limit, and tell you whether your DMARC policy is at p=none, p=quarantine or p=reject. That alone gives you an honest, qualitative picture of your current posture, with no sign-up and no card.

When you're ready to go further, onboarding is guided rather than locked behind a long contract. You connect a domain, we ingest your real RUA aggregate reports, and you see your sending sources and pass/fail rates before any policy changes are made. Getting to enforcement is a staged journey (see the enforcement journey), so you stay in control the whole way.

For current pricing and plan details, see our pricing page or get in touch. The simplest first step costs nothing: run a free scan and read what your records are actually doing today.

Yes. Your account is free to sign up for and self-serve, so you can start using DMARC Engine without any payment. If you have a paid arrangement (for example enforcement or hosted monitoring), you can change or cancel it at any time by contacting our team. There is no lock-in.

Changing your plan

Signup is free and the account is fully usable without payment, so most changes do not need anything from you. For a paid arrangement, plan changes are handled by our team rather than through a self-service billing portal:

• To upgrade or add coverage, contact us and we will arrange the change so you get more domains, reports and features.
• To downgrade or cancel, contact us and we will sort out the change with you directly.

The Billing tab in your dashboard is a read-only view of your invoices, so you can always see what has been arranged. If you are unsure which arrangement fits, our team is happy to advise before you commit. See support response times.

What happens to your hosted records

This is the important bit if you use our hosted DNS for DMARC, SPF, DKIM, MTA-STS or BIMI.

Because hosted records are published via CNAME delegation, they keep resolving as long as the delegation stays in place. If you cancel, we give you notice and your published values so you can either point the records at your own DNS or keep them flattened in-zone, with no surprise drop to an unauthenticated state that could break legitimate mail.

Always confirm your new records resolve correctly before removing the delegation, especially if you are at p=reject.

Next steps

To change or cancel a paid arrangement, just contact our team. You can also check the enforcement journey to be sure your coverage matches where you are headed.

Free tools tell you what's wrong; DMARC Engine fixes it and keeps it fixed. A checker or one-off report shows you a snapshot (the verdict that your DMARC, SPF or DKIM is failing) but stops there, leaving you to interpret raw XML, edit DNS by hand and hope nothing breaks.

DMARC Engine takes you the rest of the way:

• Hosted records. We host your DMARC, SPF, DKIM, MTA-STS and BIMI behind a single delegated record, so changes go live without you touching production DNS each time.
• Guided enforcement. We read your aggregate (RUA) data, identify every legitimate sender and walk you from p=none to p=reject without dropping real mail. See the enforcement journey.
• Done-for-you. Prefer not to do it yourself? We can run the whole ramp on your behalf.
• Multi-domain aggregation. All your domains and parked domains in one dashboard, not a separate report per domain.
• Alerting. We watch for authentication drift, new senders, SPF lookup-limit breaches and expiring DKIM keys, and tell you, rather than you discovering it weeks later.

Start with the free DMARC checker, then let DMARC Engine host and enforce it for good.

Yes, DMARC Engine is built for teams. You can invite colleagues to your account and give each person the right level of access, so your security lead, IT admin and external MSP all work from the same place without sharing a single login.

We support three role-based access levels:

• Admin, full control: invite or remove users, change billing, add or delete domains, and edit DNS, enforcement and DKIM rotation settings.
• Editor: can make day-to-day changes such as adjusting policies, working through the enforcement journey and acting on alerts, but cannot manage billing or other users.
• Viewer: read-only access to dashboards, DMARC reports and compliance status. Ideal for auditors, stakeholders or compliance leads who need visibility without the ability to change anything.

To invite someone, open Settings → Team, enter their email and pick a role. They receive an email invitation and set their own password, so credentials are never shared. You can change a member's role or revoke access at any time.

If you manage email authentication for several clients as an MSP, this lets you grant scoped access per organisation. See also managing multiple domains.

Next steps

Add your colleagues under Settings → Team and assign roles based on what each person needs to do.

We work with managed service providers and resellers on a partner basis. DMARC Engine is built to run email authentication across many client domains, and white-label branding plus consolidated billing and reporting are arranged with our team as a service arrangement rather than a self-serve product.

As a partner, you manage each client's DMARC, SPF, DKIM, MTA-STS and BIMI records and drive every domain to p=reject on its own timeline. Notification channels (Email, Slack, generic HTTPS Webhook and PagerDuty) can be configured so you hear about authentication failures or pending DNS changes before your clients do.

White-labelling, where customer-facing reports and notifications carry your name rather than ours, is set up with us as part of the partner arrangement, so enforcement looks like part of your service rather than a third-party add-on. Onboarding and bulk domain additions are handled with the team as your book of business grows.

To discuss partner pricing, consolidated billing and reporting, and how white-label branding works for your clients, see the MSP and partner page. If you are weighing it up, the hosted DMARC overview and the enforcement journey explain how each client reaches reject safely.

Next steps: review the MSP page, then get in touch to set up your partner arrangement and add your first client domains.

In short: your data is hosted on Cloudflare's global edge infrastructure, encrypted in transit and at rest, and we deliberately store as little of it as possible.

DMARC Engine is built on Cloudflare Workers and Cloudflare's managed storage, so your account runs across a distributed, security-hardened network rather than a single server you have to trust. All traffic to and from the platform travels over TLS, and stored data, including any credentials needed to manage your hosted DNS, is encrypted at rest.

Just as important is what we hold. The platform deals primarily in email-authentication metadata: aggregate (RUA) report data such as sending IPs, alignment results and policy outcomes. We aren't a mailbox provider and we don't sit in your mail flow, so we don't read, store or relay the contents of your emails (see do you store my email?).

This data-minimising posture keeps your exposure small by design and supports our wider compliance approach. See GDPR compliance for detail.

Next steps

Want the specifics for your own setup? Start with a free DMARC checker scan, or review how hosted DMARC manages records on your behalf.

In most cases your first aggregate (RUA) reports arrive within about 24-72 hours of publishing a rua address in your DMARC record and sending real mail.

Aggregate reports are generated by receiving mailbox providers (Google, Microsoft, Yahoo and others) on their own schedule, almost always once per day per source. Because each provider batches and sends on its own clock, reports trickle in at different times rather than all at once, so the first day or two can look sparse.

A few things to expect early on:

• It needs traffic. Reports only cover mail your domain actually sent to a given provider. Low-volume or dormant domains will see fewer, slower reports.
• Coverage grows over time. Expect the most active senders (your mail platform, marketing tools) to appear first, with the long tail of sources filling in over the following days and weeks.
• Volume is normal at first. Reports are XML and not meant to be read by hand. Hosted DMARC parses them into a clear sources view so you can see what is passing, failing and where.

If nothing arrives after 72 hours, double-check the published record with the DMARC checker. A typo in the rua tag is the usual culprit.

Next step: publish your record, then watch the dashboard populate before you begin the enforcement journey toward p=reject.

DMARC Engine is a done-for-you hosted platform for email authentication. It manages the full stack that proves your mail is really from you: DMARC, SPF, DKIM, MTA-STS and BIMI. Instead of leaving you to hand-edit DNS records, decipher cryptic aggregate reports and hope nothing breaks, we host those records on Cloudflare's network and walk your domain through a safe, staged rollout. The goal is concrete: get you from p=none (monitoring only, no protection) to p=reject (spoofed mail is rejected at the recipient's server) without a single legitimate message going missing along the way. You delegate a few records to us once, and from then on we maintain them, watch the incoming reports and tell you exactly when it is safe to tighten policy.

The "done-for-you" part is the point. Getting to p=reject by hand is genuinely fiddly. SPF has a hard limit of ten DNS lookups that large senders blow through; DKIM keys need rotating; a careless p=reject published too early will silently bin your invoices, newsletters and password resets. DMARC Engine handles the awkward bits for you: it flattens and keeps your SPF record under the lookup limit, manages DKIM selectors and rotation, hosts MTA-STS and TLS reporting so mail is delivered over enforced TLS, and serves your BIMI record and logo so your brand mark can show in supporting inboxes. Most importantly, it ingests the RUA aggregate reports mailbox providers send back, identifies every service sending on your behalf (your CRM, helpdesk, finance tool, marketing platform and so on), and only recommends moving to quarantine or reject once those sources are authenticated and passing. You get emailed monitoring so you are told about a new sending source or an authentication failure rather than discovering it when a customer complains.

Who is it for? Any organisation that sends email from its own domain and wants to stop others spoofing it. That includes:

• Small businesses and agencies that send from Google Workspace or Microsoft 365 and want protection without hiring a deliverability specialist.
• E-commerce, SaaS and finance teams whose transactional mail (receipts, alerts, resets) must land reliably and must not be impersonated in phishing attacks.
• IT and security teams who need to satisfy supplier security questionnaires, cyber-insurance requirements or the bulk-sender rules now enforced by Google and Yahoo, which require a valid DMARC policy.
• Anyone who has tried to set up DMARC themselves, got stuck at the report stage, and has been parked at p=none for months without ever reaching enforcement.

If you just want to check where you stand today, you do not need an account. The free diagnostic tools will tell you in seconds what is published and what is missing: the DMARC checker, SPF checker, DKIM checker, MTA-STS checker and BIMI checker, plus a DMARC report analyzer for reading aggregate files you already receive. When you are ready for someone to actually run the rollout for you, that is what the hosted products and the dashboard at app.dmarcengine.com do. For a plain-language primer on the standards themselves, see the glossary and the requirements overview.

No, you do not need to be a technical person to use DMARC Engine. The honest exception is one initial step: you (or whoever has access to your domain's DNS) need to add a single delegation record so we can manage authentication on your behalf. That is the only piece that touches your DNS by hand. Everything that normally makes DMARC hard, the records, the gradual policy changes, the report parsing, is handled by the platform after that.

Here is the part that puts people off DMARC: getting it right usually means writing and maintaining several fiddly DNS records (a DMARC TXT record, an SPF record kept under the 10-lookup limit, DKIM keys, an MTA-STS policy, a BIMI record), and then nudging the policy from p=none to p=quarantine to p=reject without accidentally blocking your own legitimate email. Each of those has its own syntax and its own ways to go wrong. DMARC Engine takes that whole job off you. Once delegation is in place, we publish and update the records for you, watch the incoming reports, and only move your enforcement policy forward when the data shows your real sending sources are aligned and passing.

So what do you actually do, and what is automated? In plain terms:

• You do, once: add the delegation record we give you at your DNS host (a copy-paste CNAME or NS entry, with step-by-step instructions for common providers like Cloudflare, GoDaddy, Namecheap and Google Domains). If you would rather not touch DNS at all, you can forward the instructions to your IT person or web host and they will be done in a few minutes.
• You do, ongoing: read the plain-English summaries we email you, and tell us about any new sending service you add (for example a new newsletter tool or invoicing system) so we can make sure it is authenticated. Most months that is nothing at all.
• We automate: generating and publishing every record, keeping SPF flattened and within limits, rotating and serving DKIM keys, hosting your MTA-STS and BIMI policies, collecting and decoding the raw XML aggregate reports, and stepping your policy safely towards p=reject at a pace your domain can handle.

The deliberate goal is no email outage. We do not flip you to enforcement on day one and hope for the best; we sit at monitoring first, confirm in the reports that your genuine mail (your mailbox provider, your marketing platform, your CRM, and so on) is passing, then tighten. If something looks off, we hold and tell you in language you can act on, rather than handing you a wall of jargon.

If you want to get a feel for the moving parts before signing up, or you simply want to check where your domain stands today, the free diagnostic tools need no account and no delegation: try the DMARC checker, the SPF checker, the DKIM checker, the MTA-STS checker and the BIMI checker. If you already receive DMARC reports and want them made readable, the DMARC report analyzer turns the raw XML into something human. There is also a short, jargon-free glossary if a term trips you up. The short version: you handle one DNS step at the start, we handle the email authentication from then on.

No, not when you do it in the right order with evidence to back each step. DMARC itself does not block or reject anything at p=none. That policy means "publish a record, ask receivers to send me reports, but take no action on mail that fails". Your email keeps flowing exactly as it does today. The reports are the whole point: they show you every source sending on your behalf, which of those pass SPF and DKIM with proper alignment, and which do not. Until you have read that evidence and fixed your legitimate senders, you simply do not move to an enforcing policy. The thing that breaks email is jumping straight to p=reject blind, before you know what is actually sending as your domain. A staged path exists precisely so that never has to happen.

The safe sequence is monitor, then quarantine a slice, then full enforcement. You start at p=none and collect aggregate (RUA) reports for two to four weeks, long enough to capture monthly senders like payroll, invoicing or marketing batches. You read those reports to build a complete picture of your sending sources, then bring each legitimate one into alignment: add it to SPF, set up DKIM signing, and confirm the authenticated domain matches your From domain. Only once your real mail is passing do you tighten the policy, and even then you do it gradually. Our DMARC report analyzer turns the raw XML into a plain readout of who is sending and whether they pass, so you are never guessing.

A few specific safeguards stop an outage:

• pct ramping. You can apply enforcement to a percentage of mail first, for example p=quarantine; pct=10, then 25, 50 and 100. A misconfiguration shows up on a small slice, not your whole flow, and you raise the percentage only when reports stay clean.
• Quarantine before reject. Failing mail at p=quarantine lands in spam rather than vanishing. It is recoverable and visible, which is a far gentler checkpoint than rejection, so you reach p=reject having already proven nothing legitimate is failing.
• Alignment fixes, not blanket blocking. DMARC only ever affects mail that fails both SPF and DKIM alignment. Properly authenticated mail is unaffected by the policy, so the work is about getting your senders passing, not about cutting anything off.
• Continuous report monitoring. New senders, expired DKIM keys or a changed SPF record surface in the next reports, and we email you when something starts failing, so you react before users notice.

The honest caveat: the risk is not DMARC, it is an unknown or unauthenticated legitimate sender that you enforce against before fixing it. That is exactly what the monitoring phase is designed to surface, and why we never recommend rushing it. The platform handles the staging, the record edits and the watching for you, and keeps you at each step until the evidence says it is safe to advance. If you want to see your current position before changing anything, run a free DMARC check and an SPF check; they read your existing DNS without touching it. For the full walkthrough of the journey, see our requirements guide. Done in this order, with reports leading every decision, reaching p=reject is a controlled process, not a gamble with your inbound or outbound mail.

There is no fixed number of days, because the timeline is driven by your email estate rather than the calendar. For a simple domain that sends only through one or two well-behaved providers (say Google Workspace or Microsoft 365 plus one marketing tool), reaching p=reject typically takes a few weeks: roughly two to six. For a sprawling estate with many sending sources, regional offices, acquired brands, legacy applications and third parties you have lost track of, expect a few months, and occasionally longer. The work itself is not slow; the waiting is. You publish p=none, then watch real DMARC reports accumulate so you can see every system that sends as your domain before you start blocking anything.

What actually drives the duration is discovery and authentication, not policy changes. The honest sequence looks like this:

• Source discovery. You need at least a couple of weeks of aggregate reports at p=none to surface every legitimate sender, including the once-a-quarter invoicing system and the helpdesk that nobody mentioned. Low-volume senders can take a full reporting cycle or two to appear at all.
• Fixing alignment. Each sender must pass SPF or, preferably, DKIM with the result aligned to your visible From domain. Some third parties make this a five-minute DNS change; others require a support ticket, a CNAME they generate, or a plan upgrade, and that is where weeks disappear.
• Estate complexity. Number of sending services, number of subdomains, how many teams must coordinate, and how cooperative each vendor is. SPF's ten-lookup limit can force you to flatten records or restructure, which adds time.
• Staged enforcement. Moving through p=quarantine with pct ramped from a small percentage upward, watching for collateral damage at each step before you commit to full p=reject.

Rushing is the one genuinely risky part, and it is risky in a specific, irreversible way: if you publish p=reject while a legitimate sender is still unauthenticated or misaligned, receiving mailboxes will silently reject that mail. There is no bounce you will notice in time and no undo for messages already discarded. That can mean missed invoices, password resets that never arrive, or a whole department's mail vanishing, and you often only find out when a customer complains. This is why the safe path is deliberately patient: prove every source authenticates, watch the reports stay clean across a full cycle, then enforce. A clean run of reports is worth far more than a fast one.

The practical takeaway is to optimise for correctness, not speed. Start by publishing a monitoring-only record today so the clock on discovery begins, then resolve senders in parallel rather than one at a time. With DMARC Engine the monitoring, source discovery and report parsing are done for you, and the platform recommends each enforcement step only once the data supports it, so you are never guessing when it is safe to advance. If you want to understand the destination before you start, read the journey from p=none to p=reject and check your current published policy with the DMARC checker. The estates that reach p=reject fastest are not the ones that hurried; they are the ones that found every sender early and fixed alignment without leaving anything behind.

No. DMARC Engine does not read, receive, store or have any access to the contents of your actual emails. The way email authentication works, it never needs to. DMARC, SPF and DKIM all operate on your domain's DNS records and on metadata about how messages were authenticated, not on the messages themselves. We publish and manage DNS records on your behalf (your SPF policy, your DKIM keys, your DMARC, MTA-STS and BIMI records) and we process the aggregate reports that receiving mail servers send back. At no point does your normal mail flow pass through us, and we are not in the delivery path for the email you send or receive.

It helps to understand what an aggregate (RUA) report actually contains, because that is the only email-related data we handle. When a domain such as Google, Microsoft or Yahoo receives a message claiming to be from your domain, it checks SPF and DKIM, applies your DMARC policy, and then once a day sends you a summary in XML. That summary is statistical: it lists sending IP addresses, the volume of messages seen from each, the envelope and header domains, and the pass or fail results for SPF, DKIM and DMARC alignment. That is it. An aggregate report tells us "200 messages claiming to be from your-domain.com came from IP 203.0.113.10 yesterday, and 198 passed DKIM." It does not, and cannot, tell us who the email was sent to, what the subject line was, what the body said, who the real sender was, or whether the message was legitimate marketing or a phishing attempt. The DMARC standard deliberately excludes all of that from aggregate reports.

There is a separate, optional report type called a forensic or failure (RUF) report, and this is the one people worry about because it can include redacted message headers and sometimes a portion of a failing message. To be clear about our position: aggregate reporting is what drives the platform and what we rely on to move you safely from p=none to p=reject. We do not require RUF reports to do our job, very few large mailbox providers send them anyway (Google and Microsoft do not), and where they exist they are heavily redacted by the reporter, not by us. If your plan or configuration involves any failure reporting, we treat those headers as sensitive and you remain in control of whether they are collected at all.

To summarise what we do and do not touch:

• We manage: your DNS records for DMARC, SPF, DKIM, MTA-STS and BIMI, and the per-domain settings in your dashboard at app.dmarcengine.com.
• We process: aggregate (RUA) XML reports, which contain sending IPs, message counts and authentication pass/fail results only.
• We never see: message bodies, subject lines, recipients, attachments or your mailbox contents, because none of that is ever sent to us.
• We are not: an inbound or outbound mail server, a relay, or a proxy in your email path.

If you want to verify any of this for yourself before trusting us with a domain, every check we run is also available as a free, no-login diagnostic. You can inspect exactly what is published in your DNS using the DMARC checker, the SPF checker and the DKIM checker, and you can paste a real aggregate report into the DMARC report analyzer to see precisely what one contains. For more on how reporting and alignment work end to end, see the glossary and requirements pages. The short version: your email content stays between you and your mailbox provider, and we only ever work with DNS and the anonymous, aggregated authentication metadata that keeps spoofers out of your domain.

Every email provider, without exception. This is the part that surprises people, so it is worth explaining why. DMARC, SPF, DKIM, MTA-STS and BIMI are not features of your mailbox or your sending platform: they are records that live in your domain's DNS. When a receiving server (Gmail, Outlook, Yahoo and the rest) decides whether to trust a message from your domain, it looks up those records in DNS and checks the message against them. We manage that DNS-side policy. Your provider keeps doing exactly what it does today, which is sending and receiving your actual email. The two layers sit side by side and never compete, so there is nothing on your provider's end to switch, migrate or break.

In practice that means the big mailbox hosts and every sending platform we have seen are covered. That includes Google Workspace and Microsoft 365 for your day-to-day staff mail, and the long list of services that send on your behalf: SendGrid, Mailchimp, Amazon SES, Postmark, Brevo (formerly Sendinblue), Klaviyo, HubSpot, Salesforce, Zendesk, Intercom, Zoho, Mailgun, ActiveCampaign, your CRM, your billing system, your help desk and your marketing automation. Most domains send through five to fifteen of these without anyone realising it. Our job during onboarding is to find all of them by reading your real DMARC reports, then make sure each one is correctly authorised in SPF and signing with DKIM, so that nothing legitimate gets caught when we tighten your policy.

You keep your current provider, full stop. We do not ask you to move mailboxes, change your MX records, route mail through us, or hand over your sending platform. Concretely, here is what stays with you and what we handle:

• Your mailboxes and MX: untouched. Google Workspace or Microsoft 365 stays exactly where it is, and inbound mail keeps flowing through your existing MX records.
• Your sending platforms: untouched. Your ESPs and apps carry on sending; we just make sure each one is authenticated so it passes DMARC.
• The DNS authentication layer: this is the part we look after, either by hosting delegated records for you or by handing you the exact records to publish, then monitoring them.

The only thing we genuinely need is the ability to manage the relevant DNS records for your domain, because that is where authentication is enforced. If a new tool joins your stack later, for example you adopt a new newsletter platform or a fresh invoicing service, it shows up in your monitoring and we authorise it before it can cause a failure. You can confirm any of this yourself right now without signing up: run your domain through the free DMARC checker, SPF checker and DKIM checker to see the current DNS-side picture, and read the requirements for what Google and Microsoft now expect from senders. If you would like the full walkthrough of how we take a domain from p=none to p=reject safely, see our managed DMARC product.

Yes. DMARC Engine is built for managing many domains and their subdomains from one account, whether you have a single brand or a portfolio of dozens. Every domain you add gets its own protection profile: its DMARC policy, SPF record, DKIM keys, MTA-STS policy and BIMI logo are tracked and managed separately, so a change to one domain never silently affects another. You add a domain in the dashboard at app.dmarcengine.com, verify ownership with a DNS TXT record, and from there each domain has its own dashboard view, its own report inbox and its own progression from p=none towards p=reject. If you are not sure where a given domain currently stands, you can run a free DMARC checker on it first, no account needed.

For larger portfolios, domains can be organised into groups so you are not scrolling through a flat list. Group domains however suits you: by client (useful for agencies and MSPs), by business unit, by sending platform or by environment. Each domain shows its current policy, alignment health and whether new reports have arrived, so you can scan the whole estate at a glance and drill into the ones that need attention. The per-domain monitoring emails mean you do not have to log in daily; you get told when something changes, such as a new sending source appearing or alignment dropping, on a per-domain basis so alerts stay relevant to the right team.

Subdomains are handled deliberately, because this is where a lot of DMARC rollouts go wrong. DMARC has an explicit subdomain policy tag, sp=, which controls what happens to mail from subdomains independently of the top-level domain's p= policy. This matters because subdomains inherit your organisational DMARC record unless they publish their own, so a strict p=reject on the parent can quietly block mail from a forgotten subdomain (or, conversely, an attacker can abuse an unprotected subdomain). DMARC Engine lets you set sp= to match your appetite, and you can also add an individual subdomain as its own managed domain when it has genuinely different senders, for example a marketing platform on news.example.com or a ticketing system on support.example.com. A common, safe pattern is:

• Keep the parent domain progressing on its own schedule from monitoring to enforcement.
• Set sp=reject early on parent domains that never legitimately send from subdomains, to shut down a frequent spoofing route.
• Add high-volume or third-party subdomains as separate managed entries so their SPF, DKIM and reports are tracked in isolation.

Because the platform is hosted, scaling to many domains does not mean managing many raw DNS records by hand. You delegate the relevant records once per domain (we provide the exact CNAME or NS targets), and after that we publish and update policies on the hosted side, so tightening a policy across your estate is a dashboard action rather than a DNS ticket each time. The free diagnostic tools, including the SPF checker, DKIM checker and MTA-STS checker, work on any domain whether or not it is in your account, which is handy when auditing a new portfolio before onboarding it. For more on rollout sequencing across multiple domains, see the requirements guide and our products overview.

Yes, absolutely. Keeping your current email provider is the whole point of how DMARC Engine works, and nothing about how you send or receive mail changes. We are a DNS-based service: we do not host your mailboxes, we do not relay or proxy your outbound mail, and we never sit in the path of a message. If you use Google Workspace, Microsoft 365, Zoho, Fastmail, an on-premise Exchange server, or any combination of these, you carry on exactly as before. Your MX records stay pointed at your provider, your users keep the same login, and your inbound and outbound mail flows are untouched.

What we actually configure lives entirely in DNS, in the form of TXT and CNAME records that authenticating receivers (Gmail, Outlook, Yahoo and the rest) read when they evaluate your mail. The DMARC record tells those receivers what policy to apply and where to send aggregate reports. SPF lists which servers are allowed to send for your domain, and DKIM publishes the public keys your provider uses to sign messages. None of these records intercept mail; they are published facts that receiving servers look up. Because of this, you can use as many sending services as you like alongside your main mailbox provider: a marketing platform, a CRM, a help-desk, a billing system, an invoicing tool. The job is to make sure every legitimate sender is correctly aligned and authorised, and that is precisely what taking you from p=none to p=reject does, safely and without blocking your own mail.

A few practical points worth knowing:

• You keep your own DNS, or delegate selectively. You can apply our recommended records yourself at your registrar, or use our hosted delegation for the DMARC, MTA-STS and BIMI records via a CNAME so changes propagate without you touching the zone each time. Either way, your authoritative DNS and your mail provider are unaffected.
• DKIM signing stays with your provider. We do not sign your mail. Your provider continues to sign with its own keys; we simply make sure the published selectors and policy are correct and aligned. If you ever switch providers later, you rotate the relevant records, and nothing else about the setup breaks.
• Switching or adding a provider is straightforward. Migrating from, say, Google Workspace to Microsoft 365 just means updating the SPF and DKIM entries for the new sender. Your DMARC policy and monitoring carry across unchanged.

The only thing that genuinely changes is visibility and protection. Once your DMARC record is live, receivers start emailing aggregate reports showing every source sending under your domain, legitimate or not, and we parse those into a clear view of who is sending your mail. That is how we get you to enforcement without surprises: we watch the real data first, confirm your provider and every other genuine sender pass alignment, then tighten the policy. You can confirm the current state of any domain at any time with our free DMARC checker, SPF checker and DKIM checker, none of which require you to change a single mail setting. In short: keep your provider, keep your mail flow, and let the DNS do the work.

BIMI (Brand Indicators for Message Identification) puts your logo in the inbox: in supporting mailbox providers, your brand mark appears in the avatar slot next to messages you send. The appeal is real. A recognisable logo lifts open rates, helps recipients tell your genuine mail from lookalikes, and signals that you take email security seriously. But BIMI is the last step in the authentication stack, not the first, and it only pays off once the foundations underneath it are solid.

The hard prerequisite is DMARC at enforcement. Mailbox providers will not display your logo unless your domain publishes a DMARC record with a policy of p=quarantine or p=reject (some providers require p=reject). If you are still on p=none, BIMI does nothing at all, because the whole point is that the provider trusts you have locked down who can send as your domain. So the honest sequence is: get SPF and DKIM aligned, move DMARC to enforcement without breaking legitimate mail, and only then publish BIMI. That is exactly the journey DMARC Engine automates, taking a domain from p=none to p=reject safely. You can check where you stand today with the free DMARC checker, and confirm SPF and DKIM with the SPF checker and DKIM checker.

The second cost is the VMC (Verified Mark Certificate), and this is where "worth it" gets specific to your brand. Gmail and Apple Mail will only show a logo backed by a VMC: a certificate, issued by an approved authority, that proves you own the trademark on the logo. That means your logo must be a registered trademark in a recognised jurisdiction, and a VMC carries an annual fee (typically several hundred pounds or dollars a year), plus the converted SVG Tiny PS artwork. Some providers honour a CMC (Common Mark Certificate) for logos that are in use but not yet registered, with narrower display support. Without a registered trademark and a VMC, you can still publish a BIMI record, but the major consumer inboxes will not render your logo, which removes most of the visible benefit.

So, is it worth it? BIMI pays off when you send meaningful volume to consumer inboxes (Gmail, Yahoo, Apple Mail), when brand recognition genuinely matters to your open rates and your customers' trust, and when you already hold or can register the trademark on your logo. Retailers, financial services, charities, and any brand that gets impersonated in phishing tend to see the clearest return. BIMI can wait if you are still at p=none, if you send mostly business-to-business mail to providers that do not display logos, if your logo is not trademarkable, or if the VMC cost outweighs the gain at your volume. The good news is that the work to qualify for BIMI, namely reaching DMARC enforcement, is worth doing on its own merits, so nothing is wasted. Start there, validate your setup with the BIMI checker, and treat the logo as the reward at the finish line. For the full picture of where BIMI sits in the stack, see DMARC requirements.

Yes. DMARC Engine ships with a REST API so you can manage authentication and pull reporting data from your own scripts, CI pipelines, provisioning tools or internal dashboards rather than clicking through the UI. The API speaks JSON over HTTPS and uses API-key authentication, so it slots into the same workflows you already use for the rest of your infrastructure.

You authenticate with a scoped API key. Sign in to the dashboard at app.dmarcengine.com, open Settings -> API keys (creating keys is an admin-only action), and generate a key. Each key is shown once at creation and is stored only as a SHA-256 hash, so copy it straight into your secret store. You can issue multiple keys (for example one per environment or per integration), label them so you know what each is for, and revoke any key instantly if it leaks or is no longer needed. Send the key in the x-api-key request header on every request:

curl https://app.dmarcengine.com/api/domains \
  -H "x-api-key: YOUR_API_KEY"

Here is what you can automate through the API:

• Records and onboarding: add and remove domains, read the DMARC, SPF, DKIM, MTA-STS and BIMI state we manage for each one, and check live publication status. Because we host the records behind a delegated CNAME, you do not push raw DNS through the API; you change policy and configuration, and we propagate it. This is how teams onboard a batch of domains programmatically instead of one at a time.
• Reporting: retrieve the parsed aggregate (RUA) data that normally appears in the dashboard, broken down by sending source, authentication result and pass or fail volume. You can export this on a schedule into your own data warehouse or BI tool, or feed it into a customer-facing report. See /tools/dmarc-report-analyzer for the same parsing logic in an interactive view.
• Alerts and monitoring: poll for the alert events we raise (for example a new unauthenticated source, a drop in pass rate, or a record that has stopped resolving) so you can route them into your own on-call tooling. We do not send inbound webhooks, but you can also have alerts pushed automatically to the outbound notification channels configured in Settings -> Notifications (Email, Slack, a generic HTTPS webhook and PagerDuty) alongside polling the API.

A few practical notes. Keys are scoped to your account, so requests are tied to the same domains you manage in the dashboard. The REST endpoints live under https://app.dmarcengine.com/api/* (for example /api/domains, /api/lookup, /api/reports and /api/settings/api-keys); there is no separate API host and no version namespace in the path. For automation that needs to react to changes, poll the relevant endpoint rather than expecting a callback. Reporting data is only as fresh as the reports your sources send, which for most mailbox providers means roughly daily aggregate reports, so polling more often than once an hour for report data gives you nothing new.

For the full endpoint list, request and response shapes, authentication details and example payloads, documentation is available on request. If you are still deciding whether to drive everything by API or let us run it for you hands-off, the /products/managed-dmarc overview explains the done-for-you path, and you can always mix the two: let us handle the safe progression from p=none to p=reject while your scripts read reporting and alert data through the API. If you need a capability that is not yet exposed, tell us what you are trying to build and we will tell you whether it is on the roadmap.

Your records are yours, and cancellation is a clean exit rather than a cliff edge. Because DMARC Engine is a DNS-based service, nothing we manage lives inside our application in a way that traps you. Your DMARC policy, your SPF rules, your DKIM selectors, your MTA-STS and BIMI configuration are all expressed as ordinary DNS records that any provider can host. When you cancel, the question is simply where those records live and how lookups resolve, and you have full control over both. We do not delete your DNS or change your policy out from under you on the day a subscription ends; an enforcement policy you have already reached stays in effect because it is published in DNS, not gated behind our login.

How the handover works depends on which setup you chose. If you applied our recommended records directly at your own registrar or DNS host, there is nothing to unwind: those TXT and CNAME entries already sit in your authoritative zone, so cancelling the service changes nothing about how receivers evaluate your mail. If instead you used our hosted delegation, your _dmarc, _mta-sts, default BIMI and policy records resolve through a CNAME that points at us. To take that back in-house you replace each delegated CNAME with the flattened record it currently serves, so the same published values now live in your own zone. We give you the exact target records to paste in before you remove the delegation, which means there is no window where your DMARC, SPF or BIMI silently disappears.

A sensible cancellation runs in this order:

1. Export your records. From the dashboard at app.dmarcengine.com you can download the current resolved values for every record we manage: DMARC policy, the flattened SPF, DKIM selectors and keys, MTA-STS policy and BIMI. Keep this as your source of truth.
2. Publish them in your own DNS. Paste the exported TXT and CNAME values into your registrar or DNS host so the identical records resolve from your authoritative zone.
3. Verify with the free tools. Confirm everything still resolves using the DMARC checker, SPF checker, DKIM checker and BIMI checker before you remove any delegation.
4. Remove the delegation, then cancel. Once the checkers show your own zone serving the records, swap out the CNAMEs and close the subscription.

The honest trade-offs are worth stating plainly. Hosted SPF flattening refreshes automatically while you are a customer; once you take SPF in-house, you own the upkeep, and if an upstream sender changes its IPs you update the record yourself. The same applies to DKIM key rotation and to keeping your MTA-STS policy current. Aggregate (RUA) report monitoring and the parsed dashboards stop when the subscription ends, so you would point your rua= address elsewhere or read the raw XML yourself; our DMARC report analyzer remains free if you want to keep eyeballing reports. None of this affects mail flow: your provider, mailboxes and MX records are untouched throughout. If you later decide to come back, see migrating from another DMARC provider, the same delegation step simply runs in reverse.

Yes. DMARC Engine is built to support GDPR compliance, and we act as a data processor for the operational data your domains generate. The personal data we touch is limited and specific. For your account we hold the email address you sign up with, billing details handled by our payment provider, and standard security metadata such as login timestamps and the IP addresses used to access app.dmarcengine.com. For the service itself we ingest DMARC aggregate (RUA) reports, which are sent by receiving mail servers and describe authentication results per source IP, not message content. Aggregate reports can contain sending IP addresses, which may be personal data in some contexts, so we treat them accordingly. We do not read, store or analyse the bodies, subjects or recipients of your actual emails; DMARC reporting works on metadata about authentication, not on the mail you send.

Where the data lives matters for GDPR, and our answer is straightforward: the platform runs on Cloudflare, and report processing happens in Cloudflare Workers with storage in Cloudflare's infrastructure. Cloudflare is a sub-processor and offers EU data-handling commitments and Standard Contractual Clauses for any transfers outside the EEA. We keep the data we hold to a minimum, separate per-account so one customer's reports are never visible to another, and we apply encryption in transit. Access to production data is restricted to the small number of people who operate the service, and account security features such as two-factor authentication and IP allowlisting let you reduce the risk of unauthorised access on your side too.

Retention is deliberately bounded rather than indefinite. Parsed aggregate report data is retained for a defined rolling window so you can see trends and reach p=reject with confidence, after which older detail is aged out. If you close your account, we delete or anonymise the associated personal data within our documented timescales, except where we are legally required to keep certain records (for example, billing and tax records). The exact periods, the categories of data, and our list of sub-processors are set out in our data-retention and privacy notice, which is the authoritative reference and is kept current as the service evolves.

To support your own obligations as the data controller, we provide the practical controls GDPR expects:

• Right of access and erasure: request a copy of your account data or its deletion, handled within statutory timescales.
• Data minimisation: we collect only what the service needs, and we never store your email content.
• A Data Processing Agreement (DPA): available for customers who need one in writing, covering processing scope, sub-processors and SCCs.
• Security controls: encryption in transit, per-account isolation, restricted production access, plus optional 2FA and IP allowlisting on your account.
• Breach process: we will notify affected customers without undue delay if a personal-data breach affecting your data occurs.

If you have a specific clause to satisfy, a security questionnaire, or a request to exercise a data subject right, contact our support team and we will point you to the relevant documentation or sign the paperwork. For the full detail on categories, locations and retention periods, start with the data-retention and privacy notice.

Support is built into the platform rather than bolted on, because email authentication touches live mail flow and getting stuck is not an option. Every plan includes in-app ticketing from the dashboard at app.dmarcengine.com: open a ticket, attach the domain in question, and we can see the same DNS state, report data and timeline you do, so there is no back and forth pasting record values into emails. You can also reach us by email, and tickets and email replies land in the same thread so nothing gets lost between channels. If you have not signed up yet, the free diagnostic tools (the DMARC checker, SPF checker, DKIM checker and BIMI checker) answer most "is my record correct" questions on their own, and the DMARC report analyser explains what your aggregate reports actually mean.

Typical response expectations depend on urgency and plan, and we are honest about that rather than promising numbers we cannot keep across every tier. As a general guide:

• Anything affecting live mail delivery (legitimate mail being quarantined or rejected after a policy change) is treated as top priority and answered first, usually within hours during working hours.
• Configuration and onboarding questions (record syntax, which sources to authenticate, when it is safe to tighten policy) are normally answered the same working day or the next.
• General questions and feature requests are worked through in turn after the above.

We deliberately do not rush you from p=none to p=reject. The whole point of the platform is to take a domain there safely with no outage, so if a ticket is about tightening policy we will look at your real aggregate report data first and tell you whether your sending sources are fully aligned before recommending the change. If they are not, we will tell you exactly which source needs SPF or DKIM fixing before it is safe to move. See the requirements page and the glossary if any of the terms are unfamiliar.

Done-for-you onboarding is the part most people care about, and it is included rather than an upsell. When you bring a domain on board we map out every system that sends mail under it (your mail provider, marketing platform, helpdesk, invoicing tools and so on), generate the correct DMARC, SPF, DKIM and MTA-STS records, and either delegate DNS so we manage the records for you or hand you exact values to paste in if you would rather keep DNS in house. From there we monitor the incoming reports and email you when something needs attention: a new sending source appears, an existing one starts failing alignment, or your data shows it is finally safe to step the policy up. You are never left staring at raw XML wondering what to do next.

If you want to understand the moving parts before raising a ticket, the docs cover setup and DNS delegation, the knowledge base answers common how-to questions, and the blog goes deeper on alignment, reporting and policy strategy. For anything not covered there, open a ticket and a real person who understands DMARC will pick it up.

Yes, genuinely free. Our public checkers and the report analyser run without an account, without a credit card and without a trial clock counting down. You can use them as often as you like, on as many domains as you like, including domains you do not own (handy for vetting a supplier or a prospect). There is no paywall hiding the actual result, no "sign up to see your score" gate and no drip-feed where the first lookup is free and the second one asks for payment. Paste a domain or a record, read the verdict, close the tab. That is the whole transaction.

What you get for free covers the full diagnostic surface of email authentication:

• DMARC checker: fetches and parses your _dmarc TXT record, flags syntax errors and tells you whether your policy is p=none, p=quarantine or p=reject.
• SPF checker: resolves your SPF record, counts the DNS lookups against the limit of 10 and warns when a +all or a stray include is putting you at risk.
• DKIM checker: looks up a selector and validates the published public key.
• BIMI checker: inspects your BIMI record, SVG logo and (where present) the VMC certificate.
• DMARC report analyser: drop in a raw aggregate (RUA) XML file and get a readable breakdown of which sources passed, which failed and where your real mail is coming from.

These tools are deliberately useful on their own. They run the same parsing and DNS logic the platform uses internally, so the answer you see in the free checker is the answer we would act on. A lot of people find a problem with a checker, fix the record by hand and never need anything else, and that is completely fine. We would rather you have a correct DNS record than an account you do not use.

Where the paid platform differs is in the ongoing, done-for-you side that a one-off check cannot give you. A free check is a snapshot of right now; it cannot watch your domain over time, cannot collect the daily RUA reports that providers send back, and cannot walk you safely from p=none to p=reject without guessing which legitimate senders you might break. The platform hosts your DMARC, SPF, DKIM, MTA-STS and BIMI behind delegated records so changes go live without you editing DNS, ingests and stores your aggregate reports continuously, and emails you when a new sending source appears or when alignment drops, so you can move to enforcement without a quiet outage. The free report analyser reads one file you happen to have; the platform receives every report automatically, keeps the history and turns it into a trend.

So the honest summary: the tools are free forever and you never have to upgrade to use them. If you only need to check a record, you are done. If you want continuous monitoring, hosted records and a guided path to p=reject across a portfolio of domains, that is what the dashboard and the paid plans are for. See our requirements guide for what the major mailbox providers now expect, and the glossary if any of the terms above are unfamiliar.

A Verified Mark Certificate (VMC) is a digital certificate that proves you own a registered trademark for the logo you want to display in inboxes. It is the credential that powers BIMI (Brand Indicators for Message Identification), the standard that shows your brand logo next to your messages in supporting email clients. A VMC is issued by an approved Certificate Authority (currently DigiCert or Entrust), and it cryptographically binds your logo (an SVG file) to your registered mark and your domain. When a mailbox provider receives your email, it can fetch the certificate referenced in your BIMI record and confirm that the logo has been verified rather than simply asserted by whoever published the DNS record.

You need a VMC because the two largest consumer providers, Gmail and Apple Mail (on iOS 16 and macOS Ventura or later), will not show your logo without one. Some providers, notably Yahoo and Fastmail, will display a self-asserted BIMI logo with no certificate at all, but Gmail and Apple treat the VMC as a mandatory trust signal. So the practical answer to "do I need one?" depends on where your recipients read their mail: if you want your logo to appear in Gmail and Apple inboxes, a VMC is not optional. There is also a hard technical prerequisite that sits underneath all of this: BIMI only works once your domain is enforcing DMARC at p=quarantine or p=reject with full coverage. No mailbox provider will render any logo, certificate or not, for a domain still on p=none. Getting to enforcement safely is exactly what our hosted DMARC product is built for, and you can confirm your current policy with the free DMARC checker.

The trademark requirement is the part that catches most people out. To obtain a VMC you must own a registered trademark for the mark, granted by an accepted intellectual-property office such as the USPTO, the EUIPO, the UK IPO or another recognised registry. A pending application is not enough; the mark must be registered, and the logo in your SVG must match the registered mark closely. The certificate itself is a paid annual product from the CA, typically several hundred to roughly a thousand US dollars per year, and verification can take days to weeks because the CA checks your trademark and confirms domain control.

If you do not hold a registered trademark, there is now an alternative called a Common Mark Certificate (CMC). A CMC follows the same issuance and validation process as a VMC but accepts marks that are not registered trademarks, such as a logo backed by sustained prior use or a government-issued mark. The trade-off is reach: at the time of writing Gmail recognises CMCs, but Apple Mail does not, so a CMC will not light up your logo across every inbox a VMC would.

Before you spend anything on a certificate, get the foundations right and test what you have:

• Confirm DMARC enforcement first; see our requirements guide for what Gmail and Yahoo expect.
• Prepare a compliant logo, a square SVG Tiny Portable/Secure (SVG P/S) file, and validate it and your record with the BIMI checker.
• Read the full walkthrough in our BIMI product overview before buying a VMC or CMC.

No, and that is the whole point of doing it in stages. We align every legitimate sender first and watch your aggregate reports at each step, only tightening the policy once nothing legitimate is failing.

A standard domain reaches enforced p=reject in about a week of monitored rollout. The exact time depends on how many services send mail as your domain.