dmark
dmark is an open-source email security tool for inspecting SPF, DKIM, DMARC and BIMI records and working through domain setup guidance.
This repository contains the bilingual web app. The Go backend contains additional email-authentication services. See project scope and contributing.
A bilingual public app for dmark.is: the domain workspace is the homepage. Visitors add domains, run live checks, inspect records and work through their checklist. There are no accounts by design: no sign-up, password or email address. Saved work lives only in a first-party browser cookie, and check results are not stored server-side. Checklist completion is user-declared progress, not a security certificate.
Development and verification
npm ci
npm run dev
npm test
npm run lint
npm run build
npm run test:launch
npx playwright install chromium
npm run test:browser
Pages: /is/ and /en/. Production runs on Coolify (see COOLIFY.md). The pages are prerendered, while the scan and SPF routes run as Node.js handlers. Static export is intentionally disabled to support these routes.
Live scanner
The browser sends a domain to the same-origin scan route. The route validates it, calls the fixed https://lookup.kastro.is/api/lookup?q=...&scope=mail endpoint from AndriGitDev/whois-there, validates its response, and returns only email-security evidence. The mail scope makes Lookup run DNS and mail-auth checks only, with no WHOIS, TLS, DNSSEC or GeoIP calls. The route does not forward cookies, credentials, user IP headers or unrelated infrastructure details, and stores nothing.
Checks typically complete in under two seconds. The upstream deadline is 45 seconds; the function budget is 60 seconds. Responses are not cached. Upstream failures and rate limits produce explicit errors with no simulated fallback.
All dmark scans reach Lookup from the dmark server, so they share one Lookup rate-limit bucket. The mail scope allows 120 requests per minute per source. Set the optional KASTRO_LOOKUP_TOKEN environment variable to a value listed in Lookup's LOOKUP_SERVICE_TOKENS to give dmark its own bucket of 1,200 requests per minute. Do not forward caller-supplied IP headers to evade limits.
Rating scope
Ratings describe observed SPF/DMARC configuration, not whether an individual message is authenticated or whether spoofing is impossible. F indicates missing/non-enforcing DMARC or failed SPF posture; A requires assessed SPF and full reject enforcement with upstream green findings; B/C indicate remaining configuration concerns. An incomplete SPF chain, blocked target, or resolver warning suppresses the overall grade. Common-selector DKIM discovery is shown separately and does not lower the rating when no key is found. This is not a complete standards conformance validator, and upstream resolver limitations may yield incomplete results. Verify findings against authoritative DNS and message/report evidence before changes.
Saved domains and supplementary DNS checks
Guest domains, six checklist flags and an optional DKIM selector are saved in the compact dmark_workspace_v2 first-party cookie (one year, SameSite=Lax, Secure on HTTPS). It contains no scan results, credentials or email addresses. Browser cookie size can limit the workspace below the 20-domain ceiling; overflow is reported rather than silently truncating work. If cookies are blocked, the app remains usable for that visit. Existing dmark:domains:v1 localStorage work is migrated only after cookie persistence succeeds.
No accounts
Accounts were removed deliberately: dmark never asks for an email address, never creates a session and has no account API routes. The public app provides on-demand checks and manual DNS guidance. Clearing the dmark_workspace_v2 cookie and dmark:scores:v1 localStorage removes everything dmark knows about a visitor's workspace.
The scanner accepts one optional DKIM selector and performs bounded Node DNS TXT resolution for that selector and default._bimi. DNS timeouts are shown as unknown, distinct from a missing record. The new observations do not alter the SPF/DMARC grade and do not fetch remote logos, certificates or arbitrary URLs. They check basic publication only, not cryptographic or full standards validity. Public scan traffic still needs a shared deployment-level rate limiter for substantial use; the new lookups are bounded per request and do not forward caller IP headers.
Analytics
The domain is sent to Kastro Lookup for the requested check, but is not included in scanner analytics events. Events permit only status and source. Optional build-time analytics settings: DMARK_ANALYTICS_PROVIDER, DMARK_ANALYTICS_DOMAIN, DMARK_ANALYTICS_SCRIPT_URL, and DMARK_ANALYTICS_SITE_ID. Policy and contact links lead to Kastro, the current site operator.
Domain scores and guided improvements
Adding a domain starts its first live check. Dashboard cards show DNS readiness out of 100, the existing SPF/DMARC letter grade, last-check time and a refresh action. The improvement plan orders unmet checks, gives DNS names and provider-led remediation instructions, and explains how to verify each fix. Checklist notes never award points.
以上为 README 的开头部分。其余内容请阅读原文。 查看完整 README ↗
