Monitoring · Available on All tiers

A broken SPF record fails silently — until your emails start landing in spam.

Check DNS records directly, including SPF, DKIM and DMARC, so a deliverability record clobbered by a DNS change doesn't sit broken for weeks before anyone notices.

Start Free → See pricing

Free forever plan, no card required.

Why it matters

DNS record monitoring

DNS changes are some of the riskiest, least-monitored edits a team makes. A typo'd TXT record, a domain migration that dropped a DKIM key, a DMARC policy overwritten by a script — none of it throws an error. It just quietly breaks email deliverability or routing until someone finally notices. Nobody runs a test suite against DNS the way they do against application code, and most teams only look at their records when something's already wrong, which means the window between "the record broke" and "someone noticed" can run to weeks. In that window, password reset emails silently start bouncing, a subdomain quietly stops resolving, or a DMARC policy left in an old, permissive state leaves the door open for exactly the kind of spoofing it was supposed to prevent. Watching the records directly closes that window down to the length of a check interval instead of however long it takes someone to stumble across the problem. It's the digital equivalent of a foundation crack — invisible from the curb, structural underneath. It's a category of failure most teams don't even think to monitor for until it's already cost them something.

Email authentication, covered

SPF, DKIM and DMARC monitored directly, not inferred from a delivery failure three weeks later. Instead of waiting for a bounce report or a customer complaint to tell you something's wrong with your sending reputation, you find out the moment one of these records actually changes — before it's had time to quietly tank your deliverability. That's a meaningfully faster feedback loop than waiting for a marketing platform's own deliverability dashboard to flag a problem. Deliverability problems caught this early rarely have time to actually damage your sender reputation.

Any record type

Watch the records that matter for your setup, not just the handful a generic tool assumes you use. Whether that's an MX record for a mail migration, a CNAME pointing at a third-party service, or a TXT record used for domain verification with some other tool entirely, you're not limited to a fixed list of "important" record types someone else decided on. That flexibility matters because every team's DNS setup looks a little different from the next one's. The monitor adapts to your infrastructure instead of forcing your infrastructure to fit a predefined template.

Change history via Automations

Starter+ orgs get a DNS change report showing exactly what value changed, and when it changed. That turns "something about our DNS looks different" into a concrete before-and-after you can hand to whoever made the change — or whoever needs to revert it — instead of trying to reconstruct what happened from memory. It turns DNS debugging from a guessing game into a quick look at a timestamped log. It's the kind of paper trail that turns a stressful debugging session into a quick lookup.

FAQ

DNS record monitoring, answered.

Which DNS records can it check?

Any record type you point it at, including SPF, DKIM and DMARC — the three most common causes of a broken deliverability record. That also covers A, AAAA, CNAME, MX, TXT and NS records, so a monitor can watch whichever record actually matters for your setup, not just the ones a generic tool assumes everyone cares about. If your setup relies on a less common record type, it's still fair game to monitor. There's no shorter list hiding behind the marketing copy — the coverage really is that broad.

Can I see what changed and when?

Starter tier and up get a DNS change report through Automations, showing exactly what value changed and when — not just that something's different now. That turns a vague "DNS looks off" into a concrete record of the old value, the new value, and the timestamp, which is usually all you need to figure out who or what made the change. That level of detail is usually enough to skip a round of "wait, what did we even change?" entirely. It's the kind of detail that saves real time during an actual investigation.

Will this catch a DNS change made by my registrar or DNS provider?

Yes — the monitor doesn't care where a change came from. Whether it was a teammate, a script, an expired domain transfer, or your DNS provider making an infrastructure change on their end, a monitored record that resolves differently than expected triggers the same alert either way. The alert doesn't care about intent — only about whether the record now resolves differently than it did before. The record either matches what you expect or it doesn't, regardless of who touched it.

Get Started

DNS record monitoring. Free, starting now.

Start Free →