I shared an early version of this tool a while back, but the backend has been completely rewritten this weekend.
The Problem: The #1 issue I saw wasn't just 'missing' records, it was the 10-DNS-Lookup Limit. People add HubSpot, Salesforce, and Google, and suddenly their email breaks because of nested includes.
The New Solution (v2): I added a 'Fix It' engine that performs a recursive DNS scan. It dives into every include:, resolves the IPs, and flattens them into a single, valid list that bypasses the lookup limit.
New Features:
Deterministic Output: I locked the LLM temperature to 0.0 so it acts as a logic engine, not a creative writer.
Safety Toggles: You can now toggle between SoftFail (~all) and HardFail (-all) instantly to see the diff.
Visual Diff: Shows exactly which IPs are being pulled from where.
It’s still free, no ads, no login. Would love to know if the flattening logic holds up against your most complex enterprise domains."
And could you detail your use of LLMs in this? It’s straightforward DNS queries, right?
I don’t see options for the ‘safety toggles’ you mentioned.
Nested Lookups: You are 100% right. The current UI counter is 'naive' (it just regexes the top-level record). The backend (when you click Fix) does the full recursive resolution to find the hidden depth. I will push a patch to make the frontend counter recursive so it matches the actual problem.
Why LLM: I use standard Node dns libraries for the actual resolution (obviously). The LLM is used as a 'fuzzy parser' to re-assemble the broken pieces and generate the explanation text/diffs. It handles syntax errors in the original record gracefully where my strict regex parsers were failing.
Safety Toggles: They currently only appear after you click the 'Fix It' button (in the result modal). That’s a UX fail on my part—I'll move them to the main view so they are visible upfront.
Appreciate you digging in.
It’d be nice to be able to click on subordinate nodes in the visualization and drill-down into that domain.
Also, be cautious with calling ‘soft fail’ as “safe” and ‘hard fail’ as “secure”. Hard fail is often not the recommended configuration these days, as DKIM can been more appropriate and you may be missing invalidation metrics in DMARC reports due to SMTP connections bailing-out early. Check out M3AAWG guidance.
You are spot on regarding the DMARC interaction. I used 'Safe/Secure' as simplified shorthand for the UI, but you're right that -all can sometimes pre-emptively kill connections before DMARC/DKIM evaluation, causing a loss of reporting data.
I will update the UI labels to be more technical ('SoftFail' / 'HardFail') rather than editorializing them as 'Safe/Secure' to avoid misleading users.
Love the idea of clickable nodes for the visualization drill-down. Adding that to the roadmap for the next sprint.