Preserve the complete rejection before changing DNS
Gmail 550 5.7.26 identifies an authentication problem, but the enhanced status code is not a single root cause. Save the full non-delivery report, the rejection timestamp, the sending service and the visible From address. The diagnostic text can distinguish a message that failed both SPF and DKIM from one that authenticated under identities that do not align with the author domain. Removing that context and keeping only the code turns a specific incident into guesswork.
Map the identities used by the rejected message
Write down the RFC 5322 From domain seen by the recipient, the envelope sender or Return-Path domain, and every DKIM d= signing domain and s= selector. These values often differ when a marketing platform, support desk or transactional API sends for a brand. SPF authenticates the envelope path, DKIM authenticates a signing domain and DMARC evaluates whether a passing path aligns with the visible From domain. A green DNS dashboard for the company root domain does not prove that the rejected stream used those identities.
Test SPF for the actual sending IP and envelope domain
Use the IP and envelope domain from the failed production route. Follow SPF include and redirect dependencies to the final authorization result and count DNS-producing terms across the complete evaluation path. Do not add a second SPF record or copy a provider include blindly: multiple SPF records and over-complex dependency chains can turn a narrow authorization issue into a permanent error. If a provider uses its own bounce domain, SPF may pass for that provider yet remain unaligned with the From domain.
Inspect the DKIM selector named by the message
Query s=._domainkey.d= using the selector and signing domain from DKIM-Signature. Confirm that the TXT or delegated CNAME resolves to one applicable public key and that the selector has not been revoked. DNS presence alone is incomplete evidence because the sending stream may use an old selector, sign with a different domain or produce a signature that fails verification. For a delivered retest, receiver-stamped Authentication-Results should report dkim=pass for the expected d= identity.
Evaluate DMARC alignment against the visible From domain
DMARC can pass when either a valid SPF identity or a valid DKIM signing identity aligns with the RFC 5322 From domain under the effective alignment mode. A DMARC p value requests receiver handling; it does not make an unaligned authentication path pass. Discover the policy that applies to the author domain, then compare the actual MailFrom and DKIM d= domains rather than assuming that any SPF or DKIM pass is enough.
Correct the third-party sender at the source
For an external platform, complete its authenticated-domain setup for the exact sending stream. That may include publishing its DKIM selectors, configuring a custom return path, verifying the From domain and removing obsolete records only after the replacement is active. Keep marketing, transactional and employee routes separate in the investigation: they can use different IPs, selectors and envelope domains even when the visible From domain looks similar.
Retest the same route with receiver evidence
Send a fresh message through the same application, provider account, From domain and traffic class that generated the rejection. Inspect the complete delivered header at a receiver and confirm the intended SPF result, DKIM result and DMARC alignment in Authentication-Results. Also recheck the public DNS state after propagation. A durable fix is demonstrated by the receiver evaluating the new message successfully, not only by a vendor control panel changing to green.
A compact incident checklist
Keep the original NDR and timestamp; record From, Return-Path, sending IP, DKIM d= and s=; validate the full SPF path; inspect the active DKIM key; discover the effective DMARC policy; compare alignment; correct the exact provider stream; and retest with a delivered header. If the new evidence is healthy but Gmail still rejects the route, continue with reputation, rate and provider-policy investigation without undoing working authentication.
Verify the evidence
Use the live analysis that matches this workflow instead of relying on a generic status check.