Security

1. Overview

This page describes how DMARCit (operated by Cadmos LLC) approaches the security of the data you entrust to the Service. It is intended as a plain-language summary of our practices and is not a contract. Where this page overlaps with our Terms of Service, Privacy Policy, or Data Processing Addendum, those documents control.

2. Data We Handle

The Service primarily processes two categories of data:

• DMARC aggregate reports (RUA). XML reports sent by mail receivers to the RUA address you configure. These contain summary authentication data (sending IP addresses, message counts, SPF/DKIM alignment, reporting organization) and do not typically contain message content or recipient addresses.
• Account, organization, and billing data. Names, email addresses, hashed credentials, organization membership, role assignments, domain configurations, subscription status, and a truncated card identifier returned by Stripe. We do not store full payment card numbers.

See the Privacy Policy for the full list of data categories and their retention periods.

3. Encryption

In transit. Connections to the DMARCit application and APIs are served over HTTPS using TLS. Outbound connections we make to subprocessors (the database, payment processor, IP intelligence provider, and AWS services) likewise use TLS.

At rest. Data stored with our infrastructure providers is encrypted at rest using the encryption mechanisms provided by those services — Supabase (Postgres), Amazon S3, and Stripe. We rely on the providers' managed encryption and do not operate our own key management system.

No method of transmission or storage is completely secure. We do not represent that the Service is invulnerable, and we do not offer a guarantee of absolute security.

4. Infrastructure

The Service is built on managed infrastructure providers, including:

• Vercel for application hosting and serverless compute
• Supabase for managed Postgres, authentication, and session storage
• Amazon Web Services (SES, S3, SNS, Route 53) for inbound DMARC report email, raw report storage, and DNS for hosted SPF
• Stripe for subscription billing and payment processing

The authoritative list of subprocessors, including data categories and processing regions, is maintained on the Subprocessors page.

5. Authentication and Access Controls

Authentication. Users sign in with email and password (with passwords stored in hashed form by Supabase) or with single sign-on. SAML SSO is available via Supabase's GoTrue authentication service for organizations that prefer to delegate authentication to their own identity provider. Time-based one-time password (TOTP) multi-factor authentication is available as an optional second factor.

Roles. Within an organization, every user holds one of four roles:

• Owner — full administrative control, including billing and member management
• Admin — organization and domain configuration, member management within their scope
• Member — day-to-day use of the Service across the organization's domains
• Viewer — read-only access, scoped to a specific subset of the organization's domains

Domain scoping. Viewers are restricted to the domains explicitly granted to them. The application resolves visible domains for each user through a single canonical helper, so the same scoping rules apply consistently across the dashboard, reports, and APIs.

6. Multi-Tenant Data Isolation

DMARCit is a multi-tenant Service. Tenant data is separated at the database layer using Postgres Row-Level Security (RLS). Application queries run under the authenticated user's identity, and RLS policies on each tenant-scoped table constrain which rows that user can read or modify based on their organization membership and role.

This means that an organization's DMARC reports, domain configurations, and membership data are not visible to users outside that organization through normal Service usage.

7. DMARC Report Handling

Aggregate (RUA) only. The Service ingests DMARC aggregate reports. Raw report emails received by AWS SES are stored briefly in S3 for processing and then deleted on the schedule described in the Privacy Policy. Parsed aggregate data is stored in the database, scoped to your organization.

Forensic (RUF) reports are not ingested. Forensic/failure reports can include message headers and, depending on the generating mail system, portions of the message body — categories of data that materially expand the privacy footprint of a DMARC monitoring service. We have made a deliberate product choice not to receive, store, or display RUF reports. The Service's DNS guidance can still help you configure a RUF address with a third party if you choose, but no RUF data flows into DMARCit.

8. Data Minimization and Retention

We aim to collect only the data needed to operate the Service. We do not use third-party analytics or advertising trackers, and we do not sell personal data. Specific retention periods for account data, DMARC report data, raw report emails, SPF cache data, and logs are listed in the Privacy Policy.

9. Reporting a Security Issue

If you believe you have found a security vulnerability or are aware of a security incident affecting the Service, please contact us at security@dmarcit.io. Please include enough detail to reproduce the issue, and avoid testing that would degrade the Service or affect other customers' data.

We appreciate responsible disclosure and will work with reporters acting in good faith. We do not currently operate a paid bug bounty program.