Proofpoint Essentials SPF: what to add when outbound mail relays through Proofpoint

When an MSP routes a client's outbound mail through Proofpoint Essentials, the receiving server sees Proofpoint's IP addresses, not Microsoft's or Google's. The client's SPF record has to authorize Proofpoint, or outbound mail that used to pass SPF starts failing it. This page covers what Proofpoint's public getting-started guides say, what's live in DNS today, and how to merge the entry without breaking the record. It covers Proofpoint Essentials only. Proofpoint's enterprise products are configured per customer, so take those values from the client's own Proofpoint documentation or support team.

What Proofpoint's public guides say

Proofpoint's Getting Started Guide PDFs for Essentials, hosted on proofpoint.com, list the SPF entry by data stack:

These guides are old. The PDF metadata shows creation dates of August 2016 for US1 and EU1, and a January 2017 revision of US1. They're still the Essentials SPF reference publicly available on Proofpoint's site, but check them against the client's Essentials admin console, which is the authority for that account.

Note that the guide's entry is an a: mechanism, not an include. a:dispatch-us.ppe-hosted.com authorizes whatever IP addresses that host name resolves to.

What's in live DNS: the _spf-us and _spf-eu includes

On Oct 13, 2026, a live DNS check found two include-style hosts:

• _spf-us.ppe-hosted.com → v=spf1 a:dispatch-us.ppe-hosted.com ~all
• _spf-eu.ppe-hosted.com → v=spf1 a:dispatch-eu.ppe-hosted.com ~all

So include:_spf-us.ppe-hosted.com wraps the same a:dispatch-us entry the guide documents. Partner knowledge bases from Proofpoint resellers describe the include form as the newer recommended format, and the a:dispatch form as "still supported." We couldn't find that recommendation in Proofpoint-hosted public documentation. Treat it as partner guidance confirmed by DNS, not as a Proofpoint statement.

Lookup cost:

• a:dispatch-us.ppe-hosted.com placed directly in the record costs one lookup.
• include:_spf-us.ppe-hosted.com costs two: the include itself, plus the a: lookup inside it.

The include's advantage is that Proofpoint can change what's behind it without you editing the client's record. On a record close to the limit of 10, the direct a: entry saves a lookup. Both are DNS observations, not documented guarantees.

Inbound-only clients don't need the entry

SPF authorizes the servers that send mail for a domain. If a client uses Proofpoint Essentials only for inbound filtering, so their MX records point to Proofpoint but outbound mail still leaves directly from Microsoft 365 or Google, Proofpoint isn't sending anything for them and the SPF record doesn't need a Proofpoint entry. Adding one anyway authorizes IP addresses that never send the client's mail, and spends a lookup. That's the kind of drift the first paragraph of RFC 9989 §7.1 addresses: domain owners "should periodically review their SPF records" so the authorization matches current needs.

So before you edit anything, check two things. Is an outbound connector or smart host actually pointed at outbound-us1.ppe-hosted.com (or EU1)? And do the DMARC aggregate reports show the client's mail arriving from Proofpoint IPs? Add the entry only if outbound relaying is on, or about to be turned on.

Merging into a Microsoft 365 or Google record

Keep one SPF record per domain. A second v=spf1 record is a permerror under RFC 7208 §4.5. For a Microsoft 365 tenant whose outbound mail now relays through Essentials US:

```

v=spf1 include:spf.protection.outlook.com a:dispatch-us.ppe-hosted.com -all

```

or, with the include form:

```

v=spf1 include:spf.protection.outlook.com include:_spf-us.ppe-hosted.com -all

```

Whether to keep the Microsoft or Google include depends on whether any mail still leaves directly from them. Proofpoint's smart-host relay sends outbound mail through Proofpoint, but other things on the tenant may not follow that path. Journaling, some connectors and some apps can still send direct. Check DMARC aggregate reports for direct Microsoft or Google traffic before you remove their include.

Keep the client's existing -all or ~all ending. The ~all in Proofpoint's guide applies when that's the whole record. If you're tightening it, the second paragraph of RFC 9989 §7.1 notes that -all can cause some receivers to reject mail at SPF time, before DMARC is evaluated, and those rejections never show up in aggregate reports. Make sure DKIM is working first.

Order of operations for an outbound cutover

1. Add the Proofpoint entry to the existing SPF record before you point outbound mail at the smart host. Proofpoint's guide lists SPF alongside the smart-host details for this reason.
2. Wait for the record's TTL to expire.
3. Switch the outbound connector or smart host to outbound-us1.ppe-hosted.com (or EU1).
4. Send test messages to external mailboxes and read the Authentication-Results headers. You want spf=pass, dkim=pass for the client's domain, and dmarc=pass.
5. Watch the DMARC aggregate reports for a week for SPF failures from Proofpoint IPs.

DKIM and DMARC alignment

DMARC (RFC 9989) passes when SPF or DKIM passes and the authenticated domain aligns with the From: domain. SPF through Proofpoint aligns if the envelope sender stays on the client's domain. DKIM is the safer path, because RFC 9989 says domains publishing p=reject must not rely solely on SPF. If DKIM is applied by Microsoft 365 or Google before mail reaches Proofpoint, confirm that the relay doesn't modify messages (for example, by adding footers or disclaimers) in a way that breaks the body hash. Check the test headers for dkim=pass.

Check the client's SPF now

Run the free SPF checker →

It walks the include tree, counts DNS lookups against the RFC 7208 limit of 10 (including a: and nested lookups), and flags duplicate records and +all or ?all endings.

Founding Partner: $1,999, one time. Track SPF, DKIM, and DMARC on every client you've moved behind a gateway, with alerts when a record changes. Founding Partner covers 50 client domains with full branding (logo and colors), weekly rescans and change alerts, unlimited Security Briefs (150 prospect scans a month), the Grow toolkit, the Policy library, a branded service menu, webhooks, the API, and MCP access (except quote drafts). If you later subscribe to Pro, you pay $299/mo instead of $399 for as long as that Pro subscription stays active. The offer is capped at 50 seats and closes on Dec 15, 2026, or when all 50 seats are claimed, whichever comes first. Proposals and the Service Library require Pro. Founding Partner is non-refundable, except that you're refunded if the seats run out before your payment can be fulfilled.

See Founding Partner details →