Security you can trust, not just claim.

ShieldMarc is UK owned and run: the service is operated by ShieldMarc Ltd, a company registered in England and Wales under company number 17352242, with its registered office at 66 Paul Street, London, EC2A 4NA.

ShieldMarc Ltd is the data controller for all customer data, so the company you contract with is the same UK company that answers an access, correction or deletion request.

ShieldMarc customer monitoring data is stored and processed on our servers inside the European Union by default, under GDPR and UK data protection law, with dedicated UK hosting available on request for organisations that require UK data residency. DMARC reports reach us through a Microsoft 365 mailbox, an archive copy of each report email is kept in Cloudflare R2, and the AI features you choose to use call US providers: see the sub-processors below.

Our core infrastructure, databases and monitoring pipelines run inside the European Union. Specific datacentre regions and a data-flow diagram are disclosed under NDA on request as part of any DPIA or procurement questionnaire.

For organisations with strict data residency requirements we offer on request:

• Dedicated UK hosted environments for customers requiring UK data residency.

This is available to enterprise customers on custom pricing. Contact sales to discuss your requirements.

ShieldMarc uses eight named sub-processors: Hetzner (EU) for hosting and offsite backups, Stripe (US) for payments, Microsoft (EU) for email delivery and the mailbox that receives DMARC reports, Zammad (EU, self-hosted) for support tickets, Cloudflare (global) for the edge network and object storage, and Anthropic (US), OpenAI (US) and Google (US) for optional AI features.

Each provider, the data it processes and the jurisdiction it processes in are set out in our Privacy Policy. The categories covered are infrastructure, object storage, offsite backup, email delivery, edge network, payments and AI providers.

The three AI providers receive your data only through an explicit user action: no monitoring or personal data leaves for a model provider unless an operator invokes an AI-assisted feature. We do not sell personal data and do not share data with advertisers or data brokers.

AI analysis of your data always runs on demand. It fires only when an operator clicks an AI button (Explain with AI on a tool result, AI analysis on a DMARC report row, or deep domain review). No background job sends customer data to a model: the one scheduled AI job is our daily check of how OpenAI and Google models answer public DMARC questions, and it sends them no customer data. The signal layer, enforcement engine and alerting all run deterministically without AI involvement.

Deep reasoning (Ask AI on the Email page, including its threat review and domain posture review) is a paid-tier feature and runs on Google's Gemini 3.8 Flash through Cloudflare AI Gateway, with Anthropic's Claude Haiku 4.5 as a fallback we can switch to. Free public tool explainers run on smaller, cheaper models so the free tier can stay genuinely free. Models can change, so the ones in use are also documented to procurement on request as part of any DPIA. When AI is invoked, the relevant record is sent to the model provider under API-only data processing terms that prohibit training on customer data and retain input for short-term abuse monitoring only. By default these providers process the request in the United States. The providers are listed in our Privacy Policy.

Public ingress is tunneled through a managed edge network. Origin servers have no publicly reachable inbound ports beyond the tunnel itself, so the application is not directly exposed to the open internet.

Traffic between your browser and ShieldMarc is encrypted with TLS, and our HSTS header makes browsers insist on HTTPS. Offsite backups are encrypted with AES-256 before they leave our servers, with a passphrase we hold.

Payment data is handled exclusively by our PCI-compliant payment processor. Card numbers, CVVs and banking details never touch ShieldMarc servers. We store only tokenised billing references.

Customer organisations are separated in our database by Postgres row-level security. The default database role for signed-in users' requests is one that the database engine itself limits to the rows of that user's organisations (for an MSP, including its client organisations).

Application code scopes the rest. Scheduled jobs and some dashboard reads and writes use a service role that bypasses row-level security, and DMARC report data, held in a separate search store, is filtered by the application to each organisation's verified domains.

ShieldMarc uses three roles within each organisation:

• Owner: Full access. Organisation transfer, billing, member deletion.
• Admin: Can manage domains, invite members and configure modules.
• Viewer: Read-only access to monitoring data and reports.

Owner-only actions, including subscription changes, organisation transfer and member removal, require owner authentication and are not delegatable.

Significant actions are written to an audit log with actor identity and timestamp, most of them with the IP address and user agent as well, and the log can be exported to owners on request via a security ticket. The application adds entries and does not edit them, except when data is erased: deleting an account removes the entries that person made (keeping a record of the deletion) and replaces their email address in other entries with a keyed hash, and deleting an organisation removes its entries.

ShieldMarc is primarily a machine-data platform. We process domain, DNS, certificate and DMARC report data, not end-user correspondence. That keeps the personal-data surface area deliberately small.

The main personal data we hold:

• Your account and team-member email addresses, for login, invites and notifications.
• Authentication and audit log entries, including IP address and user agent for each significant action.
• In the rare event that receivers send them, DMARC forensic (RUF) report headers. Major mailbox providers like Google, Microsoft and Yahoo do not send RUF reports by default, so this set is empty or near-empty for most customers. We index only their headers, but keep each report email as it arrived, and some receivers attach the whole failing message.
• Free-tool lookups: the domain checked, your IP address and browser user agent, kept for 90 days. For the tools that run on our servers, the domain checked is also kept in our usage analytics, without your IP address, for 400 days.

What we do not store: payment card data (tokenised by our PCI-compliant payment processor). Forensic reports: when receivers send them, they carry the failing message's headers, which can include names, email addresses and subject lines, and some carry the whole message; we keep each report email as it arrived. We hold no other personal data about the people your domain's mail is sent to or from.

Monitoring data we do store: domain names, DMARC aggregate report data (source IPs, pass/fail counts, no message content), SSL certificate snapshots, DNS record snapshots, SPF/DKIM verification results, and uptime check results.

GDPR: ShieldMarc is the data controller for all customer data. You have the right to access, correct and delete your data at any time. To request deletion, open a privacy ticket.

DMARC report data is retained for 365 days on every ShieldMarc plan, including the free Starter tier, and is then automatically purged. Uptime check results are kept for 90 days.

Audit logs are retained for 12 months. Enterprise customers may negotiate extended retention as part of a custom plan.

Cancelling a subscription moves your organisation to the free Starter plan and keeps its data; domains and monitors over Starter's limits are suspended, not deleted. If you delete the organisation, its data is kept for 30 days, giving you time to export anything you need or cancel the deletion, and is then permanently deleted. Residual data in backups is overwritten within the normal backup rotation cycle, up to 30 days.

If you delete an individual account rather than an organisation, the personal data and organisation membership for that account are removed immediately.

Every ShieldMarc plan price is published in pounds sterling on the pricing page: Starter is free, Professional is £70 per month billed monthly or £50 per month billed annually (£600 a year), and MSP is £130 per month billed monthly or £100 per month billed annually (£1,200 a year), with Enterprise on application.

Those figures are exclusive of VAT. An MSP expansion bucket of 50 additional domain slots is £40 per month.

Pricing is published rather than quoted, so a procurement team can build a business case without a sales call. Enterprise is the only tier that is priced on application, because the dedicated UK hosting option described above is scoped per customer.

The free Starter plan covers 1 DMARC domain, 10,000 DMARC messages per month, 1 SSL certificate monitor and 1 team member, with the same 365-day data retention as the paid plans and no credit card required.

Starter includes DMARC monitoring, DMARC report analysis and the threat feed. DNS, uptime, lookalike, MTA-STS, TLS-RPT, DNSSEC and CAA monitoring are paid-plan modules, and deep AI reasoning is reserved for paid tiers so the free tier's cost profile stays bounded.

The public tools are a separate surface: they need no account at all, and their AI explainers are free to anyone.

ShieldMarc infrastructure is monitored continuously across application and database layers. We target high availability and receive automated alerts for any degradation.

In the event of an incident affecting customer data or monitoring accuracy, affected customers will be notified within 72 hours via the email address on their account.

No formal SLA is published at this time. MSP customers should contact us to discuss contractual availability requirements.

Public status page: a public status page showing live availability, incident history and scheduled maintenance is on our near-term roadmap. Until it launches, open a security ticket to request recent availability figures.

ShieldMarc applies automated security controls across the full development and deployment lifecycle, and layered runtime defences in production. Specific tools and vendors are not listed publicly.

Build and release pipeline

• Dependency vulnerability scanning: Every build checks the full dependency tree against known CVE feeds, and automated pull requests are raised when new advisories affect a dependency we use.
• Container image scanning: Every deployment image is scanned for OS and library vulnerabilities, and a Software Bill of Materials is generated for each release.
• Secret scanning: Two secret scanners, one pattern-based and one that reports only credentials it confirms are live, check pushes to the main branch and pull requests in continuous integration, and a finding blocks deployment. The full repository history is also scanned nightly.
• Code review: Production changes are reviewed against a documented checklist before release.

Edge and transport

• WAF, bot management and DDoS mitigation: All public traffic passes through a managed edge network providing web application firewall, bot scoring and DDoS mitigation before requests reach the application.
• Tunneled origin: Application servers are reachable only via an authenticated edge tunnel. No public inbound ports are exposed on the origin host.
• Security headers: HSTS covering subdomains, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy and Cross-Origin-Opener-Policy are set on application responses. The Content Security Policy carries a per-request nonce on the dashboard, sign-in, sign-up, invitation, checkout, scan result, API and blog routes; other public pages get a fixed policy without a nonce that allows inline scripts.

Application runtime

• Rate limiting and abuse protection: API endpoints are rate-limited per identity and per source address. Repeated limit violations trigger temporary bans across the full API surface.
• CSRF protection: State-changing requests are validated against browser-origin signals before reaching handler logic.
• SSRF protection: User-supplied domain and URL inputs are validated against private, loopback, link-local and reserved IPv4 and IPv6 ranges before any outbound request.
• Signed webhook verification: Inbound webhooks from billing and auth providers are signature-verified and replay-protected with idempotency deduplication.
• Input validation: Most API request bodies are read under a size cap and validated against typed schemas at the handler boundary; the rest, such as uploads, incoming TLS reports and browser beacons, are size-capped and checked in the route's own code, except sign-in and account requests, which our authentication library handles.

Host and container hardening

• Host firewall: Default-deny inbound firewall that accepts only SSH and ping from the internet. Brute-force attempts on SSH are detected and banned automatically.
• Patching: Security updates are applied automatically from the distribution security channel.
• Host audit logging: The server that runs our virtual machines keeps continuous kernel-level audit logs of changes to accounts and access settings, commands administrators run as root, kernel modules loaded or removed, and runs of the command-line tools that manage virtual machines and containers.
• Host intrusion detection: Every day, the server that runs our virtual machines and the one that runs the application are checked for changes to their system files and programs, scanned for rootkits, and scanned for malware in files changed since the day before, with a full malware scan every week. Anything a check finds is emailed to our operator straight away.
• Container hardening: Application containers run with no-new-privileges, a read-only root filesystem, restricted writable mounts, CPU and memory limits, and network isolation for stateful services.
• Administrative access: SSH accepts keys only, with password authentication disabled. On the server that runs our virtual machines and the one that runs the application, root cannot log in over SSH, and each login is logged with the key it used.

If you discover a security vulnerability in ShieldMarc, please report it responsibly via our security disclosure form with a description of the issue and steps to reproduce. We acknowledge submissions within 24 hours.

We target a 5 business day initial response. We ask that you:

• Do not access or modify data belonging to other customers.
• Do not publicly disclose the vulnerability before we have had a chance to address it.
• Act in good faith throughout the disclosure process.

We do not currently operate a formal bug bounty programme, but we are grateful to researchers who help us improve security.

ShieldMarc's engineering posture is built to certification-grade frameworks from day one. Formal attestations (starting with Cyber Essentials, then SOC 2 or ISO 27001 depending on customer demand) are a first-order goal as the business scales.

What we already do: the controls described on this page (encryption, tenant isolation, role-based access, audit logging, minimal personal-data handling, incident response, WAF and DDoS mitigation, dependency and container vulnerability scanning, secret scanning, tunneled origin with no public inbound ports) are the same ones a formal certification would assess. They are in production today, not on a roadmap.

For vendor assessments, DPIAs or public sector procurement questionnaires we provide tailored documentation on request. Contact sales with the framework or questionnaire you need to complete and we will respond with the relevant evidence. What the service itself covers, and what is not included, is on our UK DMARC services page.