# Mimecast email security: what it does and what it cannot prove > Mimecast email security is a vendor email-security offering, but its name alone cannot prove a specific email is safe, encrypted, or legitimate. Mimecast email security is Mimecast's email-security product area. Mimecast describes email security as where it started and identifies "Email Threat Protection" as a capability area. That does not mean an email associated with Mimecast is automatically safe, legitimate, or encrypted. Those questions require evidence from the specific message, its sender context, and the receiving organization's security records. ## Quick takeaways - Mimecast describes email security as a core part of its platform. - Mimecast labels an email-related capability area "Email Threat Protection." - A sender name, logo, or claimed association with Mimecast is not message-level safety evidence. - An individual email needs its own headers, sender context, and recipient-side security evidence. - The available Mimecast material does not establish whether a particular message is encrypted. - An organization-level security score cannot verify one received email. ## How Mimecast email security fits into an email-security program [Mimecast's homepage](https://mimecast.com) describes email security as a long-running part of its platform and states: "Email security is where we started. It's still where we lead, backed by decades of threat intelligence and trusted by 42,000+ organizations." The same site labels an email-related solution area "Email Threat Protection." That establishes Mimecast as a vendor with an email-security offering. It does not establish the precise behavior of a particular control, the policy configured in a customer's tenant, or the result for one message. Those details depend on the relevant product documentation and the organization's own configuration. Mimecast's [Support Center](https://mimecastsupport.zendesk.com) presents its Knowledge Hub as an administrator resource with technical articles and how-to videos. Its current update categories include "Email Security - API-Based Protection," "URL Protection - Real-Time Scan Details Verdict Reporting," "Advanced BEC," and "Email Security MX." These category names show that the vendor maintains multiple email-security product areas. They do not, by themselves, document how each control evaluates mail or which controls protect a given recipient. Email security also extends beyond one vendor product. An email-security program may include domain authentication, recipient-side controls, user reporting procedures, and incident investigation. For that broader context, see Palisade's [email security guide](/learning/email-security) and the [email threats hub](/learning/threats). ![Decision flow showing that a Mimecast association alone cannot establish an individual email's safety, and that message-specific evidence is required](/images/editorial/mimecast-email-security/mimecast-email-security-message-evidence-flow.webp "1200x676") *Source: Palisade.* ## When a Mimecast association changes the answer The useful decision rule is narrow: an email can be assessed only from evidence about that email and its delivery path. A claim that the email is "from Mimecast," a Mimecast-branded footer, or a sender's statement does not provide that evidence on its own. The answer changes when you can examine message-specific records, such as: - The full message headers from the received message. - The exact sender domain and the reason the sender contacted the recipient. - Recipient-side security logs or a documented verdict for that message. - Official Mimecast documentation that applies to the observed product feature or status. This distinction matters because email-security systems are configured and operated per organization. A vendor's public description can explain its product area, but it cannot reveal what a recipient's tenant did with a particular message. > Do not treat a familiar vendor name as approval to open links, share credentials, or bypass your organization's reporting process. Preserve the message and use the recipient-side investigation process when it appears suspicious. If the question is about a business's overall controls rather than a single received email, use practical measures such as the ones in [email security best practices for businesses](/learning/best-email-security-practices-businesses). If the question is about another vendor's product category, [Abnormal email security](/learning/abnormal-email-security) provides a separate vendor-context explanation. ## Worked decision rule for a received email Use the following evidence object before deciding what an apparent Mimecast email means: ```text Claim: "This email is safe because it is from Mimecast." Available evidence: - Sender display name: insufficient - Mimecast branding or footer: insufficient - Vendor public product page: insufficient for this message - Full received headers: message-specific evidence - Recipient-side security logs: message-specific evidence - Documented verdict for the exact message: message-specific evidence Decision: Do not classify the email as safe, malicious, legitimate, or encrypted until message-specific evidence supports that conclusion. ``` The same rule applies to encryption. The available public material for this article does not state whether a particular Mimecast email is encrypted in transit, at rest, or through a secure-message workflow. It also does not establish which conditions or product options would apply. Treat encryption as unverified until the message evidence and the applicable official documentation support a conclusion. Likewise, do not try to rank a "most hacked email provider" from a vague phrase. That phrase has no defined measurement in the available primary material. A useful security review starts with the organization's actual exposure, controls, and observed incidents instead of an unsupported provider ranking. ## Check the evidence you actually have Start with the type of evidence in hand. If you have a suspicious received message, preserve it and review the full headers and recipient-side security records through your organization's established process. Do not rely on public vendor descriptions to classify the message. If you administer the domain or email environment, use Palisade's [Email Security Score](/tools/email-security-score) to inspect the organization's public-facing email-security posture. It is an organization-level check, not an individual-message verdict. Compare its result with your DNS configuration, then validate the real sending path with delivered-message evidence and any relevant administrative records. If the question is which Mimecast control handled a message, consult the applicable Mimecast Knowledge Hub article or administrator records for that tenant. The public update categories are not a substitute for the product-specific documentation and logs needed to explain one result. ## Review your broader email-security posture A vendor association cannot establish whether one email is safe. If your task is to assess the domain's broader public email-security posture, start with the evidence a public check can inspect. [Check your email security posture](/tools/email-security-score) A public posture check cannot prove that an individual email was legitimate, identify a recipient-side Mimecast verdict, confirm encryption, or predict future message placement. ## Sources and further reading - [Mimecast homepage](https://mimecast.com) - [Mimecast Support Center](https://mimecastsupport.zendesk.com) - [Palisade email security guide](/learning/email-security) - [Palisade Email Security Score](/tools/email-security-score) ## Frequently asked questions ### Is an email from Mimecast safe? Not necessarily. Mimecast's public material establishes that it provides email-security products, but it does not establish the safety of an individual email. Review the specific message's headers, sender context, and recipient-side security evidence before classifying it. ### What is Mimecast for email security? Mimecast describes email security as a core part of its platform and identifies "Email Threat Protection" as an email-related capability area on its [homepage](https://mimecast.com). Its [Support Center](https://mimecastsupport.zendesk.com) also lists maintained email-security product areas, but the precise behavior of each control requires the applicable product documentation. ### What is the most hacked email provider? Not verified. No authoritative measurement or definition in the available primary material identifies a provider as the "most hacked." Assess the controls and evidence relevant to your own email environment instead. ### Are Mimecast emails encrypted? Not verified. The available Mimecast material does not establish whether a specific email is encrypted, what type of encryption applies, or under which conditions. Confirm that question with message-specific evidence and the applicable official Mimecast encryption or secure-messaging documentation. ### Can an Email Security Score check a received Mimecast message? No. An [Email Security Score](/tools/email-security-score) assesses an organization's public-facing email-security posture. It cannot verify an individual message's sender, Mimecast verdict, encryption state, or recipient-side handling.