Abnormal email security

How the options were evaluated

The criteria below use current public primary sources checked on August 13, 2026. They do not treat vendor positioning as proof of a tenant outcome.

• Deployment model: Whether the option is described as API-connected cloud email security, an MX-routed gateway model, or sender-domain authentication.
• Evidence boundary: What a public description, DNS record, message, or tenant trial can establish.
• Operational review: What the buyer must verify about authorization, investigation, remediation, release, and rollback.
• Authentication scope: Whether the control validates sender-domain use, evaluates inbound messages, or both.
• Unknowns: Any tenant behavior, performance result, or configuration effect that public documentation does not establish.

Abnormal email security

Abnormal's Email Security product page describes a cloud email-security offering that uses behavioral models for people and vendors connected to an organization. The same public material describes API deployment and Microsoft 365 and Google coverage. Those are vendor statements about product positioning and deployment, not independently verified detection or remediation outcomes in every tenant.

• Best fit: Teams evaluating an API-connected cloud email-security product for Microsoft 365 or Google and prepared to review its proposed authorization and operating model.
• Relevant evidence: Abnormal's Inbound Email Security data sheet describes the vendor's Inbound Email Security offering and its behavioral approach. Check deployment statements against the buyer's own identity, permissions, and mail-handling requirements.
• Tradeoff: Public product material does not prove how a specific tenant's permissions, native controls, approved remediation actions, or false-positive workflow will behave.

MX-routed secure email gateway

An MX-routed secure email gateway is a separate architecture, not a synonym for API-connected cloud email security. A gateway evaluation asks how messages route through the service, how the service operates at the mail boundary, and how that path interacts with existing mail infrastructure. See what an email security gateway is for the three deployment models.

• Best fit: Teams whose planned security design depends on evaluating mail routing and gateway operation.
• Relevant evidence: A gateway assessment needs the documented mail path, authoritative DNS answers, configured MX records, and delivered messages from the actual production route.
• Tradeoff: Gateway evidence cannot be assumed to describe the permissions model or operational behavior of an API-connected product.

A green vendor status or a published DNS record is not proof that production messages follow the intended path. Validate the exact sending and receiving path with real delivered-message evidence before relying on a mail-flow change.

DMARC sender-domain authentication

DMARC, specified in RFC 9989, lets a domain owner enable validation of the domain used in a message's visible From field and publish handling preferences and reporting requests. This is a different control boundary from inbound behavioral email security.

• Best fit: Domain owners who need to publish sender-domain authentication policy and review authentication evidence for domains they control.
• Relevant evidence: The DMARC DNS record, a real message's authentication results from the production path, and aggregate reports after data accumulates.
• Tradeoff: DMARC does not establish whether an inbound product detected a particular impersonation attempt, handled a malicious attachment, or released a legitimate message.

_dmarc.yourdomain.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com"

How to choose

Choose Abnormal when the proposed API-connected deployment fits the tenant and the buyer can run an authorized evaluation with evidence for the operational questions that public product pages cannot answer. Choose a gateway approach when the required control point is mail routing. Use DMARC alongside either approach for sender-domain authentication, not as a replacement for inbound threat evaluation.

Use the same evidence scorecard for each option:

option: Abnormal email security
checked_on: 2026-08-13
best_fit: API-connected cloud email-security evaluation for Microsoft 365 or Google
verified_evidence:
  - Abnormal publicly describes API deployment
  - Abnormal publicly describes behavioral models for people and vendors
open_question: Tenant-specific permissions, message actions, false-positive handling, and rollback behavior
option: MX-routed secure email gateway
checked_on: 2026-08-13
best_fit: Mail-routing and gateway-operation evaluation
verified_evidence:
  - The buyer can document the intended MX and message path
open_question: Interaction with the tenant's existing routing and native controls
option: DMARC
checked_on: 2026-08-13
best_fit: Sender-domain authentication and policy publication
verified_evidence:
  - RFC 9989 defines visible From-domain validation, policy preferences, and reports
open_question: Which production senders authenticate and align after reports accumulate

Collect these items before deciding:

• The proposed connection and permissions scope, with approval from the relevant identity and security owners.
• A documented baseline for native email controls and the current mail path.
• Authorized representative cases, including known-good business messages and approved impersonation or compromised-account scenarios.
• Timestamps and evidence for investigation, remediation, release, and rollback for each scenario.
• A named evidence owner who can retain the results and approve any production change.

Check the published DMARC record beside the evaluation

Use Palisade's DMARC checker to inspect the published DMARC record for a domain in scope after documenting the current mail path and native-control baseline. Keep the result with the evaluation record so the team can distinguish sender-domain policy from inbound-filter evidence.

A public DNS check cannot evaluate Abnormal, inspect a tenant, reproduce a detection, measure message timing, test permissions, repair a false positive, monitor future tenant state, or prove inbound-filter effectiveness.