This section shows you how to manage alerts.
Click on the image to zoom in
Alerts are classified by Severity and status (Active, Acknowledged, Ignored)
Each alert received can be acted upon by simply clicking on the alert and then decide what you want to do. For instance, the first alert is a Critical RUA alert. If I click on the alert I get a details page:
- You can IGNORE the alert - you will not receive the same alert for that specific client again.
- Acknowledge the Alert (this does not suppress future alerts, simply marks that you've seen and acknowledged the current alert).
- You can also mark as unread.
Each alert type has an explanation as per the DMARC example above.
Critical alerts always generate emails. If you want to change the alert settings (who receives the alerts or which type of things we monitor or with what thresholds), you can simply click on the little gear Icon here to go configure those:
More information can be found on the alerts setting page.
By default you see ALL the alerts or filtered by category.
Summary of alerts with a brief explanation of their function.
Account Management Alerts
Alerts for this category are generated via API calls to proofpoint that look at your organisation and child organisation licensing count and licensed packages.
License Count Exceeded
| When your active user count exceeds your user license count. Note that if you pay monthly, the active number of billable users is the determinant, not the licensed count so you can turn off or disable this alert unless you're using the proofpoint licensing as a way to control clients. |
| Trial Package Upgrade Expiry | When a trial upgrade is expiring and will revert to the previous package. Example: You have someone on "Business" that you upgraded to "Advanced Plus" on a 30 day trial. The client reverts to "Business" after 30 days. If you want to make it permanent, you need to "Confirm" the purchase. |
| Package Change | When an organization changes to a different package. If say, the local admin of a client decides to jump the package Unilaterally from "Business" to "Advanced" for instance without talking to you first. |
Digital Asset Alerts
Digital assets are usually related to DNS entries, Trust Block entries in Proofpoint Essentials or any other information we can pull using the Proofpoint APIs or DNS.
| Misconfigured Domain | When a domain is being used "live" but is not configured to relay or is not active in Proofpoint Essentials. Example: your domain MX record is pointing to mx1-us1.ppe-hosted.com & mx2-us1.ppe-hosted.com, however the domain is not set to RELAY in proofpoint itself. Necessarily all your mail would bounce. |
| Azure Sync Status | Check the status of your Azure Sync setup. Azure Sync secrets are good for a max of 24 months. Usually it means that the current sync expired so you need to "Fix" the sync. This can be done in the Proofpoint Manager under under Azure Active Directory.  |
| Auto Clean Trust Result | Result of auto clean up of the trust list Vircom has a process that runs daily that checks for entries in the trusted list that could cause issues down the line. For instance, self-trusting (ie: jimbob@domain.com trusting jimbob@domain.com or *@domain.com) would open jimbob to getting spoofed messages that use domain.com as the sending domain. Another example is the removal of wild card trusted entries that trust *@gmail.com or *@hotmail.com. Since scammers will often use throw-away addresses in public free mail services, this measure is important to do daily. |
| Inactive Features | When one or more features is not enabled This is just to warn you that the client in question is paying for a feature set where they are not using the most important features. For instance, someone on "Advanced" or "Advanced Plus" that isn't using the encryption. Basically it's a way to find out if people are paying for stuff they are not taking advantage of. |
| Self Trusted | When a domain or mailbox is self-trusted Detection of a self-trust entry prior to the auto-cleanup kicking in. |
| Provider Trusted | When an Email Service provider's domain is trusted Detection of a *@gmail.com or *@hotmail.com trust entry that hasn't been picked up by the auto-cleanup yet. |
Configuration Alerts
These alerts are mainly created by monitoring changes to your IP reputation, or DNS changes related to Email. They are usually pretty important as they can impact mail flow greatly (inbound and/or outbound)
| RBL Hit | When your server has been found to have a bad reputation on an RBL/DNSBL Important note - this alert is important ONLY if your primary MTA which sits BEHIND Proofpoint is not sending mail out THROUGH Proofpoint. If it is, consider this alert as informational - basically the IP your MTA sits on is "dirty" according to one of the more popular DNSBLs and you should want to clean that up at some point. |
| SPF Problem | SPF record is invalid or has an improper policy set There can be multiple types of problems - syntax issues, deprecated settings. The most common will be having TWO seperate SPF records (which is bad, there should be only one) or too many lookups (SPF only allows 10 lookups) If uncertain, reach out to our support team. |
| SOA Changed | Domain's server of authority (SOA) changed. The two top reasons this can happen are: 1) Domain is transfered to a different registrar without notifying you. This could be a takeover attempt or simply a webmaster who "helps" by moving the DNS registration to wherever it is now to a platform that he manages. This usually is botched and mail goes down in the process. 2) Domain registration expires and the domain gets parked. Either way, this alert is pretty important as this means most likely mail is going to go down if left unattended if all the records from the zone file weren't copied over. |
| MX Typo | Domain MX record has a typo. Self-explanatory. |
| DMARC Problem | Problem is found with DMARC. Typically it's either because there's no rua address (a RUA is tells where to send DMARC reports to) or the RUA is associated with a domain that isn't the same as the DMARC entry itself. Usually it requires creating a seperate TXT record by the report receiver indicating they grant permission to receive reports on your behalf. There can be other reasons as well but these are the two most common ones. |
| MX Changed | MX changed to a different location. Someone is stopping to use proofpoint (decomissioning) without notifying you or Godaddy reverts the domain to point back directly to office365 without notifying you (assuming you're using godaddy for DNS), or any other reason MX could change. For instance, the "webmaster knowing DNS changing the registrar" could provoke this kind of thing as well. |
Email Activity Alerts
These alerts simply warn you that there's something odd going on based on the stats we pull from proofpoint.
| Spam Outliers | When an inbound spam wave is detected and blocked by the system. The message is informational more than anything. We detected a big wave of messages that were blocked by proofpoint above the normal rate. Depending on the type of wave, it could be useful to check to see if some messages didn't get blocked to report them in that wave. If you're on the "PLUS" packages, you can also REVOKE them from people's inbox using the message log. |
| Outbound Outliers | When an abnormally large volume of mail outbound is detected compared to the company's norm. The usual cause of this is someone doing a big mailmerge sending mail outbound through proofpoint. If you see that they stop at 1000, that means they hit the maximum rate limit. If these are legitimate, you may want to put in a bulk-rate-limit request to increase the bulk rate emails can be sent out to our support team. It can also be an indirect indicator of a compromised account sending out uncaught phishing messages. |
| Inbound Outliers | When an unusual amount of mail hits the domain inbound. A large volume of inbound mail hit the system that seems legitimate but way over the daily average. Worth checking out but likely not dangerous. |
| Outbound Spam | When outgoing spam is detected and blocked. We detected messages going outbound that are blocked as spam. This is usually a false-positive but sometimes it can be a compromised account. Worth checking out. |
| Outbound Virus | When outgoing viruses are detected and blocked. We detected messages going outbound blocked as viruses. Definitely worth checking out as this could signal a breached machine. |
Account Takeover Alerts
These alerts are a bit different. Most of the prior alerts above were generated via checking DNS records or polling the proofpoint API. The alerts for Takeover purposes are generated with the Office365 monitor where we monitor Office365 metrics instead of Proofpoint/DNS metrics.
| MFA Unregistered | When users have not registered for MFA |
| Large Volume outbound Email | Large volume of outbound email detected. We detected a large volume of email going out from the office365 side of things. This is more immediate than the detection done on the Proofpoint side because, on the latter, we monitor stats which are not updated in real time. Office365 is monitored in realtime so this is a much more reliable measure. Definitely a case where you need to take action if this occurs |
| Country Outlisers | People logging on from places they don't usually login from. The office365 Monitor checks where people login from geographically speaking and if we see suddenly that Stacy from accounting is now logging on from China when she was logging on usually from Podunk, New Jersey, we'll let you know. It means the account is likely compromised unless she's on a big vacation. |
| Mail Deleters | We alert you when someone decided to suddenly delete thousands of emails. It could mean nothing, or it could be an attacker cleaning up his or her misdeeds. |
| Suspect Rules | We found rules that are suspicious in the web version of outlook. For instance. Rules that have weird names like '.' or '.." or redirect mail to seldom used folders like "Conversation History" or "RSS feed". That's usually a tell-tale side that an attacker has compromised the mailbox and hiding his activities this way. |
| Failed Logins | Someone is trying to login to a user's account, possibly a brute force attempt. You can use geo-location blocking in Azure AD to reduce these occurences if the login attempts come outside of North America, for instance. |