Reputation
Reputation remembers what your own evidence says about senders, domains and links, across every organization on the gateway. When one client's administrator confirms a phishing message, the next copy aimed at any client starts with a higher score.
What gets a score
- Sending IP
- The connecting server (an IPv6 address counts as its /64). Never the shared ranges of Microsoft 365, Google, Amazon SES, SendGrid, Mailgun, Mailchimp and similar platforms: the gateway reads their published SPF records every day.
- Sender domain
- The organizational domain of the From address. It only takes the blame when the From is authenticated (DMARC pass, or a matching DKIM or SPF pass), so a spoofed message never hurts the real domain.
- DKIM signing domain
- Every domain whose DKIM signature passed.
- Envelope sender domain
- The MAIL FROM domain, blamed only when SPF passed.
- Reply-To domain
- When replies would go to a different domain than the sender.
- Link domain
- Up to 15 link domains per message, with redirectors and Safe Links unwrapped.
- Attachment
- The SHA-256 of each attachment that can carry a payload (documents, archives, HTML, programs, SVG). Ordinary pictures are skipped: logos and signature images are shared by thousands of legitimate senders. File names are never stored.
Never scored: your organizations' own domains, free-mail providers, URL shorteners, the real domains of well-known brands, sending platforms and their link domains, plus anything in Settings › Reputation. Subdomains the public suffix list does not split, such as contoso.onmicrosoft.com or contoso.sharepoint.com, are scored as that one tenant.
Evidence
| Evidence | Weight | Half-life | When |
|---|---|---|---|
| Confirmed phishing | +40 | 30 days | An administrator reports spam on a phishing, BEC, malware or virus message (or one the AI called malicious), or claws a message back. |
| Confirmed spam | +15 | 14 days | An administrator reports any other message as spam. |
| AI: malicious | +20 | 7 days | The model said phish, BEC, malware or scam with at least 85% confidence. |
| AI: spam | +8 | 7 days | The model said spam with at least 85% confidence. |
| SPF failed, no DKIM supporting | +10 | 7 days | Connecting IP only; not when ARC vouches for a forwarder. |
| Reply-To elsewhere supporting | +5 | 7 days | Reply-To domain only. |
| Text matches a confirmed message | +25 | 14 days | The message's links, domains and attachments, when its text matches a fingerprint (see below). |
| New to the network | +5 | while true | A domain first seen by any organization in the last 24 hours. |
| Registered under 7 days ago | +20 | while true | From the registry's RDAP record (see below). |
| Registered 7-30 days ago | +10 | while true | From the registry's RDAP record. |
| Clean DMARC history (trust) | -15 | while true | The sender domain had DMARC-aligned mail judged clean for 90 days (on at least 10 days) before its first bad evidence. The only evidence that lowers a score. |
Domain facts (new, registered recently, clean history) only change the score of an entity that has evidence: a new domain on its own never scores. They count as strong evidence but belong to no organization, so they do not lift the organization cap. Example: one confident AI phishing verdict (+20) on a domain registered 3 days ago (+20) that first appeared today (+5) gives 45, capped at 40: suspicious for every organization at once.
- Supporting evidence only counts once the entity also has strong evidence, and is written at most once a day per organization. Forwarded and marketing mail fail these checks all the time.
- Users' own "Report spam" clicks (portal, Mail apps) train Bayes and are recorded, but only an administrator's report becomes reputation evidence.
- An administrator's Not spam report withdraws everything that message contributed and recomputes the scores at once.
- A clean AI verdict never lowers a score. Message content is written by the sender, and the model can be tricked.
- Weights and half-lives are tunable (
reputation.weights).
Message fingerprints
When an administrator reports a message as spam or claws it back, the gateway keeps a fingerprint of its text: the text is normalised (links, addresses and numbers flattened), cut into overlapping three-word pieces, and 32 keyed hashes of those pieces are kept. Never the text itself; the hash key is the server's own secret. New mail is compared on arrival: when at least 60% of the fingerprint agrees (setting reputation.fuzzy_threshold) the message scores REP_FUZZY (up to +9, by similarity), and its links, domains and attachments get fuzzy_match evidence (+25, half-life 14 days). So a campaign re-sent with fresh links, names or invoice numbers is caught, and its new links inherit the reputation.
- Fingerprints of spam only match mail of the organization that reported it; one client's unwanted newsletter is another's subscription. Phishing, BEC and malware fingerprints match for every organization.
- Texts under 12 words are not fingerprinted (too generic). The raw message must still be stored when it is reported.
- "Not spam" on the original removes its fingerprint; Protect › Reputation lists fingerprints with their matches and a Remove button. Fingerprints expire with the evidence (180 days).
Registration dates (RDAP)
RDAP is the registries' public successor to WHOIS. Every minute the worker looks up a few domains (setting reputation.rdap_per_minute, default 15) that were first seen in the network in the last 7 days or already carry a score; IANA's list says which server answers for each top-level domain. Answers are cached: 7 days while a domain is under 30 days old, a day after a failure, a month for a TLD without RDAP. Only the registration date and registrar are kept. Subdomains of shared hosting (such as evil.github.io) have no registration of their own and are skipped. The gateway needs outbound HTTPS to data.iana.org and the registries.
From evidence to a score
Each piece of evidence fades by half every half-life; the score is their sum, capped at 100. Until strong evidence comes from at least 2 organizations (setting reputation.min_tenants) the score stops at 40, unless an administrator confirmed it. So one client's reports can make a sender suspicious, never bad, for everyone. The worker recomputes scores every 5 minutes (confirmed reports at once), and the mail flow sees a change within a minute.
| Score | Rule | Effect at default settings |
|---|---|---|
| 0-29 | none | none |
| 30-59 | REP_SUSPICIOUS | +2.5 points |
| 60-84 | REP_BAD | +8 points: quarantine on its own |
| 85-100 | REP_MALICIOUS | +12 points: quarantine; reject only with other evidence |
A message gets at most one reputation rule, for its worst entity. The model never sees reputation results, because its verdicts feed reputation.
The Reputation page (Protect › Reputation, superadmins)
- List
- Every entity with a score, worst first, with its band, the evidence category and how many organizations contributed (a count only: no page shows which organizations).
- Entity page
- Every piece of evidence, its weight then and now, how the score adds up (incl. domain facts and trust), the domain's first sighting, registration date and clean DMARC history, and Recompute now.
- Overrides
- Block counts as 100; allow ignores the entity. Each needs a reason, can expire, and is in the audit log. For a hard decision on one sender, use Allow & block lists instead.
- Shared sending ranges
- How many platform ranges the gateway knows, when they were read and any platform whose record failed. Refresh now re-reads them.
What is stored
Only metadata: the entity (domain or IP), the kind of evidence, its weight, the organization's number, and a keyed hash of the message's Message-ID. Never message text, subjects, attachments or the model's summary. Evidence and AI verdicts are deleted after 180 days (reputation.evidence_days). Results from Spamhaus are never copied into reputation.