Email authentication for Proofpoint: SPF, DKIM and DMARC

30 April 2026 · 18 min read

Proofpoint is not a typical email service provider, and that single fact changes everything about how you authenticate mail that flows through it. SendGrid, Mailgun and Amazon SES are platforms you send from. Proofpoint is a secure email gateway that sits in front of your existing mail, relaying outbound messages from Microsoft 365, Google Workspace or an on-premises Exchange through its infrastructure on the way to the internet. That relay step is exactly where SPF, DKIM and DMARC alignment quietly breaks if you do not configure it deliberately.

This guide is Proofpoint-specific and covers both products people mean when they say "Proofpoint": Proofpoint Essentials (the cloud gateway aimed at small and mid-size organisations) and the enterprise Proofpoint Protection Server, also called Proofpoint Email Protection or PPS/PoD. The SPF mechanism, the DKIM signing workflow and the selectors differ between the two, so the article calls out which is which. By the end you will know the exact SPF entry to publish for your region or cluster, how to generate and verify a DKIM key inside Proofpoint, why the gateway breaks SPF alignment unless you handle the return path, and the staged route to p=reject with Proofpoint in the path.

Before you change anything, get a baseline. Run your domain through the DMARC checker, the SPF checker and the DKIM checker so you can see what Proofpoint is currently doing to your authentication before and after each change.

Why a gateway is different: alignment, not just "pass"

DMARC does not care whether SPF or DKIM merely pass. It cares whether they pass and align with the domain in the visible From: header. There are two alignment checks and DMARC needs only one to succeed:

• SPF alignment: the domain in the SMTP envelope sender (the Return-Path, also called MAIL FROM or the bounce address) must match your From: domain, by organisational domain under relaxed alignment.
• DKIM alignment: the domain in the d= tag of a valid DKIM signature must match your From: domain, by organisational domain under relaxed alignment.

Here is the Proofpoint-specific catch. When Proofpoint relays your outbound mail, the message leaves Proofpoint's IP addresses, not your own. If your SPF record still only authorises Microsoft 365 (include:spf.protection.outlook.com) or Google (include:_spf.google.com), then the relayed message arrives at Gmail or Yahoo from a Proofpoint IP that your SPF does not list. SPF therefore fails unless you add Proofpoint's sending hosts to your SPF record. And even when SPF passes for the Proofpoint host, it only counts for DMARC if the envelope domain aligns with your From:, which depends on how the return path is handled.

That is why, on a gateway, you cannot lean on whatever authentication your underlying platform did before. The gateway is now the last hop, and its IPs and its signature are what receivers evaluate. For the deeper mechanics of why pass and align differ, see DMARC alignment explained.

SPF for Proofpoint: the exact mechanism for your product

This is the part where Proofpoint diverges sharply from a normal ESP, and where most Proofpoint SPF records are wrong.

Proofpoint Essentials: use the a: mechanism, not an include

Proofpoint Essentials sends outbound mail from a rotating cluster of IP addresses mapped to a regional dispatch hostname. Because the IPs rotate, Proofpoint does not give you a static ip4: list or a normal nested include:. Instead you add an a: mechanism that resolves the dispatch hostname's A records at evaluation time:

; US data centre
v=spf1 a:dispatch-us.ppe-hosted.com -all

; EU data centre
v=spf1 a:dispatch-eu.ppe-hosted.com -all

The region matters. If your Proofpoint Essentials tenant lives in the EU, the US mechanism will not list the right IPs and your mail will fail SPF. Use the dispatch hostname that matches the data centre your account was provisioned in, which is shown in your Proofpoint setup or deployment information. The outbound-us1.ppe-hosted.com and outbound-eu1.ppe-hosted.com hostnames you may also see are the smart-host relay destinations you point your own mail server at; they are not the SPF mechanism. Keep the two roles separate: the smart host is where your mail goes, the a:dispatch-* mechanism is what you publish in SPF.

If you send through other services as well, combine them in one record. A domain relaying Microsoft 365 mail out through Proofpoint Essentials US, plus a CRM, looks like this:

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

Proofpoint Protection Server / Email Protection: the cluster include

The enterprise product is different again. Proofpoint Protection Server uses a cluster-specific include that is unique to your deployment. It takes the form:

include:spf-<clusterid>.pphosted.com

The <clusterid> is not something you can guess; it is printed in the Deployment Information email Proofpoint sends when your tenant is provisioned (for example a hostname like spf-0123abcd.pphosted.com). A typical enterprise record that relays Microsoft 365 out through PPS:

v=spf1 include:spf-0123abcd.pphosted.com include:spf.protection.outlook.com -all

SPF gotchas that bite specifically with Proofpoint

• One SPF record only. Two separate v=spf1 TXT records on the same name is a permerror and breaks SPF entirely. Merge into a single record. This is the most common cause of the dreaded 550 5.7.1 SPF rejection on Proofpoint Essentials outbound.
• Mind the 10-lookup limit. The a: mechanism is cheap (one lookup), but the PPS include:spf-<clusterid>.pphosted.com expands and, stacked with Microsoft 365, Google and a couple of SaaS tools, can push you over SPF's hard limit of ten DNS lookups, producing a permerror. Check the live count with the SPF checker and read SPF PermError: the 10-lookup limit. If you are over, how SPF flattening works is the fix, and our SPF flattening product keeps the record flat and under the limit automatically as Proofpoint's IPs rotate.
• -all once you are confident. While you are still discovering senders, ~all (softfail) is the cautious default. The end state for a locked-down domain is -all.
• The a: mechanism still needs alignment. Adding a:dispatch-us.ppe-hosted.com makes SPF pass for Proofpoint's hosts. Whether it aligns for DMARC depends on the envelope domain, covered below.

The SPF generator will assemble a single valid record from your sender list if you would rather not hand-edit.

Enabling DKIM signing in Proofpoint

DKIM is the layer you should rely on most through a gateway, because DKIM survives the relay hop and survives forwarding, where SPF often does not. Both Proofpoint products sign outbound mail with DKIM, but you have to switch it on and publish a key; neither does it silently.

Proofpoint Essentials DKIM

In the Essentials admin interface you create the key per domain:

1. Open the domain, find the DKIM section and click Create New DKIM Signing Key.
2. Proofpoint asks for a selector. A value is pre-populated (commonly a short label such as s1), and you can change it to anything you like, for example pps1 or ppe2026. The selector is only used to locate the public key in DNS and is never visible to recipients.
3. Proofpoint generates the key pair and shows you a hostname and a value to publish in your DNS zone. It also offers to let you save the private key to a secure location. This is the only time the private key is displayed, so save it if your change-control process requires an escrow copy.
4. Publish the DNS record exactly as shown, then return to Proofpoint and click Verify Key in the key's context menu. Once Proofpoint confirms the record resolves, outbound DKIM signing is automatically enabled for that domain.

The DNS record you publish is a standard DKIM TXT record under your chosen selector:

s1._domainkey.yourdomain.com.  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A..."

The key detail for alignment: because you publish this key under your own domain and Proofpoint signs with d=yourdomain.com, the signature aligns with a From: of you@yourdomain.com. That is what carries you to enforcement.

Proofpoint Protection Server / Email Protection DKIM

The enterprise workflow lives under Email Protection > Email Authentication > DKIM Signing. The mechanics:

1. Go to the Keys tab and click Generate Key.
2. Specify a unique domain and a unique selector (each key must be unique within the domain), the scope, and the policy routes the signing applies to. Proofpoint-generated keys are 2048-bit RSA.
3. In the DNS Text Record column, use View to display the public key, then copy it into your DNS zone as a TXT record under <selector>._domainkey.yourdomain.com.
4. Enable signing on the General tab.

There is one critical PPS-specific trap. If you also use Proofpoint to evaluate inbound SPF, DKIM and DMARC, you must exclude the inbound policy routes from DKIM signing. In practice that means disabling DKIM signing processing on the default_inbound route. If you sign inbound mail you will corrupt messages and create confusing failures. Sign outbound routes only.

For why DKIM is the layer that survives relays and forwarding, and why key length matters, see DKIM, alignment and forwarding and DKIM key rotation. Confirm the selector and signature your mail actually carries with the DKIM checker, and read the broader rationale on the DKIM product page.

The return-path problem: making SPF align through the gateway

This is the most-missed Proofpoint step and the reason so many Proofpoint senders show SPF pass but SPF not aligned in their DMARC reports.

When Proofpoint relays your message, it may rewrite or preserve the envelope sender depending on configuration. The two outcomes:

• If the envelope Return-Path stays on your domain (for example bounces@yourdomain.com or a subdomain like bounce.yourdomain.com), then SPF authenticates your domain. As long as your SPF record includes the right Proofpoint mechanism (a:dispatch-* for Essentials, include:spf-<clusterid>.pphosted.com for PPS), SPF passes and aligns, because the envelope domain shares your organisational domain with the From:.
• If Proofpoint relays with an envelope on a Proofpoint-owned domain (a .ppe-hosted.com or .pphosted.com bounce address), SPF authenticates Proofpoint's domain. That passes, but it does not align with your From:, so it counts as an SPF failure for DMARC.

The practical implication: do not rely on SPF alignment through a gateway unless you have confirmed, in real DMARC reports, that the envelope domain is yours. In many Proofpoint deployments the envelope is preserved and SPF does align; in others, especially where Proofpoint applies bounce-address rewriting, it does not. Either way, DKIM alignment from the previous section is your guaranteed path, because the d=yourdomain.com signature aligns regardless of what happens to the envelope on the relay hop.

The belt-and-braces position is to have both: aligned DKIM (always achievable with a key under your domain) and aligned SPF (achievable when the return path stays on your domain). With both, a single broken link does not fail the message. If a downstream forwarder breaks DKIM, aligned SPF can still carry it; if the gateway rewrites the envelope and breaks SPF alignment, aligned DKIM carries it. Verify which you actually have using the DMARC report analyzer once reports start arriving.

A subdomain strategy for gateway-relayed mail

A clean pattern, especially for organisations relaying a single corporate mail platform through Proofpoint, is to keep the apex SPF lean and align everything on the organisational domain by relaxed alignment, which is the DMARC default. You usually do not need a separate sending subdomain for Proofpoint the way you might for a bulk ESP, because Proofpoint is relaying your existing corporate identity (you@yourdomain.com), not a marketing stream.

What does help:

• Keep adkim=r and aspf=r (relaxed) so a bounce subdomain like bounce.yourdomain.com and a DKIM d=yourdomain.com both align with the apex From:.
• If you run multiple brands or business units behind one Proofpoint tenant, generate a separate DKIM key and selector per domain. Proofpoint requires a unique selector per domain anyway, and per-domain keys keep each brand's alignment independent.
• For any genuinely separate bulk or marketing stream that does not go through Proofpoint, use a dedicated subdomain and its own policy. See the subdomain DMARC record and the sp tag.

Publishing DMARC and starting at p=none

With Proofpoint signing DKIM under your domain (and ideally SPF aligning through a preserved return path), publish DMARC in monitoring mode first so you can watch Proofpoint's real alignment before you enforce. A starter record at your apex:

_dmarc.yourdomain.com.  TXT  "v=DMARC1; p=none; rua=mailto:reports@yourdomain.com; fo=1; adkim=r; aspf=r"

What each tag does in the Proofpoint context:

• p=none means observe only, take no action on failures yet. This is your listening phase, where you discover whether Proofpoint-relayed mail aligns and whether any sender is bypassing the gateway.
• rua= is where aggregate XML reports are sent. Point it somewhere you will actually read. If you want those reports parsed into plain English with per-source pass rates and change alerts, send rua to a monitoring inbox rather than an unread mailbox.
• fo=1 asks receivers to send a failure sample whenever any underlying check fails, which speeds up confirming Proofpoint alignment.
• adkim=r and aspf=r keep relaxed alignment. Do not set adkim=s or aspf=s (strict) with Proofpoint unless your DKIM d= and your envelope domain exactly equal your From: domain with no subdomain difference, or you will fail mail that would otherwise align.

If you have never written one, the DMARC generator builds a valid record from a short form, and understanding your DMARC record explains every tag.

Reading the reports and confirming Proofpoint aligns

Leave p=none running for one to two weeks and read the aggregate reports. For Proofpoint specifically you are checking three things:

1. Mail from Proofpoint's IP ranges shows DKIM pass with d=yourdomain.com. This proves your DKIM key is published and signing is enabled. If DKIM is absent on Proofpoint rows, the key was never verified or signing is off for that domain or route.
2. The envelope domain on those rows. If it is your domain, SPF should show aligned. If it is .ppe-hosted.com or .pphosted.com, SPF passes but does not align, which is fine as long as DKIM aligns.
3. Any legitimate sender that bypasses Proofpoint. A common surprise is mail leaving Microsoft 365 or an application directly, not via the gateway. Those rows arrive from non-Proofpoint IPs and may fail if your SPF or DKIM does not cover them. Decide whether to route them through Proofpoint or authorise them separately before you enforce.

Raw DMARC XML is painful to eyeball, so paste a report into the DMARC report analyzer, or have DMARC monitoring ingest your rua stream continuously. For a field-by-field walkthrough, see reading your first DMARC report.

Watch for these Proofpoint failure signatures:

• DKIM absent on gateway mail. Key not verified, or DKIM signing not enabled for the domain or route. Re-verify the key and confirm signing is on. On PPS, confirm the outbound policy route is in scope.
• SPF pass but not aligned on gateway mail. Proofpoint rewrote the envelope to its own domain. Acceptable if DKIM aligns; if you want SPF to align too, work with Proofpoint to preserve your return-path domain.
• A direct-send source bypassing the gateway. Authenticate or re-route it before enforcement.
• A genuinely foreign source spoofing your domain. This is exactly what DMARC reporting exists to surface. Note it; enforcement will stop it.

Moving to quarantine, then reject

Once reports confirm Proofpoint (and every other legitimate sender) is aligned, tighten in stages. Never jump straight from none to reject.

First, quarantine a slice of failing traffic:

_dmarc.yourdomain.com.  TXT  "v=DMARC1; p=quarantine; pct=25; rua=mailto:reports@yourdomain.com; adkim=r; aspf=r"

The pct=25 applies quarantine to a quarter of failing messages while the rest stay at the previous handling, so you can watch for collateral damage on a small sample. Raise to pct=100, watch a few more days, then enforce fully:

_dmarc.yourdomain.com.  TXT  "v=DMARC1; p=reject; rua=mailto:reports@yourdomain.com; adkim=r; aspf=r"

At p=reject, any message claiming to be from your domain that does not pass an aligned check is rejected by receivers. Because your Proofpoint-relayed mail is DKIM-aligned, it sails through; spoofed mail does not. The full staged method, including how long to sit at each step, is in reaching p=reject without breaking email and the enforcement journey.

The Gmail, Yahoo and Microsoft bulk-sender rules lean on this: if you send volume to those mailboxes, an aligned, enforced DMARC record is effectively required. See Gmail, Yahoo and Microsoft now require DMARC and the live requirements.

Proofpoint and inbound DMARC: a separate job

One thing that confuses Proofpoint administrators: Proofpoint is also an inbound gateway, and PPS can evaluate incoming DMARC and act on it. That is a different setting from your outbound authentication and it is configured on the inbound policy routes under Email Authentication. Two consequences worth knowing:

• Inbound DMARC enforcement is independent of your own DMARC record. Turning on Proofpoint's inbound DMARC module protects your users from spoofed inbound mail; it does nothing for whether your outbound mail passes DMARC at other receivers. They are separate problems with separate fixes.
• Forwarding through the gateway can break inbound senders' DMARC. When Proofpoint forwards or re-injects mail, SPF for the original sender breaks (the IP is now Proofpoint's). This is normal mailbox-forwarding behaviour and is why DKIM, which survives the hop, is the alignment receivers rely on. It is also why an organisation in front of Proofpoint should not be surprised to see SPF-only senders fail; that is a property of forwarding, not a misconfiguration on your side.

Keep the two mental models separate: outbound is "make Proofpoint sign and authorise my mail so the world trusts it", inbound is "make Proofpoint judge other people's DMARC before it reaches my users".

Proofpoint-specific troubleshooting

550 5.7.1 SPF rejection on outbound Essentials mail. Almost always SPF is missing the a:dispatch-* mechanism, or you have two v=spf1 TXT records causing a permerror. Merge into one record and add the correct regional dispatch mechanism. Confirm with the SPF checker.

"DKIM passes in Proofpoint's verify check but DMARC reports show DKIM fail." Proofpoint's Verify Key button confirms the public key resolves; it does not confirm alignment with your From:. If signing uses d= on a different label than your From: domain, relaxed alignment usually still matches by organisational domain, but strict (adkim=s) will not. Keep alignment relaxed.

"SPF passes but never aligns through the gateway." Proofpoint is using a .ppe-hosted.com or .pphosted.com envelope. Lean on DKIM alignment, or arrange for your own return-path domain to be preserved.

"Some mail aligns, some does not." You likely have a stream bypassing Proofpoint (direct Microsoft 365 or an app server), or a second domain whose DKIM key was never generated. Each domain needs its own selector and key; each sending path needs SPF coverage.

"SPF permerror appeared after adding the PPS include." The cluster include plus Microsoft 365 and others exceeded ten lookups. Flatten the record; see SPF PermError: the 10-lookup limit.

BIMI and the logo. Once you are at p=quarantine or p=reject with Proofpoint aligned, you become eligible for BIMI, which can show your brand logo next to authenticated mail. Check readiness with the BIMI checker and read do you need BIMI. While you are tightening DNS, it is also worth publishing inbound TLS policy; check yours with the MTA-STS checker.

A complete Proofpoint example, end to end

For a domain relaying Microsoft 365 mail out through Proofpoint Essentials (US), a finished, aligned configuration looks like this:

; --- SPF: Proofpoint Essentials US dispatch + Microsoft 365, one record ---
yourdomain.com.            TXT  "v=spf1 a:dispatch-us.ppe-hosted.com include:spf.protection.outlook.com -all"

; --- DKIM: key generated and verified in Proofpoint, selector s1 ---
s1._domainkey.yourdomain.com.  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A..."

; --- DMARC: after monitoring, enforced ---
_dmarc.yourdomain.com.     TXT  "v=DMARC1; p=reject; rua=mailto:reports@yourdomain.com; adkim=r; aspf=r"

For the enterprise Proofpoint Protection Server equivalent, swap the SPF mechanism for your cluster include and use the selector you generated under Email Authentication:

yourdomain.com.            TXT  "v=spf1 include:spf-0123abcd.pphosted.com include:spf.protection.outlook.com -all"
pps2026._domainkey.yourdomain.com.  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A..."
_dmarc.yourdomain.com.     TXT  "v=DMARC1; p=reject; rua=mailto:reports@yourdomain.com; adkim=r; aspf=r"

In both cases, mail sent as you@yourdomain.com and relayed through Proofpoint is DKIM-signed with d=yourdomain.com, that signature aligns with the From: domain, SPF passes for Proofpoint's hosts, and DMARC passes on at least the DKIM factor. Spoofed mail using your domain from anywhere else fails alignment and is rejected.

The practical takeaway

Proofpoint is a relay, so the gateway's own IPs and signature are what receivers judge, not whatever your underlying platform did. Three Proofpoint-specific moves carry you to enforcement, in order of importance:

1. Generate and verify a DKIM key inside Proofpoint so it signs with d=yourdomain.com. On Essentials that is Create New DKIM Signing Key plus Verify; on PPS it is Email Authentication > DKIM Signing > Generate Key, outbound routes only. This is the alignment that reliably passes DMARC through a gateway.
2. Publish the correct SPF entry for your product and region: the a:dispatch-us.ppe-hosted.com or a:dispatch-eu.ppe-hosted.com mechanism for Essentials, or the include:spf-<clusterid>.pphosted.com cluster include for PPS, in a single SPF record, under ten lookups.
3. Publish DMARC at p=none, confirm in real reports that Proofpoint mail aligns (and that nothing legitimate bypasses the gateway), then ramp through quarantine to reject in stages, never in one jump.

Do those in order and Proofpoint keeps relaying your mail while spoofing of your domain stops. Start by checking what your domain reports today with the DMARC checker, SPF checker and DKIM checker. If you would rather not babysit the dispatch mechanisms, the DKIM selectors, the return-path alignment and the staged rollout yourself, our done-for-you DMARC service takes your domain from p=none to p=reject with Proofpoint and every other sender aligned and continuously monitored, with no email outage along the way.