Get paged when your DMARC stops protecting you.
A domain with enforced DMARC can silently fall back to p=none in a migration — and become spoofable again, with no visible sign. Merlonix re-checks your SPF and DMARC posture on a schedule and alerts you the moment enforcement drops or your SPF record disappears.
How it works
01
Turn it on for an asset
Enable email-auth monitoring on any monitored asset. It is a $0 deterministic DNS lookup on your existing cadence — no AI, no third-party API, no new credential.
02
We re-check your SPF & DMARC posture
On the asset’s cadence Merlonix re-queries your apex SPF record and your _dmarc policy — reading not just presence but whether DMARC is actually enforced (p=quarantine/reject) and whether SPF ends in -all — building a posture history over time.
03
We watch for an enforcement drop
The dangerous change is a domain that enforced DMARC falling back to p=none — a migration that reset the record, a “temporary” relaxation that never got reverted, a provider change. That definitive enforced→unenforced transition (or an SPF record disappearing) is a genuine regression.
04
You get an alert
A DMARC enforced→unenforced drop pages you with a warning; when enforcement is restored you get an info recovery. SPF present→absent alerts the same way. A resolver failure records an “unknown” and never alerts, so a transient DNS blip is never misread as a regression.
What we watch
Spoofability posture, re-checked on a schedule.
We read the same SPF and DMARC signals a good scanner reads — not just “present,” but whether the policy is actually enforced— then keep reading them, so a domain that quietly loses its protection becomes an alert instead of a silent gap.
Why continuous beats a one-time check
Catch the migration that reset your DMARC to p=none
DMARC enforcement breaks most often not from an attack but from an operations change — an email-platform migration that rebuilt the _dmarc record at p=none, a “let’s loosen it while we debug” that never got tightened again. A one-time check at setup can’t see that; a scheduled re-check does.
Know the moment your domain becomes spoofable
A published-but-unenforced DMARC record (p=none) tells receivers to deliver forged mail as you. Most scanners report DMARC as simply “present” and miss the drop. When enforcement falls back, your domain is spoofable again — and continuous monitoring is the only thing that tells you when.
One panel with the rest of your posture
DMARC-enforcement drops land in the same alert stream and asset detail as your SSL expiry, DNS drift, DNSSEC, security headers, and uptime — so the person who owns the domain hears about it the same way as everything else.
What we promise — and what we don’t
We watch your SPF/DMARC posture. We don’t run your mail.
Merlonix re-checks whether your DMARC is enforced and your SPF is present on your asset’s cadence, and alerts you when enforcement drops or SPF disappears. It is informational — the posture is not folded into a pass/fail score, and a resolver failure is recorded as unknown, never an alert. We tell you, continuously and precisely, when your domain becomes spoofable; the fix — restoring p=quarantine/rejector your SPF record — lives on your side. No fabricated posture, no guarantees beyond what the DNS records themselves say.
Common questions
What does email-auth monitoring actually check?
On your asset’s cadence, Merlonix re-checks your apex SPF record (present, and whether it ends in -all) and your _dmarc policy (present, and whether p= is actually enforced with quarantine/reject vs a spoofable p=none), plus whether an MTA-STS policy is declared. It records that posture over time and alerts you when DMARC enforcement drops or your SPF record disappears.
When does it alert me?
When DMARC goes from enforced (p=quarantine or p=reject) to unenforced (p=none or no record) between two definitive checks, you get a warning — your domain is now spoofable. When enforcement is restored you get an info recovery. An SPF record disappearing also warns (and its return recovers). MTA-STS declaration is recorded but does not alert. If a resolver fails, the check is recorded as “unknown” and never alerts.
How is this different from a one-time SPF/DMARC check?
A one-time check (including our own free /tools/email-auth scan) tells you your posture at the moment you run it. Continuous monitoring re-checks on your schedule and catches the silent enforcement drop a later migration introduces — which a check you ran at setup can never see.
Does it monitor DKIM or full email deliverability?
Not continuously. The monitored kind alerts on SPF presence and DMARC enforcement (the two highest-value spoofability signals) and records MTA-STS declaration. Our free /tools/email-auth scan also reads DKIM at well-known selectors and MTA-STS mode/BIMI on demand, and for deep, email-specific deliverability analysis a dedicated deliverability tool goes further — we’re honest about that division.
Does the email-auth posture affect a pass/fail score?
No. Email-auth monitoring is informational: the alerts stand on their own and are not folded into any aggregate health or compliance score. That keeps it consistent with the free scanner and the readout, which also keep it out of scoring.
Don’t let a migration silently un-protect your domain.
Turn on email-auth monitoring and get paged the moment DMARC enforcement drops. Start the full-workspace trial — 14 days, no card.