OnlyDMARC handles operational email-authentication telemetry, DNS snapshots, account access, and notification routing. Our security approach is practical: reduce the data we hold, protect the secrets that grant access, keep privileged actions auditable, and design public tools so they cannot become easy abuse paths.
OnlyDMARC is built as a cloud-hosted .NET application with a managed SQL database, scheduled background functions, queue-backed processing where appropriate, and provider-managed TLS termination in front of the web application. The current production configuration is oriented around Azure-hosted infrastructure.
We rely on managed cloud-provider controls for physical data-centre security, platform patching, database durability, and storage protections. Application-level design keeps several caches and processors single-instance by intent; we do not present the current deployment as a horizontally scaled, multi-region active-active platform.
Browser and API traffic is served over HTTPS. In production, the application enables HSTS, requires secure cookies for authentication and antiforgery protection, and uses forwarded-header handling so the application sees the original client scheme and IP behind the platform edge.
Database credentials and provider credentials are configuration secrets, not source-code constants. Passwords are stored as hashes. Account verification, password-reset, login-code, and API-key flows use hashed or protected tokens so plaintext secrets do not need to be stored for later comparison.
DMARC aggregate reports and DNS records can reveal operational information about your email infrastructure. We treat that data as customer data, scope it to authorised users, and avoid exposing personally identifying details through the internal agent-observability API unless an explicitly scoped key is used.
The authenticated application uses cookie-based sign-in, per-user roles, and domain-access grants. Administrative pages require an administrator role. Domain ownership verification grants access only after a DNS TXT challenge is satisfied or an operator performs a manual verification action.
The customer API and internal agent-observability API use separate authentication schemes and scopes. Agent keys have their own scope set, can be revoked, and are audited separately from ordinary user sessions.
Internally, production and administrative access should follow least-privilege practice. Specific company-wide controls such as SSO enforcement, MFA coverage, access-review cadence, and privileged-access tooling should be confirmed before being represented as formal commitments.
OnlyDMARC includes several application-level controls designed to reduce common web and product-abuse risks:
Development practice includes automated tests and code review as part of normal engineering workflow. Claims about mandatory third-party penetration testing, DAST/SAST coverage on every pull request, container image scanning, or fixed remediation SLAs should be treated as future security-program items unless separately confirmed.
The platform records function execution status, application events, notification delivery state, public status snapshots, and selected operational summaries. The public status page provides a current service snapshot, and internal operator views expose deeper health and activity signals.
Notification delivery uses an outbox pattern so transient channel failures can be retried and inspected. Several scheduled maintenance jobs prune or anonymise old public-tool, signup, login-code, and verification records.
We aim to respond quickly to incidents and communicate clearly when customers are affected. We do not currently publish a blanket 24/7 staffed-on-call, SIEM, IDS, or formal incident-response certification claim on this page.
OnlyDMARC is designed with privacy and security controls that support professional use, including data minimisation, scoped access, auditability, and retention/pruning paths. We do not currently claim independent SOC 2, ISO 27001, or Cyber Essentials certification on this page.
If you need a formal security questionnaire, data-processing agreement, sub-processor list, or evidence for procurement, contact us and we will provide the materials that are accurate for the current deployment and operating model.
We welcome good-faith reports of security issues in OnlyDMARC. If you discover a vulnerability, please:
We aim to acknowledge reports promptly and keep reporters informed as we triage and remediate. We cannot promise a bounty, fixed resolution date, or blanket legal safe harbour, but we will not treat good-faith, policy-following research as hostile.
Please email security reports to:
For general security questions that are not vulnerability reports, please use our contact form.