Pingback Permitted From (PPF)

Version: 0.9.0 Date: January 2026

Abstract

This specification defines a DNS-based mechanism for authorizing Pingback and Webmention senders, analogous to SPF for email. It allows domain owners to declare which hosts are permitted to send link notifications on their behalf, enabling receivers to reject unauthorized notifications before fetching the source URL.

Problem Statement

Pingback has a sender authentication problem identical to SMTP's pre-SPF era: any host can send a Pingback claiming any source URL. Current implementations attempt to verify legitimacy by fetching the claimed source to check the link exists, but this creates two vulnerabilities:

1. Reflected amplification attacks — An attacker sends Pingbacks to thousands of servers claiming victim.com as the source. All receivers simultaneously fetch from victim.com to verify, creating a distributed denial-of-service.

2. Unauthorized notifications — Anyone can trigger Pingbacks pointing to legitimate URLs they did not author, polluting receivers' notification streams.

Webmention, despite being a W3C Recommendation, has the same fundamental vulnerability. The specification recommends receiver-side mitigations but does not address sender authorization—any host can still claim any source URL.

Solution

Domain owners publish a DNS TXT record declaring which hosts may send Pingbacks and Webmentions for URLs on that domain. Receivers query this record and reject unauthorized notifications before any HTTP request touches the claimed source.

Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174 when, and only when, they appear in all capitals.

This specification uses the terminology defined in Pingback 1.0:

• Source URI — The page containing the link (where the link originates)
• Target URI — The page being linked to (the destination)
• Client — The software that sends the pingback notification, typically running on the source site
• Server — The software that receives the pingback notification, running on the target site

Webmention uses the same source/target terminology; client and server roles are equivalent.

Additionally:

• Proxy — An intermediary service (such as a CDN) that receives pingbacks from clients and forwards them to servers
• Sender — The party transmitting a pingback request (either a client directly, or a proxy forwarding to a server)
• Receiver — The party receiving a pingback request (either a server directly, or a proxy on behalf of a server)

Examples in this specification use reserved domains per RFC 2606 and RFC 6761:

• example.com — A generic sender (client) site
• example.net — A proxy service
• example.org — A server (target) site

Record Format

The record is a TXT record at _pingback.<domain> containing a version tag followed by one or more mechanisms.

Syntax

ppf-record  = "v=ppf1" SP ( "none" / mechanisms )
mechanisms  = mechanism *(SP mechanism)
mechanism   = "a" /
              "a:" hostname /
              "ip4:" ip4-network /
              "ip6:" ip6-network /
              "include:" domain

Where:

• SP is a single space character (per RFC 5234).
• hostname/domain are DNS names (per RFC 1035).
• ip4-network and ip6-network are either a single IP address or a CIDR network (per RFCs 791, 4291, 4632).

Version

All records MUST begin with v=ppf1. Records without this prefix, or with an unrecognized version, are treated as invalid (see Verification Algorithm step 3).

Mechanisms

Mechanisms are evaluated left-to-right. The first match determines the result. If no mechanism matches, the notification is rejected.

The none mechanism allows a domain to declare that it does not send notifications. Any Pingback or Webmention claiming a source URL on that domain should be rejected.

A record with no mechanisms (just v=ppf1) is treated as equivalent to none, but authors SHOULD use none explicitly as its intention is clearer.

Record Presence as Policy

A valid PPF record constitutes an explicit policy. Unlike SPF, there is no soft-fail or neutral state:

• Valid record exists: Notification must match a mechanism or be rejected (fault 51)
• No record, malformed record, or unrecognized version: Server decides whether to proceed without PPF authorization (permissive mode) or reject (strict mode, fault 18)

This simplification is appropriate because PPF is opt-in from inception rather than being retrofitted onto legacy infrastructure, and failure (a dropped notification) has minimal impact compared to a lost email. Eliminating soft-fail and neutral states removes ambiguity and keeps the specification simple.

Verification Algorithm

Upon receiving a notification (Pingback or Webmention) claiming source URL https://source.example.com/post:

1. Extract the hostname from the source URL (source.example.com)
2. Query the TXT record at _pingback.source.example.com
3. If no record exists, record is malformed, or version is unrecognized:
   • Permissive mode: Proceed without PPF authorization
   • Strict mode: Reject the notification (fault 18)
4. If a valid record exists, evaluate mechanisms against the sender's IP address
5. If a mechanism matches, proceed to link verification
6. If no mechanism matches, reject the notification (fault 51)

Include Processing

When evaluating an include:domain mechanism:

1. Query _pingback.<domain>
2. Evaluate that record's mechanisms
3. If any mechanism matches, the include matches

DNS Lookup Limits

To prevent resource exhaustion, evaluation MUST NOT result in more than 10 DNS lookups. This limit applies to the total number of lookups across all mechanism evaluation, including:

• Each a mechanism (A/AAAA lookup of source hostname)
• Each a:hostname mechanism (A/AAAA lookup of specified hostname)
• Each include:domain mechanism (TXT lookup, plus any lookups from the included record)

Additionally, include depth MUST NOT exceed 5 levels to prevent loops.

If either limit is exceeded during evaluation, the result is the same as a malformed record: permissive mode proceeds without PPF authorization; strict mode rejects the notification.

Backwards Compatibility

PPF is designed to work alongside existing Pingback and Webmention implementations without breaking legacy clients.

Sites may support Pingback, Webmention, or both. A single PPF record covers both protocols—the DNS authorization layer is protocol-agnostic. During the transition to wider Webmention adoption, sites will likely advertise both endpoints simultaneously; the combined endpoint examples in this specification reflect this expected coexistence.

Pingback Client Capability Signalling

Pingback clients that support PPF asynchronous responses MUST include the following header in their request:

X-PPF-Version: 1

This header is essential for Pingback because it tells the receiver the client can handle asynchronous responses and HTTP status codes beyond the standard XML-RPC format. Without it, the receiver MUST fall back to legacy Pingback responses.

Webmention clients MAY include the X-PPF-Version header. It is not required because Webmention already uses HTTP status codes natively and the W3C specification already defines asynchronous processing.

Pingback Asynchronous Processing Protocol

Receivers MAY process pingbacks synchronously or asynchronously. Synchronous processing completes DNS authorization and link verification before responding; asynchronous processing queues some or all of these operations and provides a status URL for the client to poll.

When a pingback is accepted for asynchronous processing, the receiver responds as follows:

• Response MUST be 202 Accepted
• Response body MUST be empty
• Response MUST include Retry-After header (minimum delay before polling)
• Response MUST include Expires header (status URL valid until this time)
• Response MUST include Location header with a status polling URL

Pingback Response Handling

The following sections describe Pingback-specific response handling. For Webmention, see the Webmention section below.

Server Response Behaviour

Servers MAY perform initial validation synchronously and return an XML-RPC fault response immediately on error (malformed request, invalid target URL, etc.).

For pingbacks that pass initial validation, the receiver checks PPF authorization. The response depends on the result and whether the client is PPF-aware:

Legacy Clients (no X-PPF-Version header)

Server MUST return standard Pingback responses:

• Success: HTTP 200 with bare string body
• Rejection: HTTP 200 with XML-RPC fault body

Response MUST NOT include Retry-After, Expires, or Location headers.

PPF-aware Clients (X-PPF-Version: 1 header present)

Synchronous processing:

• Success: HTTP 200 with bare string body
• PPF rejection: HTTP 410 with bare string describing the reason
• Unwelcome: HTTP 200 with XML-RPC fault 52, or any appropriate HTTP error code

Asynchronous processing:

• Accepted for processing: 202 with status URL (see Pingback Asynchronous Processing Protocol)
• Immediate rejection: HTTP 410 with bare string, or HTTP 200 with XML-RPC fault

Receivers MAY use any appropriate HTTP error code (4xx/5xx) to reject a pingback, but returning HTTP 200 with an XML-RPC fault is more informative to the client.

This structure ensures existing Pingback clients continue to work unchanged, while PPF-aware clients can take advantage of extended status codes and asynchronous processing.

Status Endpoint

When responding asynchronously, the URL in Location returns:

The Expires header on the initial 202 response indicates the guaranteed lifetime of the status URL. Once the pingback reaches a terminal state, the status endpoint SHOULD include its own Expires header.

The status identifier MUST be unguessable (a UUID or similar random token) to prevent third parties probing for information about pingbacks between other sites.

Status Endpoint Response Format

The status endpoint response mirrors what the server would return for a synchronous pingback:

202 Still processing: Response body is empty.

200 Accepted: Bare string body. The string value is for debugging and is implementation-specific; a suggested format is:

Pingback from https://source.example.com/post to https://example.org/article received 2025-01-10T12:00:00Z; validated 2025-01-10T12:00:30Z

200 Rejected: XML-RPC fault response with an appropriate fault code. Any valid Pingback fault code may be used (e.g., 0x0011 for no link found, or the PPF-specific codes below):

<?xml version="1.0"?>
<methodResponse>
  <fault>
    <value>
      <struct>
        <member>
          <n>faultCode</n>
          <value><int>51</int></value>
        </member>
        <member>
          <n>faultString</n>
          <value><string>PPF authorization failed</string></value>
        </member>
      </struct>
    </value>
  </fault>
</methodResponse>

PPF Fault Codes

PPF extends the Pingback 1.0 fault code scheme:

Fault codes 18 and 51 typically appear in async status responses, since DNS authorization happens in the background. For synchronous processing where DNS is checked before responding, a 410 with a bare string is returned instead.

Fault code 52 may be returned at any point—either as an immediate response or in a status response—always as HTTP 200 with XML-RPC fault body. This allows receivers to reject sources based on reputation or abuse signals regardless of PPF authorization.

Existing Pingback 1.0 fault codes remain valid for their original purposes (0x0011 for no link found, etc.).

Webmention

Webmention already defines asynchronous processing: receivers return 202 Accepted with a Location header pointing to a status URL. PPF slots into this flow—receivers check DNS authorization before fetching the source URL.

The Webmention specification does not define what the status URL should return. This specification does not extend that; the 202 response with empty body described in the Pingback Asynchronous Processing Protocol is compatible with Webmention's async model.

Webmention uses HTTP status codes rather than XML-RPC faults:

• 200/201: Success (accepted)
• 202: Accepted for async processing
• 4xx: Client errors (bad request, invalid target)
• 5xx: Server errors

Note on 203 Non-Authoritative Information

Proxies are transforming intermediaries: the status response they provide to clients may differ from what the server returned. For example, a proxy may translate a server's HTTP 410 rejection into an XML-RPC fault for a Pingback client's status endpoint. This makes 203 Non-Authoritative Information the more precise HTTP status code for proxy responses. However, this specification uses 202 Accepted uniformly for simplicity and compatibility with Webmention's existing async model. Implementations that return 203 instead of 202 are not non-conforming, but clients MUST treat both identically.

Adoption and Transition

During the transition period, servers may choose how strictly to enforce PPF:

• Permissive: Accept all notifications; use PPF for authorization when a record exists, fall back to legacy verification otherwise. This is the default behaviour described in this specification.
• Strict: Require a valid PPF record; reject notifications from sources without one.

Security-conscious sites may choose strict mode immediately. For the broader ecosystem, the transition from permissive to strict will be gradual—driven by server software authors deciding when to change the default, as adoption of PPF records becomes widespread.

Implementation Guidance

This specification supports two operating modes: direct (standalone implementation) and proxied (via a CDN or similar service). Implementations MAY support either or both modes.

Direct Mode

In direct mode, the receiver handles all verification itself.

Processing Considerations

DNS resolution and link verification are vulnerable to tarpitting:

• DNS tarpitting: attacker-controlled nameservers delay responses indefinitely
• HTTP tarpitting: attacker-controlled web servers (or victim sites) drip-feed responses, hold connections open, or chain redirects

Synchronous implementations SHOULD enforce strict timeouts and caching on DNS lookups. Asynchronous implementations avoid these risks by queuing network operations.

Caching

Implementations SHOULD cache authorization results:

• Respect DNS TTL for positive results
• Cache negative results (NXDOMAIN, timeout, unauthorized) for at least 1 hour
• A flood of notifications claiming the same domain triggers only one lookup

Rate Limiting

Implementations SHOULD enforce:

• Global limit on outbound DNS queries per second
• Per-domain queue depth limits
• Hard timeouts on all network operations

Proxied Mode

In proxied mode, a CDN or similar service handles authorization, fetching, and filtering. The server receives pre-validated requests and operates synchronously.

Implementations supporting proxied mode MUST:

• Reject notifications received directly (not via the configured proxy)
• Verify requests originate from the proxy (via IP allowlist, shared secret, or signature—implementation-specific)
• Advertise the proxy's endpoint rather than their own

Endpoint Advertisement

All notification endpoints MUST point to the proxy. Sites supporting both protocols advertise both:

X-Pingback: https://pingback.example.net/receive/example.org
Link: <https://pingback.example.net/webmention/example.org>; rel="webmention"

or in HTML:

<link rel="pingback" href="https://pingback.example.net/receive/example.org" />
<link rel="webmention" href="https://pingback.example.net/webmention/example.org" />

Proxy-to-Server Request Format

When a proxy forwards a verified Pingback, the XML-RPC payload remains unchanged. This ensures compatibility with existing implementations. The proxy adds headers to provide verification context:

Proxies MAY add additional headers for authentication (shared secrets, signatures, etc.) as appropriate for their implementation.

For Webmention, the same headers apply; the form-encoded payload (source and target parameters) remains unchanged.

Server Behaviour (Proxied Mode)

When operating behind a proxy, the server:

1. MUST verify requests originate from the configured proxy
2. MUST fetch source content from the URL in X-Pingback-Cache-URL instead of the source URI
3. MAY use other proxy-provided headers for logging or policy decisions

The payload is unchanged. The server processes the notification normally, but source content comes from the proxy's cache.

The cache URL MUST be either unguessable (containing a UUID or similar random token) or secured by other means, to prevent third parties from retrieving cached content.

Proxy-to-Client Response

Client ────────► Proxy                           Server
       ◄──── 202 ────   (async verify & cache)
                      ─── pre-validated request ──►
                      ◄─────── 200 / fault ───────

For PPF-aware clients, the proxy responds per the Pingback Asynchronous Processing Protocol.

For legacy clients, the proxy returns a standard Pingback success response immediately and processes asynchronously.

The server responds synchronously to the proxy with standard Pingback responses. The proxy translates the server's response into the appropriate format for the client's status endpoint. For example, if the server returns HTTP 410 (used for PPF rejection in direct mode), the proxy may represent this as an XML-RPC fault 52 in the Pingback status response, or as an appropriate HTTP error for Webmention.

For Webmention, the flow is identical; the server responds with HTTP status codes rather than XML-RPC faults.

Sender Behavior

Clients and proxies sending Pingbacks or Webmentions SHOULD:

• Include X-PPF-Version: 1 header to enable asynchronous responses and status tracking
• Track response codes per target domain
• Implement exponential backoff for repeated 5xx failures
• Maintain a blocklist of domains returning persistent 5xx errors
• Clear blocklist entries after a reasonable period (e.g., 7 days) to allow recovery
• Poll status URL from Location header if provided, respecting Retry-After and completing before Expires

Examples

Direct Mode Examples

Self-hosted site

The site sends Pingbacks from its own IP address:

_pingback.example.com. IN TXT "v=ppf1 a"

Static site with external Pingback service

Site uses a third-party Pingback service at pingback.example.net:

_pingback.myblog.example.com. IN TXT "v=ppf1 a:pingback.example.net"

Multiple authorized sources

Site sends from its own server and a managed hosting service:

_pingback.news.example.com. IN TXT "v=ppf1 a ip4:203.0.113.0/24 include:pingback.example.net"

Subdomain with separate policy

Main domain and blog subdomain have different infrastructure:

_pingback.example.com. IN TXT "v=ppf1 a"
_pingback.blog.example.com. IN TXT "v=ppf1 include:pingback.example.net"

Domain that does not send notifications

A static site or documentation site that never links out:

_pingback.docs.example.com. IN TXT "v=ppf1 none"

This explicitly declares that any Pingback or Webmention claiming to originate from this domain is unauthorized.

Proxied Mode Examples

Site behind a CDN or DDoS protection service

Sites using origin protection require:

1. DNS policy delegating authorization to the proxy:

_pingback.example.org. IN TXT "v=ppf1 include:pingback.example.net"

2. Endpoint advertisement pointing to the proxy:

X-Pingback: https://pingback.example.net/receive/example.org
Link: <https://pingback.example.net/webmention/example.org>; rel="webmention"

or in HTML:

<link rel="pingback" href="https://pingback.example.net/receive/example.org" />
<link rel="webmention" href="https://pingback.example.net/webmention/example.org" />

3. Receiver configured to:
   • Only accept notifications from the proxy
   • Fetch cached content from proxy instead of source URL

Security Considerations

DNS as Authorization Layer

Using DNS for authorization is proven at scale—SPF has operated this way since 2003, handling billions of queries daily across the global email infrastructure. The same properties apply to PPF:

• DNS infrastructure is globally distributed and heavily cached
• Authorization queries never touch the claimed source's web server
• Amplification attacks become ineffective when receivers check authorization first

Denial-of-Service Considerations

Synchronous implementations that perform DNS lookups in the request path should enforce hard timeouts (e.g., 2 seconds), use cached results aggressively, and apply per-source rate limits. Without these controls, attacker-controlled nameservers can tarpit connections and exhaust server resources.

Asynchronous implementations isolate all network operations in background workers, providing stronger protection against tarpitting attacks.

Proxies SHOULD NOT process notifications fully synchronously, as this exposes the proxy infrastructure to the same tarpitting risks. The purpose of a proxy is to protect the origin server; a proxy that can itself be tarpitted provides limited value.

Origin IP Exposure (Proxied Mode)

Sites using CDN or DDoS protection services typically only proxy inbound traffic. Without proper configuration, notification verification fetches go directly from the origin server, exposing its real IP.

Sites operating in proxied mode MUST:

1. Use include: to delegate DNS authorization (MUST NOT use a mechanism)
2. Advertise the proxy's endpoint, not the origin's
3. Reject any notifications received directly (not via the proxy)

An attacker who discovers the origin IP could bypass proxy protections by sending notifications directly; the origin should treat such requests as unauthorized regardless of other validation.

Negative Caching

Extended caching of negative results (NXDOMAIN, timeout) prevents attackers from using non-existent or slow-responding domains to exhaust resolver resources.

DNS Lookup Limits

The maximum of 10 DNS lookups and include depth of 5 levels (both inherited from SPF) prevent:

• Infinite loops from circular includes
• Resource exhaustion from deeply nested or wide policies
• Computational complexity attacks
• Amplification via attacker-controlled DNS infrastructure

Limitations

PPF shares the same fundamental limitations as SPF for email:

• Does not prevent spam. PPF verifies that a sender is authorized to send pingbacks for a domain—it says nothing about the quality or legitimacy of the content. An authorized sender can still send unwanted or malicious pingbacks.
• Does not verify content. The link verification step (checking the source actually links to the target) remains necessary. PPF only gates access to that step.
• Relies on domain owner action. Domains without PPF records provide no protection. Adoption is voluntary.

PPF reduces the attack surface by eliminating unauthorized senders, but receivers should continue to apply content filtering, rate limiting, and moderation to pingbacks from authorized sources.

Privacy Considerations

DNS Query Metadata

PPF authorization requires DNS queries that reveal which domains are receiving notifications claiming to originate from other domains. This metadata is visible to DNS resolvers and anyone monitoring DNS traffic. However, this exposure is no worse than the notifications themselves—a successful notification already reveals the linking relationship—and DNS responses are heavily cached, reducing the query volume.

Status URL Confidentiality

Status URLs reveal that a notification is in progress between two parties. This specification requires status identifiers to be unguessable (UUIDs or similar) to prevent third parties from probing for information about notifications between other sites.

Proxy Trust Model

Sites operating in proxied mode delegate significant trust to the proxy operator. The proxy observes:

• Every notification sent to or from protected sites
• The full content of source pages (cached for verification)
• Timing patterns and linking relationships across all customers

This is the same trust model as CDNs for web traffic generally. Site operators should evaluate proxy operators with the same scrutiny they would apply to any infrastructure provider handling their traffic. A malicious or compromised proxy could collect substantial intelligence about cross-site relationships.

Rationale

Pingback is the web's dominant cross-site notification protocol. It requires no API keys, no account registration, no signing infrastructure, and no central authority. Any site can notify any other site that it has linked to them. This simplicity encouraged adoption but is also Pingback's weakness: without sender authentication, the protocol is trivially abused.

Webmention is essentially Pingback without XML-RPC—a much simpler transport for the same notification model. It should have replaced Pingback, and may yet do so, but adoption has been slow. Despite going through the W3C process, it inherits the same sender authentication vulnerability.

Trackback predates Pingback but was superseded by it; refback never achieved meaningful adoption. While the DNS authorization mechanism defined here could in principle be applied to Trackback, that protocol is probably better retired than revived. Such application is outside the scope of this specification.

Today, roughly 40% of websites support Pingback natively through WordPress. Webmention adoption remains negligible despite being simpler. Rather than replace these protocols, PPF fixes them by adding the missing authentication layer, using the same proven approach that SPF brought to email. The protocols remain simple and decentralized.

Value for CDN Providers

CDN providers are well-positioned to offer PPF proxy services:

• Reputation data: Aggregating pingback traffic across many sites provides signals that no single site could gather alone—patterns of abuse, spam sources, and bot behaviour become visible at scale.
• Abuse detection: Clients that ignore Retry-After, source content containing XSS patterns, high volume from single sources to many targets, and aggressive polling all correlate with malicious activity.
• First-mover advantage: The first major CDN to offer PPF protection creates switching costs and competitive differentiation.
• Minimal infrastructure: PPF proxy services can share existing DNS and caching infrastructure.

Value for Hosting Providers

Hosting providers can deploy PPF records for all customers with minimal effort:

• A single include: mechanism pointing to the provider's PPF record covers all hosted sites.
• Customers gain protection without understanding or configuring PPF themselves.
• The provider can update authorized senders (e.g., adding a new edge node) without touching customer DNS.

Protocol Translation

Because both Pingback and Webmention express the same information—a (source, target) pair—proxies can translate between them transparently. A proxy advertising both endpoints can accept a Webmention and deliver it as a Pingback to a server that only speaks XML-RPC, or vice versa.

This has significant implications for Webmention adoption. A translating proxy gives Webmention clients access to any Pingback-only site behind that proxy, and vice versa, without requiring changes to existing implementations. As proxy adoption grows, so does the pool of sites reachable by either protocol. If WordPress later adds native Webmention support, the proxy simply stops translating. Protocol translation is an implementation decision for proxy operators, not a protocol requirement, and the mechanism for discovering a server's supported protocols is outside the scope of this specification.

Adoption Dynamics

PPF follows the same adoption path as SPF. Early SPF adoption was driven by large email providers (AOL, Hotmail, Gmail) who had the most to gain from spam reduction and the infrastructure to check records at scale. As major receivers began checking SPF, senders had increasing incentive to publish records. Hosting providers accelerated adoption by publishing records on behalf of customers.

The same dynamics apply to PPF: CDN and hosting provider adoption covers many sites with single deployments, creating rapid growth in both record publication and enforcement. This is not speculative—it's the proven playbook.

Acknowledgments

This specification borrows heavily from SPF (RFC 7208), adapting its proven DNS-based authorization model for the Pingback use case. The name "Pingback Permitted From" echoes SPF's original name, "Sender Permitted From", before it was expanded and renamed.

References

Normative References

• RFC 2119 — Key words for use in RFCs to Indicate Requirement Levels
• RFC 8174 — Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words
• RFC 5234 — Augmented BNF for Syntax Specifications: ABNF
• RFC 1035 — Domain Names - Implementation and Specification
• RFC 791 — Internet Protocol (IPv4)
• RFC 4291 — IP Version 6 Addressing Architecture
• RFC 4632 — Classless Inter-domain Routing (CIDR)

Informative References

• Pingback 1.0 Specification — hixie.ch/specs/pingback/pingback
• Webmention (W3C Recommendation) — w3.org/TR/webmention/
• RFC 7208 — Sender Policy Framework (SPF)
• RFC 2606 — Reserved Top Level DNS Names
• RFC 6761 — Special-Use Domain Names