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.
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.
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.