When applying for jobs, I always perform OSINT recon on their security posture before deciding whether to proceed. Part of that involves knowing what their email security posture looks like, and which services they’re using to send emails. In one such case recently, I noticed they were using Proofpoint’s Hosted SPF service.

Having implemented this for clients previously, I knew that the macro-based SPF implementation could be queried to reveal any authorised email services. Here’s the technique for systematically fingerprinting an organisation’s email service landscape through Proofpoint’s infrastructure.

Background: Proofpoint’s Macro-Based SPF

Proofpoint Hosted SPF addresses the traditional SPF 10-lookup limitation using dynamic macro expansion. The implementation uses:

v=spf1 include:%{ir}.%{v}.%{d}.spf.has.pphosted.com ~all

The macros expand at query time to create unique DNS lookups based on the sending IP. These DNS lookups are then performed against Proofpoint-hosted DNS servers that host the data generated by their Hosted SPF platform. This allows Proofpoint’s Hosted SPF customers to specify unlimited authorised services without hitting DNS lookup limits inherent in the usual SPF record setup.

The Fingerprinting Technique

Proofpoint’s DNS infrastructure responds to queries for any IP address, not just during legitimate SPF checks. By querying with known service provider IP ranges, you can enumerate an organisation’s authorised email services.

Macro expansion:

  • %{ir} - Reversed IP octets (1.2.3.4 → 4.3.2.1)
  • %{v} - IP version identifier (“in-addr” for IPv4, “ip6” for IPv6)
  • %{d} - Target domain

Testing Microsoft Exchange Online authorisation for example.com:

# Microsoft Exchange Online IP: 40.92.0.1 -> reversed: 1.0.92.40
Resolve-DnsName -Name "1.0.92.40.in-addr.example.com.spf.has.pphosted.com" -Type TXT

Response Pattern Analysis

Three distinct response patterns identify service authorisation status:

Authorised service:

v=spf1 ip4:40.92.0.1 -all

Confirms the specific IP is authorised for the domain. This is just a plain, valid SPF record authorising that single IPv4 address with a hard fail (-all).

Known but unauthorised:

v=spf1 -all

Proofpoint recognises the IP range but customer hasn’t authorised it for this domain.

Not configured:

NXDOMAIN

The IP range isn’t in Proofpoint’s configuration.

Implementation

Query construction for common email service providers:

# Google Workspace
Resolve-DnsName "1.0.125.74.in-addr.example.com.spf.has.pphosted.com" -Type TXT

# AWS SES
Resolve-DnsName "1.0.240.54.in-addr.example.com.spf.has.pphosted.com" -Type TXT

# SendGrid
Resolve-DnsName "1.0.89.167.in-addr.example.com.spf.has.pphosted.com" -Type TXT

# MailChimp
Resolve-DnsName "1.128.201.205.in-addr.example.com.spf.has.pphosted.com" -Type TXT

Complex Integration Patterns

Some organisations return SPF exists mechanisms revealing additional service integrations:

v=spf1 exists:%{i}.spf.rnmk.com exists:%{i}._spf.mta.salesforce.com -all

These responses indicate:

  • Return Path integration (rnmk.com)
  • Salesforce Marketing Cloud (_spf.mta.salesforce.com)

The exists mechanisms demonstrate service stacking through Proofpoint’s infrastructure, providing deeper insight into email service architecture.

Security Implications

Organisations using Proofpoint Hosted SPF should understand that:

  1. Obscurity does not equal security
  2. Authorised email services are still enumerable through DNS queries
  3. They should be preferencing the use of DKIM over SPF to denote authorised email services wherever possible

Use Cases

This reconnaissance technique has legitimate applications in:

  • Security assessments - Understanding email infrastructure during authorised engagements
  • Incident response - Identifying potential email sources and pivot points
  • Compliance auditing - Verifying only approved services maintain SPF authorisation
  • OSINT reconnaissance - Evaluating organisational security posture

The technique demonstrates how functional requirements (solving SPF lookup limitations) can create information disclosure opportunities. Proofpoint’s implementation prioritises management capabilities and scalability, with enumerable authorisation as an accepted trade-off.

Script

I’ve built a script that automates this process for a given domain, you can check it out in my GitHub repo here.

Example output:

PS> E:\Invoke-ProofpointSPFFingerprint.ps1 -Domain example.com

Domain             : example.com
ServiceName        : Microsoft 365
TestIP             : 40.92.0.1
QueryName          : 1.0.92.40.in-addr.example.com.spf.has.pphosted.com
IsAuthorised       : True
ResponseType       : Authorised
ResponseData       : v=spf1 ip4:40.92.0.1 -all
AdditionalServices :

Domain             : example.com
ServiceName        : SAP SuccessFactors
TestIP             : 125.7.99.210
QueryName          : 210.99.7.125.in-addr.example.com.spf.has.pphosted.com
IsAuthorised       : True
ResponseType       : Authorised
ResponseData       : v=spf1 ip4:125.7.99.210 -all
AdditionalServices :

Domain             : example.com
ServiceName        : SwiftDigital
TestIP             : 13.54.188.125
QueryName          : 125.188.54.13.in-addr.example.com.spf.has.pphosted.com
IsAuthorised       : True
ResponseType       : Authorised
ResponseData       : v=spf1 ip4:13.54.188.125 -all
AdditionalServices :