< back to blog

Actionable Alerts: From Webhook to MSP Ticket

MSPProduct Updates

Introduction

Domain Setup Regression Alerts were created to catch the moment a domain’s email security posture moves backwards. When we first introduced them, the delivery path was email. That was useful, but for Managed Service Providers (MSPs), email is rarely the final destination for operational work.

MSPs need tickets.

If a client’s DNS records change unexpectedly, a DMARC policy is downgraded, or MX records move without warning, the useful outcome is not just “someone saw an alert”. The useful outcome is an assigned ticket, tied to the right client and domain, with enough detail for a technician to investigate.

Webhook Alert Delivery now makes that workflow possible. Regression alerts can be sent per-domain to webhook endpoints, including custom JSON endpoints designed to map cleanly into ticketing systems.

Why Email Alone Is Not Enough for MSPs

Email alerts are still important. They remain the fallback path, and they are useful for smaller teams or out-of-band notifications. But MSP operations usually run through ticketing systems, not shared inbox archaeology.

When an alert stays in email:

  • ownership is easy to miss
  • SLA tracking is weak or manual
  • multiple client issues can blur together
  • the investigation trail often lives outside the service desk
  • repeated alerts can be hard to connect to the same underlying change

That is especially painful for domain setup regressions, because the cause is often outside the MSP’s direct control.

A client might give DNS access to a web developer. A registrar migration might change name servers. A marketing platform might ask someone to “just update SPF”. A well-meaning administrator might simplify a DMARC record and remove p=reject.

None of those changes necessarily pass through the MSP’s change process. The first sign may be a regression detected by VerifyDMARC.

The Ticketing Use Case

Webhook alerts let MSPs treat domain regressions like operational events instead of inbox messages.

For regression alerts, VerifyDMARC sends one webhook alert per affected domain. That matters for ticketing, because a single domain regression can become a single ticket with a clear subject, client/domain context, and body details.

The custom VerifyDMARC JSON format is designed for this kind of workflow. An illustrative regression alert looks like this:

{
  "version": "1",
  "alertType": "regression",
  "orgId": "org_12345",
  "domain": "client.example.com",
  "subject": "Domain setup regression detected for client.example.com",
  "details": [
    "DMARC policy changed from reject to quarantine",
    "MX records changed"
  ],
  "dashboardUrl": "https://reports.verifydmarc.com/domain/setup/client.example.com",
  "timestamp": "2026-05-20T00:00:00.000Z"
}

The subject can become the ticket title, details can become the ticket body, domain can drive client or asset matching, and alertType can drive routing or priority rules. The dashboard URL sends the technician straight to the domain setup view for the affected domain.

Slack, Teams and Discord webhooks are useful for internal IT teams that work from chat. MSPs can use those too, but the higher-value workflow is usually JSON into a PSA, service desk, or automation platform that creates tickets.

Delivery and Fallback Behaviour

Webhook Alert Delivery is currently in Beta. You can configure up to five webhooks per organisation, and supported formats include Slack, Microsoft Teams, Discord, and VerifyDMARC JSON.

Webhook URLs must use HTTPS and respond with a successful 2xx response within 10 seconds. For VerifyDMARC JSON webhooks, live alerts include an X-VerifyDMARC-Signature header using HMAC-SHA256. Test payloads are not signed, so your endpoint should acknowledge receipt first and verify signatures before processing live payloads.

Email fallback is still part of the design:

  • if no webhooks are configured, alerts are sent by email
  • if all webhooks succeed, no fallback email is sent
  • if any webhook fails, the alert is also sent by email with a note about the failed webhook
  • if a webhook fails five consecutive times, it is disabled and alert email addresses are notified

For regression alerts specifically, webhooks are sent per-domain, while email remains batched. That keeps tickets specific without flooding an inbox during a larger DNS provider incident.

Why These Alerts Deserve Tickets

VerifyDMARC alerts are intended to represent conditions that need investigation, not background noise to filter out before they reach the service desk.

For MSPs, the ticketing decision is less about asking “should this become work?” and more about asking “who owns the next step?” A DMARC downgrade, SPF regression, MX change, TLS failure, parked domain state change, or future alert type should arrive somewhere actionable by default.

Routing rules can still add value. Use them to assign the right queue, priority, client, asset, or automation path. Just avoid building an integration that rejects unfamiliar alertType values, because new alert types may be added later.

These alerts are not always security incidents. Sometimes they are planned changes that nobody told the MSP about. Sometimes they are transient DNS failures. Sometimes they are genuine mistakes.

Either way, they deserve a ticket because they need a human to decide which case they are.

Example: The Client DNS Change

Imagine a client gives their website provider access to DNS so they can launch a new site. During the update, the provider accidentally changes the MX records or removes part of the SPF record.

Without alerting, the MSP may only hear about it when mail starts failing, spoofing protection weakens, or the client asks why something broke.

With webhook-based regression alerts:

  1. VerifyDMARC’s hourly checks detect the setup regression.
  2. A per-domain webhook alert is sent to the MSP’s ticketing workflow.
  3. The PSA creates a ticket for that client and domain.
  4. The technician checks Domain Setup History for the before-and-after state.
  5. The MSP can restore the record, contact the client, or push the change through proper approval.

The important part is timing. The alert becomes work before the client has to explain the symptom.

A practical setup looks like this:

  1. Configure alert email addresses first. Email remains the fallback path if webhook delivery fails.
  2. Turn on Domain Setup Regression Alerts in VerifyDMARC.
  3. Add a VerifyDMARC JSON webhook that points to your PSA, service desk, or automation layer.
  4. Verify webhook signatures using the signing secret before processing live alerts.
  5. Create routing rules by alertType, domain, client mapping, or asset records.
  6. Include the VerifyDMARC dashboard URL in the ticket so technicians land in the right place.
  7. Use Domain Setup History to compare the current state against previous hourly checks.

For teams that also want visibility in chat, add Slack or Teams as a secondary webhook. But avoid making chat the only destination for MSP operations. Chat is easy to notice and easy to forget. Tickets are harder to dodge.

A Safety Net, Not Change Control

Webhook alerts do not replace good DNS change control. They do not stop a client from handing registrar access to the wrong person, and they do not guarantee that every transient DNS problem is meaningful.

What they do is shorten the detection path.

For MSPs, that matters. A domain setup regression can quickly become a client-facing problem, a spoofing window, or a messy blame conversation. Turning those regressions into tickets gives the team a chance to respond while the issue is still small and specific.

If you manage client domains in VerifyDMARC, review your alert settings and consider sending regression alerts into your ticketing workflow. The inbox can remain the backup. The ticket should become the work.

If you are not using VerifyDMARC yet, start a 30-day free trial and test webhook alert delivery as part of your MSP workflow review.

For setup details, see the VerifyDMARC Alerts documentation.

Start Free Trial