Why can SPF look correct while the business still has a problem?
Your everyday mailbox might work while a website form or invoicing service fails authentication. Those messages can travel through different systems even when customers see the same business address. A provider's suggested SPF value is useful only in the context of everything else that sends for you.
Google's setup guidance starts by identifying the organization's senders, including automated and third-party services. Use that sequence. Begin with the business's tools and message flows, then ask an administrator to determine the right policy. Starting with a copied record can quietly omit a service someone depends on.
Why is one SPF policy different from one vendor?
The SPF standard, RFC 7208, does not permit multiple SPF policy records at the same DNS name. Two separate TXT records that both begin with the SPF version marker can cause a permanent evaluation error. That does not mean your domain can have only one TXT record for all purposes; unrelated TXT records serve other jobs.
If a new supplier says to add its SPF information, do not assume it should become another complete SPF record. Ask how its sending requirement fits into the existing policy. Keep the previous value and the approved replacement in the change record. An administrator should resolve the combined configuration before it is saved.
What is the lookup limit owners hear about?
SPF limits the mechanisms and modifiers that trigger DNS lookups during evaluation to ten. Nested lookups count, so ten visible vendor names is not a reliable way to judge the limit. A policy can become too expensive to evaluate even when it looks short. The standard defines the limit and resulting error behavior.
The owner's job is not to manually flatten a complicated policy. Ask the reviewer to document the evaluated lookup count, identify obsolete services, and explain the proposed remedy. Do not remove a sender merely because its name is unfamiliar. Confirm whether finance, marketing, or another team still uses it.
What should be checked after a change?
Use ordinary test messages that contain no client information. We recommend checking one representative message from each scoped service and recording the receiving system's authentication results. Include an automated message where the service supports it; sending only from an employee mailbox misses a different path.
Forwarding can change the server that delivers a message, which can affect SPF. A failure after forwarding needs interpretation alongside DKIM and DMARC rather than an immediate declaration of fraud. Ask the administrator to describe the actual path that was tested.
- Which services and domains were included?
- Was the existing SPF policy reviewed before replacement?
- Did the full policy stay within the lookup limit?
- What passed, what failed, and who owns each exception?
What is the sensible next step?
Gather your sender inventory before requesting a record change. A successful SPF review should make the authorized sending setup easier to explain. It should not end with a claim that SPF alone has made every email safe.