Which services can send as your domain, and which will fail at p=reject?
Before you move DMARC to quarantine or reject, every service that sends as you (CRM, billing, HR, ticketing, marketing) has to sign with your domain. Enter a domain: we read its public DNS and list what's authorised, what's missing, and what each vendor has to fix.
Add services you know send as this domain (optional: we'll look for their keys too)
Takes about 5 seconds. DNS is queried from your browser through Cloudflare's or Google's public DNS-over-HTTPS; nothing is sent to us or stored.
Need the full picture? DNS shows who is allowed to send; DMARC reports show who actually does.
We're reading DMARC aggregate reports by hand for a few early users: which services really send as your domain, which fail, and the request each vendor needs, until you can move to reject. Ask for it.
Stuck on a vendor that won't sign with your domain? Tell us what happened (4 questions, written, no call).
What it checks, and what it can't
- DMARC: the policy, reports, and tags that RFC 9989 (May 2026) retired (
pct, rf, ri) or added (t, np, psd).
- SPF: every include, the 10-DNS-lookup limit, void lookups, and duplicate records (both are permanent errors).
- DKIM: keys at the selector names 35 vendors document or commonly use. Vendors with account-specific selectors (Salesforce, Amazon SES, Postmark, Freshdesk…) can't be probed; we say so instead of guessing.
- Can't see: which services actually send, whether a vendor really signs with the key you published, and custom selector names. Your DMARC aggregate reports answer those.
- Selector names were checked against each vendor's own setup page on 2026-10-13 where it publishes them; vendors change them (Klaviyo moved from kl1/kl2 to km/kt/ks pairs). Tell us where it's wrong.
Built by Hieu Tran with AI agents. Not affiliated with any vendor named here.