Deliverability · Practical guide

Set up an SPF record around your actual sending services

Inventory legitimate senders, publish one SPF policy for the envelope domain and verify it on a fresh received message.

Reviewed · Examples are illustrative

Who this helps: Operators diagnosing authentication, receiving-policy and delivery failures.

Define the decision

Begin with the domain used in SMTP MAIL FROM, which may differ from the visible From address. Editing the root domain blindly can leave the actual sending identity unchanged or break an unrelated application.

Work through the procedure

  1. List every service authorized to send using the relevant envelope domain.
  2. Obtain each service’s current SPF instructions from its administration interface.
  3. Read existing TXT records and merge authorized mechanisms into one SPF record.
  4. Evaluate DNS-dependent terms, publish through the domain owner and test each legitimate stream.

Worked example

The following is a synthetic example for this procedure, not a customer result or performance benchmark.

Inventory: business mailbox plus invoicing service
Existing policy: authorizes only the mailbox service
Change request: add the verified invoicing mechanism to the existing policy
Verification: fresh messages from both paths pass SPF for the intended envelope domain

Read the result

The inventory is the important artifact. A syntactically valid record that omits an invoice sender is still an operational failure. Keep the previous value and a rollback owner while validating all streams.

Check before moving on

  1. Count SPF records rather than all TXT records.
  2. Confirm the receiver evaluated the domain you changed.

Limits and next action

Do not copy a provider include from this example or add every service you might use later. SPF authorization should follow a verified sending requirement and does not by itself guarantee DMARC alignment.

Source: RFC 7208: SPF record processing

Source references

Worked examples are illustrative. Editorial procedures are suggested methods, not measured performance claims or promises of additional product features.

Related guides

Explore the Zintara workflow