Our infrastructure is certified. DDMARC itself is not yet.
That distinction is the first thing a security reviewer will look for, so it is the first thing on this page, not a footnote under a certification badge. Below: exactly who holds which certificate, what data we can and cannot hold, and the artifacts we will send you before you sign anything.
Certification status, without the badge wall.
Two of these are certifications held by an auditor’s report. Two are compliance postures with no certificate to hold, and one is an authorization we do not hold. Vendors routinely display all five the same way.
It means the platform we run on has been audited — not that our application has. If your review requires a SOC 2 report naming DDMARC, we do not have one yet and you should record that as a gap. What we can give you today is our subprocessor list, our encryption and access-control statement, and the infrastructure provider’s own report. If that is not enough for your risk appetite, we would rather you knew now than at renewal.
We cannot leak your email, because we never receive it.
Forensic reports (RUF) are different, and they are off unless you switch them on. A forensic report can contain message headers — including the mail-from and rcpt-to addresses of the failing message, and occasionally a body fragment the receiver chose to include — because that is the point of them. If your data-handling policy would not permit that, leave RUF disabled and say so in your review; aggregate reporting alone is enough to reach enforcement.
Some of this you can verify yourself.
A control you have to take on trust is worth less than one you can test from outside. Each row says which kind it is — expand any of them for the detail your questionnaire will ask for.
All client and inter-service traffic uses TLS 1.3. Data at rest, including database backups, is encrypted with AES-256. We store no plaintext sensitive data.
Run our own hostnames through any public TLS scanner, or open the certificate in your browser. You do not need to take our word for the transit half of this.
Sign-in is by an emailed link or code, a passkey, Google or a Microsoft work or school account. There are no passwords to reuse or leak, and passkeys and Google or Microsoft sign-in are the options we recommend. Internally, access follows least privilege with role-based permissions, and access to production is logged. Customer-side, three roles (admin, member, viewer) apply organization-wide; everyone in an organization sees every domain, and per-domain scoping is not available yet. Separate organizations, or the partner model, give per-estate isolation today. Enterprise tenants can also be provisioned with per-organization encryption keys and a dedicated database instance. SAML 2.0 and OIDC single sign-on is provisioned on Enterprise agreements; there is no SCIM provisioning yet. If SSO is a requirement, raise it before purchasing so it is written into the agreement.
Create a free account and look at the sign-in options. Passkey, Google, Microsoft work or school accounts and an emailed link or code are there; SAML is not, because SSO is provisioned on Enterprise agreements, not switched on self-serve.
Every configuration and policy change is recorded with actor, timestamp and source address. The log is append-only after ingestion, so historical evidence cannot be edited retrospectively. It is not a long-term compliance archive — export it on a schedule and retain the CSV under your own policy if your framework needs one.
On a trial account, make a change and export the log. If what you see does not satisfy your ITGC reviewer, tell us before you buy, not after.
Infrastructure is monitored continuously with automated alerting and anomaly detection, and we maintain a written incident response plan with defined roles and notification paths.
You cannot test our internal alerting from outside. This is exactly the kind of control a SOC 2 report exists to evidence — which is why our lack of one is stated at the top of this page, not hidden.
We run automated vulnerability scanning against our infrastructure and dependencies continuously, and commission periodic penetration testing by external firms. Summary results are available under NDA.
Ask for the most recent penetration-test summary under NDA and check its date yourself. A test from two years ago is not a current control, and you should hold any vendor — us included — to that.
The platform runs multi-AZ on AWS with automatic failover and zero-downtime deployments. Backups are encrypted, taken daily, support point-in-time recovery; daily copies are kept 30 days and weekly copies up to 12 months. Recovery objectives and a DR test record are in preparation and will join the security packet. 99.99% uptime is a term written into Enterprise agreements; public uptime measurement is in preparation, and until it exists the incident log on the status page is the record.
Watch the public status page across your trial. An SLA is a commitment; the status history is the evidence.
Infrastructure and subprocessors.
Every security review asks for this list, so it is on the page, not behind a form. The current, dated list — including any processor added since this page was last updated, with 30 days’ notice before we do — is in the Data Processing Agreement.
Google and Microsoft appear above for site analytics and session replay — they run only on ddmarc.com, not on account or report data, and only after you allow them in the cookie banner. There is no lock-in either way: your data is exportable by CSV and API at any time, and reports stop the day you remove our rua= address from your DMARC record.
Our commitments in an incident.
Without undue delay, and in any case within 72 hours of confirming a breach affecting your data. We do not wait for a complete picture before telling you.
Which data categories, which accounts, and what we know we do not yet know. No “may have been affected” hedging where we can be precise.
Written updates while the incident is open, then a post-incident summary you can attach to your own records.
security@ddmarc.com reaches a human on the engineering team, not a ticket queue.
No paid bounty at present. We accept coordinated disclosure — see the disclosure policy and our published security.txt.
Report a vulnerability, and what we promise in return.
Email hello@ddmarc.com with what you found, how to reproduce it, and how to reach you. We acknowledge within two business days. Test only against accounts and domains you own or are authorized to use; do not access, change or keep other people’s data; stop and tell us if you reach it; no denial of service, social engineering or physical testing. If you follow these rules we consider the research authorized, we will not pursue legal action against you for it, and we will work with you on timing before anything is published. We do not currently pay bounties.
What we can send you, and when.
Some of these are available immediately, some under NDA, and one does not exist. Tick what your review needs and we will tell you which is which.
Questions reviewers send us.
Encrypted in transit with TLS 1.3 and at rest with AES-256, including backups. Access is restricted to members of your own organization with role-based permissions, and we do not share your data with third parties. The data itself is aggregate traffic statistics, not message content, so even a total compromise would not expose anyone’s email.
Not DDMARC’s own — that certification is in progress and no report exists yet. We can provide the SOC 2 Type II report for PlatOps Security, LLC, the entity you contract with, covering the infrastructure and operations scope, under NDA. If your review requires a report naming the DDMARC application specifically, the answer today is that we cannot satisfy that requirement, and you should log it as a gap.
Yes, and you can do it yourself — account deletion in dashboard settings removes your account and associated data without contacting us. For formal GDPR or CCPA requests, email hello@ddmarc.com; we process within 30 days, and deleted data is removed from backups within 30 days instead of persisting until backup expiry.
We maintain a documented incident response plan. For any incident affecting customer data we notify affected customers without undue delay, and in any case within 72 hours of confirming a breach affecting your data. The notice states which data categories were involved, which accounts, and what remains unknown at the time of writing.
Yes. You choose a US or EU region and your report data, forensic samples and audit log stay in it. Tokyo, HIPAA-eligible (US) and AWS GovCloud (US) are provisioned on request with an Enterprise agreement. Account and billing data, support access and our subprocessors are not region-bound: Stripe processes payments globally, Amazon SES sends from the US, and several other subprocessors operate from the US regardless of which region you choose.
No paid bounty at present. We accept vulnerability reports at hello@ddmarc.com and publish a security.txt file; good-faith research conducted within our disclosure policy will not be pursued.
They can, which is why they are off by default. A forensic report is generated per failing message and may include headers such as subject lines and recipient addresses. Samples are kept 90 days on every plan, separately from your aggregate history, and then deleted. If your data-handling policy would not permit processing that, leave RUF disabled — aggregate reporting alone is sufficient to reach enforcement, and most customers never turn RUF on.
Send us your questionnaire.
CAIQ, SIG, or your own form — send it and we will fill it in. If a control is missing we will say so in the answer instead of leaving the row blank.