Obsidian Email SecurityDocumentation Sign in

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

EvidenceWeightHalf-lifeWhen
Confirmed phishing+4030 daysAn administrator reports spam on a phishing, BEC, malware or virus message (or one the AI called malicious), or claws a message back.
Confirmed spam+1514 daysAn administrator reports any other message as spam.
AI: malicious+207 daysThe model said phish, BEC, malware or scam with at least 85% confidence.
AI: spam+87 daysThe model said spam with at least 85% confidence.
SPF failed, no DKIM supporting+107 daysConnecting IP only; not when ARC vouches for a forwarder.
Reply-To elsewhere supporting+57 daysReply-To domain only.
Text matches a confirmed message+2514 daysThe message's links, domains and attachments, when its text matches a fingerprint (see below).
New to the network+5while trueA domain first seen by any organization in the last 24 hours.
Registered under 7 days ago+20while trueFrom the registry's RDAP record (see below).
Registered 7-30 days ago+10while trueFrom the registry's RDAP record.
Clean DMARC history (trust)-15while trueThe 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.

ScoreRuleEffect at default settings
0-29nonenone
30-59REP_SUSPICIOUS+2.5 points
60-84REP_BAD+8 points: quarantine on its own
85-100REP_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.