Email Spoofing Protection Checker and DMARC Report Dashboard for Small Firms

The problem small businesses have with spoofed email

Anyone can send an email that says it is from accounts@yourshop.com. Criminals use this to send fake invoices to customers, fake payment change requests to suppliers and fake "reset your password" messages. The defence has existed for years: SPF, DKIM and DMARC records in DNS. Yet many small business domains either have none, have an SPF record with too many lookups, or have DMARC stuck at p=none forever because nobody reads the reports.

Since February 2024, Google and Yahoo have required DMARC for bulk senders (5,000 or more messages a day to Gmail), which pushed many businesses to publish a record. Publishing p=none is the easy step. Moving to enforcement without breaking legitimate email from the website, the invoicing tool and the newsletter service is the hard step, and that is where small teams give up.

What already exists and the gap

• dmarcian: built by people involved in creating DMARC, strong education, but the free plan is for personal non-commercial use.
• Postmark DMARC Digests: free weekly digest emails, simple and useful, but little guidance on what to do next.
• Cloudflare DMARC Management: free for Cloudflare customers, with one-click approval of senders. Only helps domains whose DNS is on Cloudflare.
• Valimail, EasyDMARC, Red Sift OnDMARC: capable commercial platforms, priced and pitched for companies with an IT team.

The gap is a tool for the owner of a shop, clinic or agency that explains findings in plain language, works whatever the DNS host, and walks them step by step to enforcement with confidence that nothing legitimate will break.

What you build

A web app with two roles: domain owner and advisor (an IT freelancer or agency looking after several domains).

1. Check: enter a domain and get an instant report card for SPF, DKIM and DMARC with plain explanations and fixes.
2. Collect: publish a DMARC record pointing aggregate reports (the rua tag) at a mailbox the app reads. The app unpacks and parses the XML.
3. Understand: the dashboard groups sending IPs into sources (Google Workspace, Microsoft 365, the website server, a newsletter provider) and shows which pass alignment.
4. Approve and enforce: the owner marks sources as legitimate. When every legitimate source passes, the app proposes the next policy step and the exact record to publish.

The technically interesting part

The interesting work is turning raw reports into sources people recognise. A report lists IP addresses and counts. Your system needs to resolve reverse DNS, map IP ranges to known providers (by reading the providers' own published SPF includes), and cluster the rest. Then it must decide whether a source is safe to enforce against: a source that fails DKIM but passes SPF alignment behaves differently from one that fails both. Show your supervisor the decision rules and the tests behind them.

The parser itself is also a good engineering exercise: reports come gzipped or zipped, in slightly different flavours, and sometimes malformed. Handle them without crashing and log what you skipped.

How to evaluate it

• Parser correctness: 50 or more reports from different receivers parsed with zero crashes; row counts match a reference parser.
• Source identification: on your own test domains, what percentage of sending volume is attributed to a named source.
• Guided rollout: take at least two real domains you or a consenting business control from p=none to quarantine or reject, and report whether any legitimate mail was lost.
• Usability: five non-technical owners read the report card and explain back what they need to fix; count how many get it right.

Suggested plan

1. Weeks 1 to 2: read the DMARC, SPF and DKIM specifications and set up two test domains.
2. Weeks 3 to 5: domain checker with lookup counting and explanations.
3. Weeks 6 to 8: report ingestion and parser with a test corpus.
4. Weeks 9 to 11: source attribution, dashboard, approval flow.
5. Weeks 12 to 14: rollout guide, digests, pilot and evaluation.

Path to a product

The first customer is a small web or IT agency that sets up domains for local businesses and wants to add "email protection" as a monthly line item. Price per monitored domain per month with a free checker as the top of the funnel. Web hosts and domain resellers are a natural channel.

Scope warning

Do not build an email security gateway, spam filter or phishing detector. Do not send test spoofed emails to third parties. Stay with authentication records and reports for domains the user controls.

Learn what you need on Sefism

• Backend roadmap : APIs, background jobs and storage for the report pipeline.
• Backend cheat sheet : quick reference while building the ingestion service.
• CyberChef : handy for decoding headers and inspecting raw report payloads while debugging.
• PostgreSQL Documentation : storing and aggregating millions of report rows efficiently.
• roadmap.sh: Cyber Security : context on email threats and authentication.

Get help with this idea

Scoping a security project is mostly about deciding what you will not defend against and how you will prove the rest works. If you want a second opinion on scope, stack or your evaluation plan, a mentor can review it with you; you still build it yourselves. New to Sefism? Create a free account first.

• Discuss this idea with a mentor
• Send a query to Tauseef
• Book a 1:1 session