Back to Learning Center Email Authentication

Zix email security: what the name means today

By Samuel ChenardJuly 28, 20268 min read

Ask AI to explain

In brief

Zix email security now sits within OpenText Cybersecurity. Learn what its encryption service does and where SPF, DKIM, and DMARC differ today.

Zix email security: what the name means today

Zix email security is a legacy name now represented within OpenText Cybersecurity. OpenText says Zix is formally part of the OpenText family, while established support and account portals remain available. The current related offering is OpenText Core Email Encryption, which applies policy-based actions to outbound email. Choose it when the question is how content is protected. Use SPF, DKIM, and DMARC when the question is whether a domain is authorized to send mail.

At a glance

Quick takeaways

Zix is formally part of OpenText, though established Zix portals remain available.
OpenText Core Email Encryption describes policy actions that can encrypt, quarantine, or block outbound email.
Encryption protects message content according to policy. It does not authenticate the visible From domain.
SPF, DKIM, and DMARC address sender-domain authorization and authentication.
A public DNS check cannot prove why an OpenText or Zix tenant handled one message in a particular way.
A delivered message and the tenant's policy evidence are needed to validate an individual encryption outcome.

Who this comparison is for

This comparison is for administrators, procurement teams, and recipients who encounter the Zix name in an old portal, a notification, vendor documentation, or an internal security discussion. The immediate task is to identify what the name refers to today and decide whether the remaining question belongs to email encryption or sender-domain authentication.

The distinction matters when an organization sees an encrypted message and assumes it came from an authenticated sender. Those are separate observations. An encryption service can protect content after its policy evaluates a message. DMARC evaluates use of the author domain and publishes the domain owner's requested handling for failures.

This is not a general email-security platform comparison. For broader managed DMARC product evaluation, see Palisade's DMARC software comparison hub. The decision here is narrower: does the evidence point to an OpenText encryption-policy question or a public domain-authentication question?

How the options were evaluated

The options were evaluated against current first-party documentation and protocol specifications, checked August 13, 2026.

Product context: Whether the source identifies the current relationship between Zix and OpenText.
Security job: Whether the documented capability protects message content or validates sender-domain use.
Evidence available: Whether a public domain name, a tenant policy record, or a delivered message is required.
Validation boundary: What the result cannot establish about a particular message, recipient, or future delivery.
Operator fit: Which team can act on the finding.

A documented capability counts as available for the purpose described by its publisher. Tenant-specific policy, licensing, deployment details, and the exact handling of an individual message remain unknown unless the organization operating the service confirms them.

OpenText Core Email Encryption

OpenText's Zix legacy information page states that Zix is formally part of the OpenText family and that established support and account portals remain available. That explains why the Zix name can still appear in operational material while current product information is published under OpenText Cybersecurity.

OpenText's Core Email Encryption product page describes DLP filters and policy actions that can encrypt, quarantine, or block outbound email. The same page describes delivery options and reporting for encryption triggers and message handling. These are policy-controlled capabilities. The public product description does not establish which policy a particular tenant has configured.

OpenText Core Email Encryption product page showing the public product context for policy-based outbound email protection — Source: OpenText Core Email Encryption, checked 2026-07-28.

Best fit: An organization that needs policy-based protection for outbound message content and uses OpenText or legacy Zix services.
Relevant evidence: OpenText documents DLP filters, policy actions to encrypt, quarantine, or block email, delivery choices, and reporting on triggers and handling.
Tradeoff: A public product page cannot show why a specific tenant encrypted, quarantined, blocked, or delivered one message. That answer requires the operating organization's policy evidence and the message path.

For a recipient, a Zix-branded notification is a reason to verify the sender and follow the sending organization's support instructions. It is not proof that the sender is legitimate. For an administrator, the legacy name is a product-context clue. It does not identify the exact service edition or the policy that applied to a message.

Do not change DNS records because an encrypted-message notification was received. First establish whether the problem is message-content handling or sender-domain authentication.

Domain authentication with SPF, DKIM, and DMARC

Encryption and domain authentication can both be present on the same message. Neither result proves the other.

RFC 9989's DMARC specification defines DMARC as a protocol for validating an author domain's use, communicating a handling preference for failed validation, and requesting reports. In operational terms, DMARC helps a domain owner publish an authentication policy. It does not report an encryption tenant's policy or determine whether content was protected.

Best fit: A domain owner investigating spoofing resistance, sender authorization, alignment, or DMARC policy.
Relevant evidence: SPF records identify hosts authorized to use a domain in SMTP HELO and MAIL FROM identities under RFC 7208. DKIM verification retrieves a public key from the claimed signing domain under RFC 6376. DMARC evaluates aligned authentication results for the author domain.
Tradeoff: DNS records alone do not prove that a particular production message used the intended sending path, signed successfully, or received a specific mailbox provider outcome.

Use this evidence map to keep the two jobs separate:

Technical exampletext

Question: What does "Zix email security" mean in this environment? Evidence: OpenText legacy information and the operating organization's records. Next action: Confirm the current service and support path. Question: Why was one message encrypted, quarantined, or blocked? Evidence: Tenant policy, audit records, and the exact message path. Next action: Ask the organization that operates the OpenText or Zix service.

Question: Is a domain publicly publishing authentication controls? Evidence: Public DNS for SPF, DKIM, and DMARC. Next action: Inspect the domain records, then validate a real delivered message.

Authentication evidence map separating public DNS checks from tenant policy and delivered-message evidence — Source: Palisade.

A domain owner can use Palisade's Email Security Score to inspect the public DNS posture for a domain. That is useful when the available evidence is only a domain name. It does not inspect OpenText policy, prove that an individual message was encrypted, reveal a recipient's experience, or predict future delivery.

How to choose

Choose OpenText Core Email Encryption when the unresolved question concerns protected content, policy-triggered handling, delivery choices, or an existing Zix-branded service relationship. Choose domain authentication work when the unresolved question concerns who may use a domain, whether messages authenticate with aligned identifiers, or the domain owner's requested handling of failed authentication.

Use the following checks before assigning the issue:

Confirm whether the observed evidence is a vendor notification, a tenant-policy event, a raw delivered message, or a public domain name.
Route tenant-policy questions to the organization operating the OpenText or Zix service.
Route a public domain question to SPF, DKIM, and DMARC inspection.
Validate a claimed production result with a real delivered message from the exact sending path.
Review DMARC aggregate-report data after it accumulates. Public DNS and a vendor status indicator are not message-level validation.

YAMLyaml

option: OpenText Core Email Encryption
checked_on: 2026-08-13
best_fit: Policy-based protection of outbound email content
verified_evidence: OpenText documents DLP filters, encrypt, quarantine, and block actions, delivery choices, and reporting
open_question: Which policy, entitlement, and message outcome apply in a specific tenant

YAMLyaml

option: SPF, DKIM, and DMARC
checked_on: 2026-08-13
best_fit: Public sender-domain authorization, signing, alignment, and DMARC policy
verified_evidence: RFC 7208, RFC 6376, and RFC 9989 define the separate protocol roles
open_question: Whether a specific production message followed the expected path and how a receiver handled it

The four validation layers are distinct:

DNS: Query the authoritative DNS source and at least one public resolver for the published SPF, DKIM, and DMARC records.
Vendor: Review the current OpenText or Zix tenant status and policy evidence with the organization that operates the service.
Message: Inspect a real delivered message from the exact production path, including its authentication results and raw headers.
DMARC: Review aggregate-report data once enough mail has been processed to identify sending sources and alignment outcomes.

Evidence

Sources and further reading

Questions readers ask

Frequently asked questions

Is Zix still a separate company?

No. OpenText's Zix legacy information page says Zix is formally part of the OpenText family. Established support and account portals remain available, so older operational material can still use the Zix name.

Is Zix email security the same as OpenText Core Email Encryption?

Not necessarily. Zix is a legacy brand context, while OpenText's Core Email Encryption page documents its current policy-based encryption offering. Confirm the actual product and policy with the organization operating the service.

Does an encrypted message prove the sender is legitimate?

No. Encryption can protect message content under a policy, but it does not prove that the visible From domain passed SPF, DKIM, or DMARC authentication. Sender-domain identity requires separate authentication evidence.

Can a DMARC check show whether Zix encrypted a message?

No. DMARC evaluates author-domain authentication and publishes a requested handling policy for failed validation. It cannot inspect an OpenText or Zix tenant's encryption policy or prove how a particular message was handled.

Should a recipient trust a Zix notification link?

Only after confirming that the sender and message are expected. Use the sending organization's documented support route when help is needed to access an encrypted message. A notification alone does not establish that a message is trustworthy.