22 June 2026 · 6 min read
Proofpoint is a secure email gateway. Your mail leaves Microsoft 365, Google Workspace or your own server and is relayed out through Proofpoint's servers, so receivers judge Proofpoint's IP addresses and Proofpoint's DKIM signature, not whatever your mail platform did first. Before you enforce DMARC, your SPF record must authorise Proofpoint and Proofpoint must sign your mail with your own domain.
This guide is mainly about Proofpoint Essentials, where the SPF value is the same for every customer in a region. Proofpoint on Demand and on-premises Proofpoint Protection Server deployments use values specific to each customer, so take those from your Proofpoint deployment documentation. The DKIM and DMARC steps apply to both.
The Proofpoint Essentials SPF record
Proofpoint's help centre (sign-in required) gives one include per region:
| Essentials region | SPF mechanism |
|---|---|
| US instances | include:_spf-us.ppe-hosted.com |
| EU instance | include:_spf-eu.ppe-hosted.com |
For a domain whose mail all leaves through Proofpoint Essentials in the US:
v=spf1 include:_spf-us.ppe-hosted.com ~allIf some mail still goes out directly, for example from Microsoft 365 or a marketing platform, add those senders to the same record:
v=spf1 include:_spf-us.ppe-hosted.com include:spf.protection.outlook.com ~allOlder Proofpoint guides use a:dispatch-us.ppe-hosted.com or a:dispatch-eu.ppe-hosted.com instead. Both forms authorise the same servers: the _spf-us.ppe-hosted.com record itself contains a:dispatch-us.ppe-hosted.com. The a: form uses one DNS lookup and the include uses two. Use one of them, not both.
Two SPF rules from RFC 7208 catch people out when they add Proofpoint:
- One SPF record per domain. A second
v=spf1record makes SPF return a permanent error for every sender. Merge the Proofpoint mechanism into the record you already have. - Ten DNS lookups at most. Proofpoint plus Microsoft 365 plus a few SaaS senders can pass ten, which also returns a permanent error.
The SPF checker shows both problems and counts the lookups.
DKIM signing in Proofpoint Essentials
DKIM is the mechanism to rely on through a gateway, because the signature travels with the message and survives the relay hop and most forwarding. Proofpoint Essentials signs outbound mail with a key you create for each domain:
- In the Essentials admin console, open the DKIM settings for your domain and create a new DKIM signing key, choosing a selector name.
- Publish the TXT record Proofpoint shows at
<selector>._domainkey.example.com. Essentials only supports 2048-bit keys, so the value is longer than the 255-character limit of a single DNS string. If your DNS host rejects it, split it into quoted strings with the DNS record splitter. - Back in Proofpoint, choose Verify Key from the key's menu. Once the key verifies, outbound DKIM signing is switched on for that domain automatically.
s1._domainkey.example.com. TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A..."Because the key is published under your domain, Proofpoint's signature carries d=example.com and aligns with a From address on example.com. Each domain you send from needs its own key. Check the published key with the DKIM checker, then send a message to an outside mailbox and confirm the DKIM-Signature header shows your domain.
On Proofpoint on Demand and Protection Server, DKIM keys are generated in the administration interface for your deployment. The DNS record and the alignment logic are the same.
Does SPF align through Proofpoint?
DMARC passes if SPF or DKIM passes and aligns with the From domain. SPF alignment depends on the envelope sender (Return-Path) on the relayed message:
- If the envelope sender stays on your domain, SPF is checked against your record, passes through the Proofpoint mechanism, and aligns.
- If the envelope sender is on a Proofpoint domain, SPF passes for Proofpoint but does not align with your From address.
Proofpoint's public documentation does not settle which applies to every deployment, so check yours. Open a message you sent to a Gmail or Outlook address and read the Authentication-Results header: smtp.mailfrom= is the domain SPF was checked against. Your DMARC reports show the same domain for every source. Either way, DKIM alignment from the previous section is what keeps Proofpoint-relayed mail passing DMARC.
Publish DMARC and read the reports
Start in monitoring mode at _dmarc.example.com:
v=DMARC1; p=none; rua=mailto:dmarc-reports@example.comLeave adkim and aspf out so both stay relaxed. While the reports come in, look for three things:
- Rows from Proofpoint's servers show DKIM pass with your domain. If DKIM is missing, the key was never verified or signing is off for that domain.
- The SPF domain on those rows. Your own domain means SPF aligns too. A Proofpoint domain means only DKIM is carrying the message, which is enough.
- Legitimate mail that does not go through Proofpoint. Applications, printers or a platform sending directly will show other IP addresses. Route them through Proofpoint or give them their own SPF and DKIM before you enforce.
The DMARC report analyser turns the XML into a per-source view.
Quarantine, then reject
When every legitimate source passes, change the policy to p=quarantine, then to p=reject once quarantine has run cleanly:
v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.comThe current DMARC standard, RFC 9989, suggests at least a month at p=none and a similar period at p=quarantine. It removed the old pct= tag; to trial a stricter policy, add t=y, which asks receivers to apply one level less. It also says domains whose users post to mailing lists SHOULD NOT publish p=reject.
Inbound filtering is a separate job
Proofpoint also filters the mail you receive, and can apply other domains' SPF, DKIM and DMARC results to it. That configuration protects your users from spoofed inbound mail. It has no effect on whether your own outbound mail passes DMARC at other receivers.
Proofpoint troubleshooting
- SPF permanent error after adding Proofpoint: two SPF records, or more than ten lookups. Merge the records, or switch the include to the one-lookup
a:form. - No DKIM signature on Proofpoint rows: verify the key again and check signing is enabled for that domain.
- SPF passes but does not align: the envelope sender is a Proofpoint domain. Rely on DKIM.
- Some mail aligns and some does not: a sending path is bypassing Proofpoint, or a second domain has no key.
Run the DMARC checker to see your current record. Related reading: DMARC for Microsoft 365 for the platform behind many Proofpoint deployments, and why DMARC fails when SPF and DKIM pass. Hosted DKIM covers key generation and selectors for the other services that send as your domain.