Thanks for helping keep dmarcheck safe for everyone who uses it.
Please do not open public GitHub issues for security problems.
Report suspected vulnerabilities privately via GitHub's private vulnerability reporting. That creates a confidential advisory only the maintainer can see.
If you cannot use GitHub's private reporting, email the maintainer via the contact listed on the GitHub profile.
Please include:
- A clear description of the issue
- Steps to reproduce (a proof-of-concept URL or payload is ideal)
- The impact you believe the issue has
- Any suggested remediation, if you have one in mind
dmarcheck is maintained by a single person in their spare time, so these are best-effort targets rather than contractual SLAs — but they are concrete so you know what to expect:
| Stage | Target |
|---|---|
| Acknowledgement — we confirm we received your report | within 3 business days |
| Triage — we validate the issue and assign a severity | within 7 business days of acknowledgement |
| Fix — a remediation ships to the live service | critical/high: target 30 days; medium/low: next convenient release |
Public disclosure — the advisory is published as a GitHub Security Advisory under schmug/dmarcheck |
when the fix is deployed, or 90 days after the report, whichever comes first |
Because dmarcheck is a rolling release deployed continuously from main (see
Supported versions), a fix reaches all users as soon as
it merges — there is no back-porting. Critical issues affecting the live service
at dmarc.mx are prioritised over everything else. We'll keep
you updated through the advisory and credit you in the published advisory unless
you ask us not to.
In scope:
- The live service at dmarc.mx and its API
- The mta-sts.dmarc.mx helper worker
- The source code in this repository, including CI/CD workflows
Out of scope:
- Denial-of-service attacks against the live service (Cloudflare's edge handles this — reports about generic DoS will be closed)
- Findings that require the reporter to control DNS records for an arbitrary third-party domain they do not own
- Reports generated solely by automated scanners without a working proof-of-concept
- Vulnerabilities in third-party dependencies that are already tracked by Dependabot unless you have a working exploit chain
dmarcheck is a rolling release deployed continuously from main. There are
no long-lived branches or LTS versions. The only supported version is the
current contents of main / the deployed Worker.
We run automated software-composition analysis (SCA) and static analysis (SAST) on every change, with the following remediation thresholds:
Dependencies (SCA).
- CI runs
npm audit --audit-level=high --omit=devas a requiredcheckstep. A HIGH or CRITICAL CVE in a runtime dependency blocks the merge and must be fixed (upgrade, patch, or remove the dependency) before the PR can land. - Moderate/low runtime CVEs and dev-only dependency CVEs (biome, vitest, wrangler, sharp — none of which ship to the Worker runtime) do not block merges. They are surfaced as Dependabot alerts in the Security tab and batched into routine dependency-bump PRs.
- Dependabot opens dependency and GitHub-Actions update PRs weekly.
- Exception process: if a HIGH/CRITICAL runtime CVE genuinely cannot be remediated (no patch is available yet, or the advisory does not apply to how the dependency is actually used), the maintainer may accept the risk by recording the justification in the PR and overriding the gate — the same dismiss-with-justification discipline applied to CodeQL alerts below. The override and its rationale stay visible in the PR history, and the CVE is re-checked when Dependabot's next bump lands a fix.
Code (SAST).
- CodeQL runs on every pull request and on a
weekly schedule (
Analyze (actions)andAnalyze (javascript-typescript)). - Error-severity CodeQL alerts are triaged and remediated before the associated change merges; warning/note-level alerts are reviewed in the Security tab and fixed or dismissed-with-justification.
These thresholds intentionally match CI's gate so the "what blocks a merge" answer is the same whether you read the policy or the workflow. They tighten if the threat model expands to cover developer machines.
See docs/OSPS-DEVIATIONS.md for where dmarcheck intentionally deviates from the OSPS Baseline, and THREAT_MODEL.md for the system's assets, entry points, and threats.
Security research conducted in good faith against the scope above — including automated scanning at reasonable rates, and testing with domains you own — is welcome. Please avoid:
- Testing against third parties' domains you do not control
- Automated scanning that hammers
dmarc.mxat high volume - Actions that could degrade service for other users
- Accessing, modifying, or exfiltrating data that is not yours
Reports that follow this policy will not result in legal action from the maintainer.