# Email security Proofpoint: what Core Email Protection covers

> Email security Proofpoint refers to Proofpoint's Core Email Protection, with API and secure email gateway options. Learn what evidence to request.

Proofpoint email security commonly refers to Proofpoint Core Email Protection, a product family that Proofpoint describes as deployable through an API-connected model or a secure email gateway. That description establishes product scope, not what any particular tenant detects, blocks, or allows. For an evaluation, separate the selected deployment model and authorized tenant evidence from public sender-domain evidence such as DMARC.

## Quick takeaways

- Proofpoint lists Core Email Protection separately from Email Fraud Defense and other products in its product directory.
- Proofpoint publicly describes API-connected and secure email gateway deployment choices for Core Email Protection.
- A product page does not show a specific tenant's policies, detections, false positives, or remediation results.
- A secure email gateway and an API-connected service need different architecture and evaluation questions.
- A public DMARC record can show a sender domain's published policy, but it cannot test an inbound Proofpoint deployment.
- DMARC authenticates use of the visible From domain. It does not replace inbound threat controls.

## How Proofpoint Core Email Protection works

[Proofpoint's Core Email Protection page](https://www.proofpoint.com/us/products/email-security-and-protection) describes email protection through two deployment approaches: an API-connected approach and a secure email gateway approach. The deployment choice changes where the security service participates in the mail environment and what an evaluator must validate.

A secure email gateway is part of the inbound and outbound mail path. The gateway architecture matters because mail routing, accepted domains, TLS behavior, and failure handling can affect production delivery. See [how secure email gateways protect an organization](/learning/how-secure-email-gateways-protect-organization) for the generic architecture rather than treating one vendor's marketing description as a universal gateway design.

An API-connected model integrates with a supported mail environment through its API rather than placing the same kind of gateway in the SMTP path. The public product description can establish that this option exists. It cannot establish which tenant permissions were granted, which policies are enabled, or how a tenant handled a particular message.

[Proofpoint's product directory](https://www.proofpoint.com/us/products) also separates Core Email Protection from Email Fraud Defense. That distinction matters when an evaluation involves sender-domain impersonation or DMARC. A claim about one named product should not be assumed to describe another Proofpoint product or service.

![Decision map separating Proofpoint API and secure email gateway deployment evidence from public DMARC sender-domain evidence](/images/editorial/email-security-proofpoint/email-security-proofpoint-evidence-map.webp "1200x676")

*Source: Palisade.*

## When the answer changes

The answer changes when the team can name the control it is evaluating and the evidence it can access.

Use this decision rule:

- If the question is about mail routing, SMTP-path inspection, or gateway failure behavior, evaluate the secure email gateway design with authorized tenant configuration and a controlled same-path message test.
- If the question is about an API-connected deployment, confirm the supported mail environment, authorized access, selected integration scope, and evidence from the tenant's approved test scenarios.
- If the question is about a domain's published DMARC policy, inspect public DNS and keep that result separate from inbound filtering evidence.
- If the question is about fraud defense or DMARC operations, confirm that the evaluation names the relevant Proofpoint product. Core Email Protection and Email Fraud Defense are distinct entries in Proofpoint's public product catalog.

A green status in a vendor tenant is not enough to prove that a real production message took the intended path. A public DNS lookup is also not proof of private tenant behavior. For wider product-category context, [email security](/learning/email-security) covers the controls that work together around mail systems.

## Worked evidence plan for a Proofpoint evaluation

Write down the deployment question before requesting results. The following is an illustrative evidence plan, not a vendor configuration.

```text
Product scope: Proofpoint Core Email Protection
Deployment question: API-connected service or secure email gateway?
Tenant evidence owner: Security administrator
Controlled test evidence: Approved message scenario and observed result
Mail-path evidence: Routing or API integration evidence for the selected model
Sender-domain evidence: Published DMARC record for yourdomain.com
Decision boundary: Public DMARC DNS does not prove Proofpoint detection or policy state
Rollback owner: Named change owner for any production routing or policy change
```

For a secure email gateway evaluation, collect evidence from the exact production or approved test path. Confirm the receiving environment, the gateway's role in mail flow, and what happens if the control is unavailable or a route is changed. A test sent through another path cannot prove the gateway's behavior.

For an API-connected evaluation, record the supported mail environment and the approved integration scope. Then test only the scenarios the tenant owner authorizes. Do not infer a detection result, policy setting, or false-positive rate from the public product page.

DMARC evidence has a different job. [RFC 9989](https://datatracker.ietf.org/doc/html/rfc9989) defines DMARC as a mechanism that evaluates SPF or DKIM authentication aligned with the visible From domain and applies the domain owner's published policy request after DMARC failure. It can help assess sender-domain authentication, but it does not inspect an inbound threat-control tenant.

If evaluating a broader set of inbound controls, [anti-phishing software](/learning/anti-phishing-software) is the adjacent buyer task. It should not substitute for an architecture-specific evaluation of the selected Proofpoint deployment.

## How should you verify the scope?

Start with the evidence you actually have.

If you have only a public sending domain, use a DNS check to record its published DMARC policy. That is useful context for sender-domain authentication and does not require access to a Proofpoint tenant. If you have an authorized Proofpoint evaluation, request tenant-specific evidence from the selected deployment model, approved message scenarios, and the real mail path.

For a production claim, validate at separate layers:

- DNS: Query authoritative DNS and at least one public resolver for the sender domain's DMARC record.
- Vendor: Obtain the authorized tenant's relevant integration and policy evidence.
- Message: Review an actual delivered test message from the exact path, including its raw headers where appropriate.
- DMARC: Review aggregate-report evidence after reports accumulate for the domain and sending paths in scope.

These layers answer different questions. A passing DMARC record does not prove inbound-filter effectiveness. A tenant status does not prove that a particular production message authenticated with an aligned domain.

## Check the public DMARC policy beside the evaluation plan

If the evaluation includes a domain you control, inspect its published policy before treating DMARC as part of the evidence plan.

[Check the domain's DMARC record](/tools/dmarc)

A public record check cannot inspect Proofpoint configuration, reproduce a detection, reveal private policy state, or prove inbound-filter effectiveness.

## Sources and further reading

- [Proofpoint Core Email Protection](https://www.proofpoint.com/us/products/email-security-and-protection)
- [Proofpoint product directory](https://www.proofpoint.com/us/products)
- [Proofpoint Core Email Protection solution brief](https://www.proofpoint.com/sites/default/files/solution-briefs/pfpt-us-sb-core-email-protection.pdf)
- [RFC 9989: Domain-based Message Authentication, Reporting, and Conformance](https://datatracker.ietf.org/doc/html/rfc9989)

## Frequently asked questions

### What is the most hacked email provider in the world?

No authoritative public ranking establishes one email provider as "the most hacked" worldwide. Reported incidents use different definitions, populations, and time periods. Assess a provider or deployment using its current security controls, your tenant configuration, identity protections, and evidence from the actual mail path.

### Is Proofpoint a legit company?

Yes. Proofpoint publicly maintains product documentation and a product directory that lists Core Email Protection and other email-security offerings. Legitimacy is different from product fit, so an evaluator should still verify the selected product scope, deployment approach, contract terms, and tenant-specific evidence.

### Who is Proofpoint's biggest competitor?

No single competitor is universally Proofpoint's biggest competitor because the answer depends on the product category, deployment model, geography, and buyer requirements. Define the exact task first, such as secure email gateway protection, API-connected email security, or DMARC operations, then compare products that address that task under the same evidence requirements.

### Does Outlook use Proofpoint?

No. Outlook is a Microsoft email client and service family, while Proofpoint is a separate security vendor. An organization can deploy Proofpoint with a Microsoft mail environment if the selected Proofpoint product and deployment model support that environment, but Outlook does not inherently use Proofpoint.

### Can a DMARC record prove that Proofpoint is protecting inbound email?

No. A DMARC record shows a domain owner's published sender-domain policy. It does not expose private Proofpoint configuration, show message detections, or test whether an inbound control handled a message as intended.