Proofpoint outage on August 14, 2026: DNS failure disrupts email worldwide

A DNS failure at Proofpoint broke email delivery for organizations around the world on August 14, 2026. Records for pphosted.com stopped resolving, so inbound and outbound mail routed through Proofpoint bounced or stalled for nearly four hours. StatusGator flagged the incident with an Early Warning Signal at 12:48 UTC, about an hour before Proofpoint acknowledged it publicly on its status page at 13:50 UTC. Here is what happened, who it hit, and how some teams kept mail moving.

Incident at a glance

Was Proofpoint down on August 14, 2026?

Yes. Proofpoint suffered a widespread outage on August 14, 2026, running from about 12:26 UTC to 16:08 UTC. The core failure was in DNS: hostnames under pphosted.com, the domain Proofpoint uses to route customer email, stopped resolving. Because so many organizations funnel their mail through Proofpoint for security filtering, a single DNS failure cascaded into email outages across thousands of companies at once.

What caused the Proofpoint outage?

The outage was a DNS resolution failure. Users consistently reported that DNS records for pphosted.com, including A and MX records, were missing or returning NXDOMAIN. With no records to resolve, mail servers could not find Proofpoint’s gateways, so messages bounced with lookup failures. Reports described it plainly:

• “DNS Records for their external hosted email got removed. Can’t resolve anything to pphosted.com” (Lexington, Kentucky)
• “nslookup on pphosted.com return no records” (New Orleans, Louisiana)
• “gslb.pphosted.com does not exist” (Chicago, Illinois)
• “They broke their DNS resulting in MX lookup failures” (Miami, Florida)

Proofpoint later published a service interruption notice confirming multiple services were affected by DNS resolution issues.

How long was Proofpoint down?

The disruption lasted roughly 3 hours and 42 minutes, from the first user report at 12:26 UTC to the last at 16:08 UTC. Proofpoint acknowledged the incident on its status page partway through, at 13:50 UTC, and mail flow gradually recovered as DNS records were restored and propagated.

Timeline of the August 14 Proofpoint outage (UTC)

Who was affected?

This was a broad, global outage that hit any organization relying on Proofpoint to route email. Because the failure was at the DNS layer, it did not spare a region or a single component. Reports came from across the United States and from the UK, Ireland, Germany, Denmark, Poland, Spain, France, Portugal, Finland, Switzerland, Türkiye, the UAE, India, Mexico, Brazil, and Canada.

The impact went beyond mail flow:

• Inbound and outbound external email failed, bouncing back as non-delivery reports (NDRs).
• The admin console and cloud portal became inaccessible or would not authenticate.
• Security tooling including TAP, TRAP, and the ThreatInsight portal was unreachable.

A snapshot of what users reported, from around the world:

• “All external email down” (Kernersville, North Carolina)
• “MX records don’t resolve” (Boston, Massachusetts)
• “Returning NXDOMAIN” (Paducah, Kentucky)
• “Getting NDR bouncebacks when sending to recipients that use Proofpoint” (Henderson, Texas)
• “Admin console inaccessible” (Forney, Texas)
• “mail flow is down” (São Paulo, Brazil)
• “Unable to send or receive email through Proofpoint” (New York, New York)

The workaround: how some teams kept mail moving

Because the failure was purely in DNS resolution rather than in the mail servers themselves, some administrators restored delivery by bypassing Proofpoint’s broken DNS. One admin in Vermont reported the fix directly: they created local A records pointing at the known IPs of their pphosted mail servers, instead of waiting for Proofpoint’s DNS to resolve.

If you are caught in a DNS outage like this, the emergency options are:

• Create temporary A records or host entries that map the affected pphosted hostnames to their last-known server IPs.
• Queue or spool outbound mail so messages retry rather than hard-bounce once resolution returns.
• Communicate to staff that external email is delayed, not lost, to cut down on duplicate sends.

One important caveat: hardcoding IPs is a short-term stopgap only. Remove those overrides once the provider’s DNS is healthy, because stale records will cause new delivery failures if the server IPs change.

How did StatusGator detect the outage early?

StatusGator sent its Early Warning Signal at 12:48 UTC, 62 minutes before Proofpoint publicly acknowledged the incident on its status page at 13:50 UTC. It works by pairing official status feeds with real-time user reports, so a spike in unofficial reports can trigger an alert before the provider posts anything public. A provider may be aware of and working an issue internally before it updates its status page, which is exactly why the public acknowledgment so often lags what users are already experiencing.

For an email security gateway, that hour of lead time is significant. Bouncing external mail can mean missed customer messages, failed order confirmations, and stalled business, so knowing early lets teams start their own mitigation, warn staff, and open a support case before the official notice even appears. Counting from the first user report at 12:26 UTC, the crowd knew a full 84 minutes before it was official.

For historical context, you can review Proofpoint’s outage history and the Proofpoint outage map to see how often these events happen and where they land.

Frequently asked questions

Monitor Proofpoint with StatusGator

If your organization depends on Proofpoint for email security, a DNS outage can silently stop mail for your entire company. StatusGator combines official status pages with real user reports and sends Early Warning Signals the moment a pattern emerges, often well before the provider confirms anything.

Start monitoring with StatusGator and get early warnings for the services your business depends on.