Skip to content

Alerts

The Alerts page allows you to manage alert email addresses, webhooks, domain setup regression alerts, the digest, and DKIM selector alerts for your organisation.

Alert Email Addresses

This section allows you to add and remove email addresses that will receive operational alerts for your organisation. Alerts are sent for:

  • Domains transitioning from parked to active status due to:
    • No longer having a valid DMARC record with a reject policy.
    • DMARC compliant mail being reported.
  • TLS reports containing failures.
    • Additional TLS failure alerts for the same domain are suppressed for 7 days to prevent notification fatigue.
    • We recommend an out-of-band email address to ensure alert delivery is not impacted by TLS issues.
  • Domain Setup Regression Alerts (if turned on)
    • Summary of regressions that may downgrade email security (detected during hourly checks).
  • DKIM Selector Alerts (if turned on)
    • A known DKIM selector has started failing verification across multiple reports.

If you don't want to receive these alerts, remove all alert email addresses.

Note: Billing and plan limit alerts are sent to the billing email which is managed in the Plan section of the Organisation page.

Webhooks

Configure webhooks to receive alerts via Slack, Microsoft Teams, Discord, or a custom JSON endpoint (VerifyDMARC format). Webhooks deliver the same alert types as email: parked domain state changes, TLS failures, domain setup regressions, and DKIM selector alerts.

You can configure up to 5 webhooks per organisation. At least one alert email address is required before adding webhooks, as email serves as a delivery fallback.

Supported Formats

  • Slack — Posts to a Slack Incoming Webhook URL using Block Kit formatting.
  • Microsoft Teams — Posts to a Teams Incoming Webhook or Power Automate Workflow URL using Adaptive Card formatting.
  • Discord — Posts to a Discord Webhook URL using embed formatting.
  • VerifyDMARC (JSON) — Posts a structured JSON payload to any HTTPS endpoint. Includes HMAC-SHA256 signing for payload verification.

Creating a Webhook

When you create a webhook, a test payload is sent to the URL first. If the test fails, the webhook is not saved. This ensures your endpoint is reachable and accepts the correct format before live alerts are sent. Your endpoint must respond with a 2xx status code (e.g. 200, 201, 204) within 10 seconds for the test to pass.

Webhook URLs must use HTTPS. For Slack, Teams, and Discord, the URL must match the expected platform host.

Note: Test payloads for the VerifyDMARC (JSON) format are not signed. See Signing for details on verifying payloads.

Signing (VerifyDMARC Format)

Webhooks using the VerifyDMARC format include an X-VerifyDMARC-Signature header containing an HMAC-SHA256 signature of the request body. You can use the signing secret to verify that payloads were sent by VerifyDMARC. Live alert deliveries are always signed; test payloads are not. Your endpoint should always acknowledge receipt with a 2xx response and verify signatures before processing the payload — do not reject unsigned requests at the HTTP level.

The signing secret is generated when the webhook is created and can be retrieved from the webhook settings. It is masked by default and only visible to organisation admins.

Webhook Health and Auto-Disable

If a webhook fails to deliver 5 consecutive times, it is automatically disabled and a notification email is sent to your alert email addresses. You can re-enable a disabled webhook from the settings page — a successful test is required before it is reactivated.

Webhook vs Email Behaviour

  • If all webhooks succeed, no fallback email is sent.
  • If any webhook fails, the alert is also sent via email and the email includes a note about the failed webhook.
  • If no webhooks are configured, alerts are sent via email only (existing behaviour unchanged).
  • Regression alerts are sent per-domain to webhooks (one alert per affected domain) but batched into a single email.

Important:

  • New alert types may be added in future. Your integration should handle unrecognised alertType values gracefully rather than rejecting them.
  • Webhook delivery is best-effort and subject to the same limitations as email alerts.

Domain Setup Regression Alerts

Turn on Domain Setup Regression Alerts to receive a summary email when one or more regressions are detected. These cover DMARC, SPF, and TLS status, or when MX records change. This keeps notifications actionable and focused.

Hourly checks are performed on all domains for all organisations with an active plan.

Designed to draw attention to unexpected changes and potential email security misconfiguration or issues.

The complete per-domain Setup History is available on the Domain Setup page which includes improvements as well as regressions.

Examples of regression alerts:

  • DMARC status changed from ok to warning
  • DMARC policy changed from reject to quarantine
  • SPF status changed from ok to error
  • MX records changed
  • MTA-STS Enforce status changed from detected to not detected

Important:

  • Best-effort notifications only: emails are not guaranteed delivery and are not a substitute for robust change control.
  • If conditions improve then regress in subsequent hourly checks we may suppress those alerts for 24 hours to avoid notification fatigue, keep an eye on Setup History under Domain Setup.
  • Persistent repeat alerts or Setup History entries often indicate an underlying issue, misconfiguration or an outage; further investigation is recommended.
  • Transient DNS failures or outages may cause false or repeated alerts.

Digest (Beta)

The digest is an optional scheduled email summarising where your organisation stands, so you can keep on top of email security posture without signing in every day. It covers:

  • Domains needing action
  • Enforcement posture across your domains
  • No DKIM sender counts
  • Sender compliance

Choose the level of detail:

  • Summary: counts plus sender compliance.
  • Detailed: adds domain lists and No DKIM sender details.

Select the days of the week, the hour, and the timezone that suit you. The digest is sent to your alert email addresses, so at least one alert email address must be added before it can be turned on.

Note: This is a Beta feature and content may be subject to changes.

DKIM Selector Alerts (Beta)

Turn on DKIM Selector Alerts to be notified when a known DKIM selector for one of your domains starts failing verification across multiple reports. This is an early signal that a signing key has been rotated, removed, or misconfigured, often before it shows up as a compliance drop.

Like other alert types, DKIM selector alerts are delivered to your configured webhooks, with email to your alert email addresses as a fallback. At least one alert email address must be added before this can be turned on.

Important:

  • Best-effort notifications only: alerts are not guaranteed delivery and are not a substitute for monitoring your sender compliance.
  • A failing selector usually warrants checking with the email service provider that signs with it.
  • This is a Beta feature and may be subject to changes.