Credential exposure alerts are useful when the recipient understands why a message arrived and where to investigate it. Sending every match to every colleague can make the important distinctions harder to see. Start with a clear scope, a recipient who understands that scope, and a delivery channel appropriate for the information included.
In Vuxep, alerts concern newly indexed matches. They do not certify a new breach, a working password, or successful unauthorized access.
Confirm scope and configuration access
Verify the domain before enabling monitoring or creating targeted rules for it. Organization administrators manage notification settings and connected destinations; viewers can inspect organization settings but cannot change them. Platform administrators can manage the same configuration for an organization.
Choose a recipient mailbox or channel with a clear owner. Confirm who can read it, including external guests, forwarding rules, and integrations. A convenient team channel is not automatically an appropriate audience for account information.
If domain coverage is incomplete, begin with the verified-domain setup guide.
Choose broad coverage or a specific question
Broad domain reports provide a starting point for monitoring newly indexed matches. Targeted rules let administrators choose an exact hostname, a website domain and its subdomains, a registered domain, an exact work email, an email domain, an exact account, or an exact URL within verified scope.
For a fictional organization, a rule for admin.example.com asks about one host. A work-email-domain rule for example.com asks about the organization's addresses, including observations on external services. Those filters answer different questions.
Each targeted email rule has its own recipient. Creating one does not automatically pause the broad domain reports. If both cover the same evidence, decide whether the overlapping messages serve a purpose before enabling both.
Understand what leaves the workspace
Email digests include recent example accounts with associated hostnames. Chat notifications can include account-and-host examples too, but do not send passwords. Use recipients and channels approved for that information.
Generic webhooks carry event metadata, the verified domain, a match count, and a workspace link. Their payload does not contain accounts, passwords, or original source URLs. That distinction can help when choosing between a human-readable chat notification and an integration that only needs a signal.
Keep detailed review in the authenticated workspace. A notification sample is neither the complete result set nor a substitute for checking the evidence.
Connect and test a destination
Vuxep supports Slack, Discord, Teams, and generic webhook destinations. Select a verified domain and choose either all new domain matches or an existing targeted rule. Use Send test to check delivery with a synthetic message that contains no exposure records.
Use the provider's supported webhook setup. Slack's incoming-webhook documentation explains channel selection and warns that the webhook URL contains a secret. Keep such URLs out of public repositories, screenshots, and shared documents.
A successful test confirms delivery at that moment. It does not demonstrate that future records match the rule or guarantee uninterrupted provider availability.
Verify generic webhook messages
When connecting your own receiver, save the signing secret shown once during creation. Vuxep sends X-Vuxep-Timestamp, X-Vuxep-Signature, and X-Vuxep-Event-Id headers.
Verify the signature over the timestamp, a period, and the exact raw request body using HMAC-SHA256. The expected header value starts with sha256= followed by the hexadecimal signature. Reject stale timestamps and deduplicate event IDs before acting on a message. Re-serializing parsed JSON before verification can change the signed bytes.
Retries preserve the event ID. The event's creation time describes the notification, not the underlying exposure date.
Know what configuration changes do
Rules begin with newly indexed records after creation or modification; enabling monitoring does not email the full historical index. Editing or pausing a targeted rule clears its unsent reports. Destination updates similarly start with new records and clear pending deliveries.
A domain-level destination operates independently of the broad-email switch. A destination attached to a targeted rule follows that rule's filter and enabled state. Pausing email alone therefore does not necessarily pause a connected chat destination.
Check these relationships when reducing notifications. Deleting and recreating configuration is not a way to replay historical findings.
Check delivery status before changing the filter
Vuxep groups matches into digests, and provider availability or retries can affect delivery time. Delivery is not guaranteed to be instantaneous. Review pending, retrying, last-sent, and error information when an expected message does not arrive.
A timeout can occur after a provider accepted a message, so retries may produce duplicate chat notifications. Generic webhook receivers should use the stable event ID to avoid processing the same notification twice.
Start with one understandable rule, test its destination, and review the first matching evidence in the workspace. Then expand coverage deliberately. Use privileged-account priorities to interpret important matches and a redacted exposure report for a broader summary.
Talk to Vuxep about notifications for your verified organization scope.