PlainDMARC.
Security

Security & data handling

LAST UPDATED 2026-07-26 · THE MONITORING PRODUCT IS LIVE

This page describes only controls we actually have in place. Where something isn't built yet, we say so. No compliance badges, no claims we can't stand behind.

1. What DMARC aggregate reports contain — and don't

DMARC monitoring works by reading the aggregate (rua) reports that mailbox providers send about your domain. Those reports contain:

Sending source IP addresses
Message volumes (counts of messages, grouped by source)
SPF and DKIM pass/fail results and DMARC alignment outcomes
Aggregate reports do not contain message content, subject lines, or recipient lists. We will only ever request aggregate (rua) reports — never forensic (ruf) reports, which can include message-level detail.

2. What we store today

Your account email address, the domains you add for monitoring, your notification preferences, and the signup source (which page you signed up from).
If you enable client sending: the client email address you enter per domain, and your white-label branding (logo, sender name, colors). Used only to deliver the reports you configure.
DMARC aggregate report data for your domains (the rua contents described in section 1), plus the weekly plain-English verdicts we compute from it.
Page-view analytics: the page, day, browser user-agent and referrer. Your raw IP address is never stored and no per-visitor identifier exists, so a visitor cannot be tracked — across days or within one.
No cookies on public pages. The only cookie we set is the sign-in session cookie for the dashboard (HttpOnly, Secure) — strictly necessary, so no consent banner is required.

3. Transport

All connections are served over TLS (HTTPS is enforced). This is handled by our web server (Caddy) with automatic TLS certificates.

4. Storage & location

Data lives on a single server in the EU (France).
Daily backups. The database is backed up once a day, and an AES-256-encrypted copy of each backup is stored off that server. (This is a recovery measure, not a high-availability claim — it's still one server.)
No third-party analytics and no ad networks.
Email delivery is handled by Resend, acting as a processor for the messages we send you.

We do not claim encryption at rest — that is not something we can verifiably guarantee on this infrastructure, so we won't say it.

5. Authentication

Sign-in is passwordless. We email you two ways in — a one-time link and a 6-digit code — and no password to leak or reuse.

The code exists because links break in practice: corporate mail scanners open every URL in a message before you do, which spends a single-use link, and plenty of people read email on a phone but work on a laptop. The code finishes sign-in in the tab you already have open.

15-minute expiry — both the link and the code stop working shortly after they're sent.
One sign-in, not two doors — the link and the code are the same record. Using either one immediately kills the other, so there is never more than one live way in.
Single use, enforced atomically — opening the same link twice from two tabs can't create two sessions; the first wins, the second is rejected. The code is claimed by the same statement, so a code racing a click cannot produce two sessions either.
Five attempts on the code — after five wrong entries the whole sign-in is void, link included, and you need a fresh email. Codes are stored only as a one-way hash and are compared in constant time.
HttpOnly, Secure session cookies — never readable by page scripts, never sent over plain HTTP.
Sessions last 30 days. Tick “keep me signed in” and it becomes a 60-day window that moves forward while you're using the product, so an active account stays signed in and an abandoned one still expires.
Changing your account email signs out every existing session, immediately, everywhere.

What this does not protect against: anyone who can read your inbox can sign in as you. That is the trade a passwordless product makes, and it is why the link and the code both die in 15 minutes.

6. API security

API keys (pd_...) let you script the product end to end.

Shown once, stored hashed — a key is displayed exactly once at creation; we keep only a one-way hash, the same way we'd never want your own passwords stored elsewhere.
Origin-header check on every state-changing request — defense-in-depth alongside our session cookie's SameSite policy.
Per-IP rate limiting on sensitive endpoints.

7. Responsible disclosure

Found a security issue? Email hello@plaindmarc.com with details — we read every message personally and will respond. We don't yet run a formal bug bounty program; we do commit to acknowledging a good-faith report and fixing verified issues promptly.

8. Security FAQ

Do you write to my DNS?

Never. We only ever read the TXT record you publish — adding, changing, or removing it is entirely up to you.

Can you read my email?

No. We only receive DMARC aggregate reports — sender IPs, volumes, and pass/fail results. No message content, no subject lines, ever.

What happens if I cancel?

Your data is deleted on request — email us anytime, including right after you cancel. Raw report data auto-deletes after 90 days either way.

9. Retention & deletion

Your account, waitlist entry, or report data is deleted on request — email hello@plaindmarc.com, including right after you cancel.
Raw DMARC report data is deleted automatically after 90 days (the weekly verdicts computed from it are kept for your history). Page-view logs are deleted after 180 days. Both run as scheduled jobs, not manual promises.
Deleting a domain from your dashboard immediately deletes its raw report data.

10. No resale

We never sell or share your data with third parties beyond the processors named here: Resend for email delivery, and Polar (our merchant of record) for paid-plan checkout and billing.

11. Who operates PlainDMARC

PlainDMARC is built and operated by Suleiman Yaakoubi, sole proprietor, based in Doha, Qatar. Questions or requests: hello@plaindmarc.com — every message is read personally.

Privacy · Terms · Compare