Confirm the Predictive sending arrangement
This guide covers the Predictive Response campaign-server workflow described in its public help center. It does not assume that every Predictive product, enterprise SMTP arrangement, or Salesforce email path behaves the same way. Record the account, campaign type, intended visible From domain, and system that actually sends the message. Do not substitute Salesforce's own authentication configuration for a third-party campaign route without evidence that it is the route in use.
The provider's deliverability page distinguishes default provider-domain sending from use of a customer's own domain. It instructs customers to contact support after publishing SPF so the sending servers can be aligned. DNS publication is therefore only part of the documented change; a support-confirmed server-side step remains necessary. Predictive Response deliverability setup
Before planning edits, capture a harmless campaign test and the existing authoritative DNS answers. Identify the people who control DNS, the business sending domain, the bounce address, and the Predictive account. Ask for the current account-specific instructions where the public material leaves a question open. This manuscript does not represent a support response or proof that a particular account has been updated.
Integrate SPF without replacing unrelated senders
The provider's SPF help identifies include:spf.predictiveresponse.net as its authorization mechanism. Its instructions distinguish adding authorization to an existing policy from creating a policy where none exists, and include a support verification step. Use that as a starting point for the exact account and domain, not as evidence that the current envelope already uses the intended identity. Predictive Response SPF setup
Preserve one SPF policy at the relevant owner name. Do not create a second SPF record or paste a second terminal all mechanism into an existing policy. Place required authorizations in the intended evaluation order and retain other legitimate senders. The existing policy's fail or softfail choice is a separate security decision; a provider example is not approval to weaken it. Review lookup limits after changes. SPF RFC 7208 sections 3.2 and 4.6.4
A validator showing syntactically valid SPF does not prove that a campaign evaluates that domain, that the support step is complete, or that DMARC aligns. Record the queried owner, returned policy, collection time, and test result. Then compare them with the actual envelope domain from a received message. The complete evidence chain must connect authorization, sending route, and visible identity.
Preserve the bounce processing dependency
Predictive's return-path instructions use a campaign test to identify the account-specific provider bounce destination. The customer then prepares a return-path address on its own mail system, aliases it to that identified destination, and asks support to update the sending application. The page connects this arrangement to bounce processing in Salesforce. Never guess the account-specific short name or use another customer's destination. Predictive return-path setup
Treat this as an operational routing change, not just a cosmetic sender edit. Document who owns the alias, what destination support confirmed, and what happens if the alias cannot deliver. Coordinate with the campaign owner so retries and suppression handling are understood. Keep the old working arrangement available for an approved rollback until both authentication and bounce processing have been demonstrated.
Use only a controlled, authorized bounce test or provider-supported diagnostic to evaluate that workflow. Do not send real campaigns to invented recipients or disrupt suppression data merely to obtain evidence. The acceptance record should show the expected status update or diagnostic outcome without exposing recipient addresses publicly. A successful recipient delivery and a functioning bounce feedback path are separate tests.
Do not equate provider DKIM with aligned customer DKIM
The reviewed deliverability page says DKIM is handled on the provider's servers. It does not establish a current customer-domain selector-generation procedure or prove which d= domain a specific campaign uses. This guide therefore does not invent DKIM CNAME targets, a self-service custom-domain switch, or an unsupported claim that customer-domain DKIM is unavailable. Those questions remain for account-specific evidence. Predictive DKIM statement
A received message can carry a valid provider-domain signature without that signature aligning with the customer's visible From domain. DKIM verification and DMARC alignment answer different questions. Record every signature's domain and selector, the receiver's results, and whether any passing signature aligns. An aligned passing SPF path can also satisfy DMARC, but only if the evaluated envelope domain and From relationship meet the applicable mode. DKIM RFC 6376 DMARC RFC 9989
Do not change the domain-wide DMARC policy simply because a vendor says it handles DKIM. Ask what exact identity is authenticated and test it. If no supported aligned path is established, keep the custom-domain rollout pending and decide with the business owner whether an authorized provider-domain route or another supported configuration is appropriate.
Predictive campaign acceptance worksheet
Complete one record for each distinct account and sending route.
- Campaign context: account, campaign type, business owner, actual sender service, and intended From domain.
- SPF change: current policy, proposed authorization, envelope domain requiring it, authoritative DNS answers, lookup review, and change owner.
- Support checkpoint: ticket reference, exact requested server-side change, support-confirmed account and domain, completion time, and unresolved questions.
- Bounce route: customer return-path address, account-specific destination, alias owner, controlled diagnostic, and expected Salesforce processing evidence.
- Received identity: test timestamp, trusted receiver, visible From, Return-Path, all DKIM domains and selectors, SPF result, DKIM results, and aligned passing path.
- Release decision: remaining unsupported features, rollback plan, business approval, human SME review, and editorial presentation review. These are blank acceptance fields, not live findings.
Fictional diagnosis of a completed DNS change but unfinished setup
This scenario is fictional. A marketing administrator publishes the documented SPF authorization and a DNS validator reports a valid policy. The next campaign still shows a provider envelope domain and fails DMARC for the customer's From domain. A valid provider DKIM signature appears, but its signing domain does not align either.
The team checks the change record and discovers that nobody completed the support checkpoint. The proposed next step is to confirm the supported customer-envelope arrangement, validate the bounce alias for that account, and have support complete the authorized configuration. Only a new received campaign and a controlled bounce diagnostic can establish the outcome. The original syntax check did not prove alignment or Salesforce bounce handling.
Evidence and publication gates
Public first-party setup documentation was retrieved and reviewed. No Predictive account, support ticket, customer DNS, bounce mailbox, Salesforce record, or received customer message was inspected or changed. Current account applicability, server-side activation, aligned results, and bounce processing remain live gates. Human SME approval and rendered presentation review are pending. The broader full configuration title stays held until the DKIM and exact route questions are resolved; the draft is unpublished.
Distinguish an alias from a DNS return-path recipe
The documented bounce setup uses a customer mail address forwarding to the account-specific processing address. It does not supply a universal DNS CNAME recipe. Keep the alias owner and the support-confirmed application change in the same ticket, and leave custom-domain DKIM capability unresolved until the provider supplies applicable evidence.
Separate message acceptance from policy rollout
A passing aligned SPF result can satisfy a message evaluation, but does not alone justify moving an entire domain to reject. RFC 9989 Section 7.4 requires valid DKIM for domains publishing p=reject and warns about indirect-mail interoperability. Inventory all legitimate senders and indirect routes before the policy owner approves enforcement. No DNS change, tenant operation or received-message test was executed for this article.