First, identify the SPF domain
For DMARC, the SPF-authenticated identity is normally the SMTP MAIL FROM envelope domain; when the reverse-path is empty, SPF uses the HELO/EHLO identity. Either can differ from the visible From: header, which is the identity DMARC asks an authenticated domain to align with. A passing SPF result by itself does not mean SPF is aligned with the visible sender.
Read the result on a real message
Send a test message through the affected sending service to a mailbox you can inspect. Open the received message's original headers and find the trusted receiving system's Authentication-Results entry. Look for the SPF result and its smtp.mailfrom identity, then compare the DMARC result and header.from domain.
Authentication-Results: mx.receiver.example;
spf=pass smtp.mailfrom=bounces.brand.example;
dmarc=pass header.from=brand.exampleThis is an illustrative header, not a result for a live domain. The receiver may format fields differently. Use the authentication result added by the mailbox provider you trust; earlier copies of that header can be supplied by the sender. Some systems also include a Received-SPF header.
In Gmail, open the message menu and choose Show original. Other mailbox providers have a similar “view source” or “view message details” option.
Inspect the published TXT policy
Query the exact domain shown in smtp.mailfrom, not automatically the visible From domain. Replace the example below with that domain:
dig +short TXT bounces.brand.exampleLook for the single TXT policy that begins with v=spf1. A domain may have many TXT records for unrelated purposes; the duplicate-record problem is multiple separate policies beginning with v=spf1, not multiple TXT answers in general. DNS tools may display one long TXT value as several quoted chunks.
If you manage DNS at a provider dashboard, compare its saved value with the public answer and check the record name carefully. A record published at the root domain does not automatically apply to a separate bounce subdomain.
Match the symptom to the next check
“PermError” or more than one SPF policy
RFC 7208 expects one SPF policy for a domain. Query its TXT records and count the answers that start with v=spf1. If more than one exists, receivers can return permerror; they do not reliably combine the policies. Inventory every active sender, ask each provider for its current approved SPF mechanism, and merge the required mechanisms into one policy before removing the duplicates. Do not discard a sender's entry until you confirm it is no longer used.
SPF returns “none,” “fail,” or “softfail”
Confirm that DNS has a policy at the exact envelope domain. Then compare the sending IP in the receiver's result with the policy's mechanisms. Ask the sending provider for the exact current include: value or authorized IP ranges; do not guess a hostname or copy an old setup from another account. Check for a retired or misspelled include and query each included name to inspect the next published policy:
dig +short TXT _spf.provider.exampleFollow nested include:values in the same way, and compare the final chain with the provider's documentation. An include delegates part of the evaluation; it is not a substitute for confirming that the actual sending service and domain match.
“PermError: too many DNS lookups”
SPF allows at most 10 DNS-querying terms during one evaluation. Terms such asinclude:, a, mx, exists:,ptr, and redirect= can consume that budget, and lookups in nested includes count too. Trace the active include chain and count the terms actually evaluated; a quick count of the visible tokens in only the top-level record can miss nested usage. RFC 7208 also has a separate limit on void lookups (queries returning no data or no domain).
Remove mechanisms for retired senders only after confirming they are unused. Ask active providers about supported ways to reduce lookups. Static IP flattening can become stale when a provider changes its sending ranges, so use it only when you have a reliable update process. Re-query and send a new test message after publishing a change.
SPF passes, but DMARC reports fail
Compare smtp.mailfrom with the domain in header.from. For SPF to satisfy DMARC, the SPF-authenticated envelope domain must align with the visible From domain. Relaxed alignment accepts domains under the same organizational domain; strict alignment requires an exact domain match. Theaspf tag in the DMARC policy selects the mode (relaxed is the default in RFC 9989). For example, SPF can pass for a provider-owned bounce domain while failing SPF alignment with your visible From domain. Ask your provider whether it supports a custom return-path domain under your organization, or confirm that aligned DKIM passes instead. DMARC passes when SPF or DKIM produces an authenticated result aligned with the visible From domain.
SPF fails only after a message is forwarded
Forwarding often changes the connecting IP, so SPF may fail at the next receiver even though the original sender was authorized. Check whether aligned DKIM still passes and whether the receiving system reports ARC results. Do not add an unrelated forwarding server to your SPF policy as a general fix; ask the forwarding service about its supported authentication handling.
Use DMARC reports to find recurring sources
If your DMARC record requests aggregate reports with a rua= address, review reports for the reporting period and identify the source IP, volume, envelope domain, SPF result, and whether SPF aligned with the visible From domain. Report formats vary, and aggregate reports are delayed summaries rather than a per-message live check. Compare unfamiliar sources with your sending-provider inventory before changing DNS.
The standards describe these checks in RFC 7208 (SPF) and RFC 9989 (DMARC). For Gmail, see its official instructions for checking message authentication.
After you publish a correction
- Confirm the public TXT answer at the envelope domain reflects your change.
- Send a fresh test message from each active sending service.
- Read the receiving provider's SPF and DMARC authentication results.
- Check later aggregate reports for the same source and alignment pattern.
For the DNS publishing walkthrough, see SPF Record Setup. For a focused walkthrough of querying and reading one published record, see How to Check Your Published SPF TXT Record.