Appearance
Alerts
MailShield raises an alert when something about a domain changes or goes wrong. Every alert appears under Notifications in the sidebar. Each member chooses which alert types also reach them by email, one by one or as a daily summary, and on Pro through their own notification channels such as Slack or PagerDuty. On Pro, owners and admins can also set up team channels that get the organization's alerts whoever its members are. To set that up, see Notifications.
Alert Types
These are the four switches under Settings → Notifications → Alerts, and the Alert types a team channel can choose. All four are on by default.
| Setting | You're alerted when | Severity |
|---|---|---|
| Score changes | A domain's security score moves by 10 or more points, or its grade changes | Info when the score improves, warning when it drops, critical when it drops to an F (below 60) |
| DNS changes | A monitored DNS record changes, or a check finds a problem in one | Info, warning or critical, depending on the change |
| High failure rates | DMARC or TLS reports show a high share of failures | Warning, or critical above 50% |
| Certificate expiry | A mail server certificate or BIMI VMC expires within 14 days, or a new certificate or TLS problem appears on a mail server | Warning, or critical at 3 days or less and for problems that stop delivery |
MailShield sends score, DNS change and certificate alerts only for verified domains.
Score Changes
Sent when a domain's score moves by 10 points or more in either direction, or its grade changes (for example from B to C). MailShield waits until two checks in a row give the same new score, so a one-off lookup problem doesn't trigger an alert. The alert shows the old and new score and which components changed. When MailShield updates its scoring rules or its checks, or you change a domain's usage type, it takes the new score as the baseline without alerting: the score moved, but nothing changed in the domain's DNS. See Security Score for how the score is calculated.
DNS Changes
MailShield compares each check with the previous one and alerts on changes to:
| Record | Examples of what's detected |
|---|---|
| SPF | The record added, removed or invalid; -all weakened to ~all (or strengthened); providers added or removed; more than 10 DNS lookups |
| DKIM | Selectors removed, keys rotated, a selector becoming invalid. A subdomain that signs its own mail has its key checked under that subdomain |
| DMARC | The record added, removed or invalid; changes to the policy, subdomain policy, pct or alignment; rua or ruf reporting turned on or off |
| MX | Mail servers added, removed or replaced by others; STARTTLS or DANE support changing; the domain no longer accepting mail; its mail servers not answering |
| MTA-STS | The record added, removed or invalid; mode changes; the policy file no longer reachable |
| TLS-RPT | The record added, removed or invalid; reporting addresses changed |
| BIMI | The record or logo location changed or removed; the logo no longer loading or valid |
| DNSSEC | DNSSEC turned on or off, or no longer validating |
A record that disappears is reported only once two checks in a row miss it and MailShield's probes confirm it's gone, so a DNS hiccup doesn't raise a false alarm. The same goes for mail servers that don't answer and for an MTA-STS policy or BIMI logo that doesn't load. When it's back on the next check, neither the hiccup nor its return is reported. A change that was already reported in the last 24 hours isn't reported again.
When a domain publishes more than one SPF or DMARC record, receivers apply none of them. MailShield reports that as a problem (see below), not as the policy changing from one check to the next.
When a record stays the same but stops passing its check, because something it depends on changed (an SPF include, say), the alert says so and gives the reason. When MailShield updates its checks, it takes the new results as the baseline without alerting, like it does for scores.
Problems found
Some mistakes break a record for all mail, however long they have been there. MailShield alerts the first time a check finds one, titled Problem found in the DNS of your domain, with what to do about it:
| Record | Problem |
|---|---|
| SPF | More than one SPF record; more than 10 DNS lookups; more than 2 terms that point at names without DNS records; an include without a valid SPF record; includes that loop |
| DMARC | More than one DMARC record, so receivers apply no policy at all; a missing or invalid policy (p=) |
| MTA-STS | More than one MTA-STS record |
| TLS-RPT | More than one TLS-RPT record |
These can come from a record nobody touched, for example when MailShield starts checking for something new. You hear about a problem again only if it goes away and comes back, not when one check briefly missed the record.
High Failure Rates
Sent when:
- A DMARC report with at least 50 messages shows more than 20% of them failing DMARC.
- The DMARC failure rate over the last 24 hours rises sharply above the domain's 14-day baseline, with at least 50 messages in each period.
- A TLS report shows at least 5 failed TLS sessions, and at least 5% of the sessions in the report failed.
Reports count by the period they cover, not when they arrive: a report about mail from more than 3 days ago, such as one you import, doesn't raise an alert. DMARC rates and the 50-message minimums only count mail that passed or failed DMARC: forwarded mail from mailboxes such as Gmail or Outlook is left out. While a failure rate stays about the same, MailShield repeats its alert only after 7 days. It alerts sooner when the rate rises by 10 percentage points or more, or when the alert becomes more severe. High failure rates can mean someone is spoofing your domain, or a legitimate service isn't set up for SPF and DKIM yet. The alert links to the reports so you can see which sources fail.
Certificate Expiry
Sent when a TLS certificate on one of your MX hosts, or the BIMI Verified Mark Certificate (VMC), expires within 14 days. It becomes critical at 3 days or less, and when the certificate has expired. MailShield repeats the alert at most every 3 days, and right away when it becomes critical or the certificate expires.
An expired MX certificate means senders that verify TLS (MTA-STS in enforce mode, or DANE) stop delivering to you.
The same setting covers mail server problems that a check finds:
| Problem | Impact |
|---|---|
| Certificate name doesn't match the host | Senders that verify TLS (MTA-STS in enforce mode, or DANE) refuse delivery |
| Self-signed or untrusted certificate | Senders that verify TLS refuse delivery |
| TLSA records no longer match the certificate (DANE) | DANE-validating senders refuse delivery |
| Old TLS version or weak cipher | Weaker transport security |
An alert is critical when a problem it reports stops delivery, and a warning otherwise. Only newly appeared problems trigger an alert, and the same problem isn't reported twice within 24 hours. A problem a server had in the last day isn't new, even when a check in between couldn't reach the server, and an expired certificate is left to the certificate expiry alert. Problems that already existed show on the domain's Checks → MX page but don't alert on every check.
When Alerts Arrive
MailShield checks every domain every 2 hours, so a DNS change is usually reported within about 2 hours. A removed record, a new score, mail servers that don't answer and an MTA-STS policy or BIMI logo that doesn't load need a second check to confirm them, so they can take up to about 4 hours. Run Checks on a domain counts as a check too: it raises the same change alerts as a scheduled check, and the next scheduled check doesn't repeat them. Failure-rate alerts follow shortly after a report arrives.
Where Alerts Go
| Destination | What you get | Plan |
|---|---|---|
| Notifications page | Every alert for the organization | All plans |
| The alert types you've switched on, as they happen. With the daily summary on, info and warning alerts come in one email a day and critical alerts right away | All plans | |
| Your channels | The alert types you've switched on, at or above each channel's minimum severity, in Slack, Microsoft Teams, Discord, Telegram, Matrix, Mattermost, Pushover, PagerDuty, Datadog or a webhook | Pro |
| Team channels | The alert types each channel chooses, at or above its minimum severity, on the same services. Owners and admins manage them, and they keep working when members leave or delete their account | Pro |
A destination that is both a team channel and someone's own channel gets each alert once. Scheduled Reports (daily, weekly or monthly PDF summaries) are separate from alerts. See Notifications.
Troubleshooting
Not Receiving Alert Emails
- Check your spam or junk folder.
- Make sure the alert type is switched on under Settings → Notifications. Settings are per organization, so check the organization you expect alerts for.
- If Daily summary is on, info and warning alerts arrive once a day, at 08:00 UTC.
- Make sure the domain is verified. Unverified domains don't send score, DNS change or certificate alerts.
Too Many Alerts
Switch off the alert types you don't need under Settings → Notifications, turn on the Daily summary to get info and warning alerts in one email a day, or set a channel to send only warnings and critical alerts. Switched-off alerts still appear on the Notifications page.