Step 2: Update SPF Record (Google Workspace)

Modified on Tue, Aug 25 at 11:03 AM

In order to route your email outbound through Proofpoint, this step is required to ensure that your messages are not rejected by recipient mail servers as potential spoofing.

Why this step matters

When Proofpoint relays your outbound mail, the message reaches the recipient from a Proofpoint address rather than from Google. If your SPF record does not authorize Proofpoint, receiving servers see mail claiming to be from your domain arriving from a source you have not listed, and can treat it as spoofing.

Find your current record

Your SPF record is a TXT record on the root of the domain's DNS zone, beginning v=spf1. A Google Workspace domain that has never used another mail service normally has:

v=spf1 include:_spf.google.com ~all

Add Proofpoint

Add the Proofpoint include for your region immediately after v=spf1, keeping everything already in the record:

  • US region: include:_spf-us.ppe-hosted.com
  • EU region: include:_spf-eu.ppe-hosted.com

A Google Workspace domain relaying through Proofpoint in the US region becomes:

v=spf1 include:_spf-us.ppe-hosted.com include:_spf.google.com ~all

And in the EU region:

v=spf1 include:_spf-eu.ppe-hosted.com include:_spf.google.com ~all

Keep the Google include. Google Workspace still sends some mail directly rather than through the relay, including Drive sharing notifications, Calendar invitations and comment notifications. Remove the Google include and those messages start failing SPF.

Check these before you save

  • One record per domain. Two TXT records beginning v=spf1 is a permanent error and fails every check. If one already exists, edit it rather than adding another.
  • Ten DNS lookups maximum. Every include counts towards the limit. If the domain already lists several services, count them before adding another.
  • One all mechanism, at the end. Anything after it is ignored.

A note on ~all and -all

A tilde is a soft fail and a minus is a hard fail. The hard fail is stronger, but it only helps once every legitimate sender is listed. Leave the record on ~all through the deployment, then change it to -all after mail has been running through Proofpoint for a few days and you are satisfied nothing else sends as the domain.

Older record format

These records are still honored but should be updated to the include format above:

US region:  v=spf1 a:dispatch-us.ppe-hosted.com ~all

EU region:  v=spf1 a:dispatch-eu.ppe-hosted.com ~all

DKIM and DMARC

  • Leave Google Workspace DKIM signing in place. Do not turn it off as part of this deployment.
  • Check whether the domain publishes a DMARC record, and what the policy is. A domain on p=quarantine or p=reject with a broken SPF record has its mail held or discarded rather than delivered to junk, and nobody sees a bounce.

Allow for DNS

SPF changes are subject to the TTL on the TXT record, commonly one hour. Allow the TTL to expire before testing, and check the record has actually updated rather than assuming it has.

Proceed to next step: Step 3: Import Mailboxes

Deploying Proofpoint? We Can Help

We support Proofpoint deployments end-to-end from configuration and migration to optimization, ensuring a smooth rollout with minimal disruption.

Speak to an expert

Was this article helpful?

That’s Great!

Thank you for your feedback

Sorry! We couldn't be helpful

Thank you for your feedback

Let us know how can we improve this article!

Select at least one of the reasons
CAPTCHA verification is required.

Feedback sent

We appreciate your effort and will try to fix the article