Give the policy an owner

Name the team accountable for approving senders and the team able to publish DNS. Record an escalation contact and backup. A marketing platform owner can provide service evidence, but should not silently alter organization-wide authorization; a DNS team can publish syntax, but cannot know whether a sender is legitimate without business ownership.

For every SPF identity, maintain the complete record, purpose, visible From relationships, mechanisms and modifiers, provider account, lookup dependencies, expected volumes, and last verified message. Map each term to an owner. “Inherited” is not an owner.

Use an onboarding checklist

Require a request to include:

  1. business purpose and permission basis;
  2. exact MailFrom and visible From domains;
  3. provider and account ownership;
  4. official SPF requirement and its dependency cost;
  5. DKIM and DMARC alignment plan;
  6. representative receiver test;
  7. rollback and retirement date or review date.

Reconstruct the full candidate policy and validate it before publication. Never ask a requester to append a second v=spf1 record.

Review on a useful cadence

At each review, query authoritative DNS, trace bounded dependencies, detect multiple policies and processing-limit risk, and compare every term with the active sender inventory. Sample fresh messages from each stream rather than trusting DNS alone. Investigate unknown traffic without automatically authorizing it.

Provider includes can change beneath your record. Monitor their availability and behavior without copying their ranges into an unmanaged static list. Keep resolver errors and missing records as unknown/error states, not “not authorized” evidence.

Retire cleanly

When a service closes, stop application traffic, revoke credentials, preserve required suppression and audit data, and watch through a period that includes infrequent jobs. Remove the SPF term with a recorded rollback. Confirm remaining senders on fresh messages and update the inventory.

Keep an audit trail

For each change, retain the requester, approver, previous and new values, reason, observed TTL, validation evidence, deployment time, outcome, and rollback result. Avoid storing customer addresses or complete messages where a sanitized identifier and authentication extract will do.

The maintenance process succeeds when a new operator can explain every authorization and safely remove a retired one. A short SPF record with no ownership can be riskier than a longer, well-governed policy—and a syntactically valid policy can still authorize the wrong systems.