DNS & E-mail Authentication Posture
Grades a domain's SPF/DKIM/DMARC/MTA-STS/DNSSEC/CAA posture and the mail-spoofing exposure it controls.
Overview
This area covers products and tools that check and help fix the DNS-anchored controls that stop domain spoofing and mail interception: SPF, DKIM and DMARC (who may send mail as this domain, and what happens when they don't), MTA-STS and TLS-RPT (mail transport encryption), BIMI (a verified brand logo in the inbox, once DMARC is enforced), DNSSEC and CAA (zone and certificate-issuance integrity), and dangling-record/subdomain-takeover exposure. It is distinct from `email-security-anti-phishing`, which filters the mail your users RECEIVE, and from `secure-web-gateway-dns-security`, which filters a USER's outbound DNS/web requests to block malicious destinations — this area instead grades whether the DOMAIN ITSELF is correctly configured against spoofing and hijack, the posture a phishing sender or a subdomain-takeover attacker would be checking. Pricing is mostly per-domain SaaS, alongside capable open-source command-line tools that cover the checking side (not the ongoing DMARC aggregate-report analytics the commercial platforms specialize in).
SPF/DKIM/DMARC misconfiguration is nearly universal and directly exploitable — it's what lets an attacker send mail that looks like it came from you.
Advantages
- Open-source tools (checkdmarc, parsedmarc) check and report on the exact same records for free, so this posture doesn't require a paid platform to start
- DMARC's own aggregate (rua) reports are generated for free by every receiving mail server — commercial tools mainly add the parsing, visualization and safe-rollout workflow around data already being sent to you
- A move to DMARC p=reject is one of the highest-leverage anti-phishing changes available, and the DNS records themselves cost nothing
Trade-offs
- Moving from p=none to p=reject without first analyzing aggregate reports risks blocking your own legitimate mail (a forgotten marketing-mail sender, a helpdesk ticketing system) — the reason the specialist platforms exist
- BIMI's biggest payoff (the verified checkmark/logo) needs a Verified Mark Certificate from a small set of paid CAs, on top of DMARC enforcement — real added cost most vendors here don't include
- Every check here is necessary but not sufficient alone; a domain can pass every individual check and still be misconfigured in combination (e.g. an overly permissive SPF `include`)
Open-source option
checkdmarc covers the record-configuration checks, and parsedmarc covers their core DMARC-report-parsing data pipeline — both free and actively maintained. What the commercial tier really sells on top is hosted dashboards, guided rollout workflow and support; CMDash's own posture engine (record-correctness checks, no report ingestion) sits closer to the open-source line than the commercial one — see its `cons` above.
Vendors & tools in this area
DMARC platform operating since 2015 that describes itself as the first to automate DMARC; Monitor tier is free, Enforce automates the path to p=reject.
Visit site →DMARC/SPF/DKIM dashboard founded in 2012 by a primary author of the DMARC specification; paid plans from $19.99/mo (annual).
Visit site →Automated DMARC targeting 6–8 week enforcement, part of the wider Red Sift Pulse platform.
Visit site →Hosted DMARC/SPF/DKIM/BIMI platform with a free single-domain plan; paid plans from $35.99/mo (annual); free lookup tools.
Visit site →SaaS email-authentication platform (DMARC/SPF/DKIM/MTA-STS/BIMI) with published pricing from about $8/mo.
Visit site →Free, actively-maintained Python/CLI validator for SPF, DMARC, MTA-STS, TLS-RPT, BIMI and SMTP TLS records.
Visit site →Free, actively-maintained DMARC/SMTP-TLS aggregate and forensic report parser, with Elasticsearch/Splunk/Kibana output.
Visit site →First-party DNS/e-mail posture engine — 27 checks across SPF, DKIM, DMARC, MTA-STS, TLS-RPT, BIMI, DNSSEC, CAA and subdomain takeover, scheduled and history-tracked.
Visit site →