Pulseguard
Under Attack?DNS Monitoring
Every DNS change, flagged instantly.
DNS is the one place where a single record change can hand your traffic, or your email, to someone else. Records are resolved on every scan, compared with the last resolution, and evaluated for the email-authentication policies that decide whether anyone can send mail as you.
- Record types resolved
- 6
- Email auth policies checked
- 3
- Against the last resolution
- Diffed
- First run is never an alert
- Baseline
What resolved, and what changed.
Email authentication across the top, the zone as it resolves on the left, and the diff against the previous resolution on the right.
One record, soft-fail policy, within the ten-lookup limit.
Policy is p=none: reports are collected, nothing is rejected.
Selectors are arbitrary, so absence is reported, never called a confirmed gap.
- A api 198.51.100.14+ A api 203.0.113.41- TXT _dmarc v=DMARC1; p=quarantine;+ TXT _dmarc v=DMARC1; p=none;+ TXT @ google-site-verification=…
Nobody watches DNS until it's the problem
A repointed A record is a takeover. A weakened DMARC policy is an invoice fraud campaign nobody notices for a month.
Every change is a diff
Records aren't just listed. They're compared with the previous resolution, so what changed is the headline rather than something you'd have to spot by reading.
Email spoofing is a DNS problem
SPF, DMARC, and DKIM are what stop anyone sending mail as your domain. All three are evaluated, and a policy that exists but enforces nothing is reported as weak rather than as a pass.
Honest about what can't be proven
DKIM selectors are arbitrary, so a key that isn't at a common selector is reported as not detected, never as a confirmed gap. A scanner that guesses here is worse than one that says so.
Changes open incidents
A DNS change opens an Incident with its own timeline, because the question after an unexpected record change is always 'who did this and when', not 'is there a notification somewhere'.
The first run isn't an alarm
A project's first resolution populates every record as new, which isn't a change worth reporting. Diffing only starts once a baseline exists. That was deliberate, after learning the alternative is a wall of noise.
Part of the same timeline
DNS events sit alongside findings, certificate renewals, and deployments, so a change can be read next to whatever else happened that day.
Six record types, checked directly
Records are resolved through the platform's own resolver rather than scraped from a provider's API, so what's recorded is what the internet actually sees.
Address records
A and AAAA records with their TTLs: the ones that decide where your traffic actually lands.
Mail routing
MX records with their priorities, so a change in who receives your mail is visible.
Text records
TXT records including SPF and DMARC policies, domain verification tokens, and anything else parked in the zone.
Delegation
NS and SOA records. A nameserver change is one of the loudest possible signals that something has happened to a domain.
How a change gets caught
Resolve, store, compare, and only then decide whether anything is worth telling you about.
- 1
Records are resolved directly
A, AAAA, MX, TXT, NS, and SOA are looked up per domain using the platform's own resolver, with no third-party API in the path and nothing to configure.
- 2
Every record is stored with its dates
Each record keeps a first-seen and last-seen timestamp, which is what makes 'when did this appear' answerable rather than a matter of memory.
- 3
Email policies are evaluated
SPF syntax and lookup limits, the DMARC policy level, and best-effort DKIM presence are turned into findings, with DKIM absence reported conservatively rather than asserted.
- 4
The zone is diffed against the baseline
Changes are computed against the previous resolution, gated on a non-empty baseline so a first run records history instead of raising alarms.
- 5
Notable changes become incidents
A record change that matters opens an Incident and lands on the project timeline, alongside the findings and certificate events from the same scan.
DNS Monitoring, answered.
No. Records are resolved directly over DNS, which means what's recorded is what the world resolves, including a discrepancy between your provider's dashboard and what's actually being served.
Know the moment a record moves.
Add a domain and the first resolution becomes your baseline immediately.