E-Mail · Gmail · DNS · Help

Gmail rejects customer replies with 550 5.7.26

Match the complete rejection to the actual sending path and check SPF, DKIM and DMARC according to the evidence.

Source date: 5 November 2026Editorial team: KAN KAI WORKSEditorially updated:

Quick answer

Gmail uses 550 5.7.26 for different sender authentication failures. The complete bounce determines which diagnostic path applies. For affected replies, compare the actual sending identity and SMTP route with a working message, including SPF, DKIM and DMARC relationships. Merely publishing a DNS record does not prove correct alignment. Avoid broadly weakening policies; verify the affected route with a clearly marked test message.

Source basis: Q1 · Q2

Applies to
Covers Gmail SMTP rejections using 550 5.7.26. The customer-reply report was accessible only as a title; diagnosis relies on Google's documented errors and sender requirements.
How to verify the result
A test message using the affected identity passes the relevant authentication checks and reaches the intended recipient, with headers and sending route matching the corrected configuration.
Your first check

Which authentication check does the complete bounce identify?

Keep the full diagnostic section and sending time. Code 5.7.26 alone does not distinguish the documented SPF, DKIM and DMARC variants.

You reply to a customer and receive a bounce containing 550 5.7.26. The address can be correct and other recipients may still accept the message. Google uses this code for several authentication-related failures. The complete text after the code therefore matters more than an assumption that the customer personally blocked you. Q1

Identify the actual sender path

The visible company address, technical return-path domain and DKIM signing domain are separate values. Diagnosis depends on how this particular message was sent and whether the relevant domains align. Q2 A reply can select a different identity or outgoing server from a newly composed message.

Turn the bounce into a specific finding

  1. Preserve the diagnostic information. Record time, recipient domain, Message-ID and the complete SMTP diagnostic section. Redact message content and personal addresses before sharing. Repeatedly sending the same customer reply is not initially a useful test.
  2. Identify the sending channel. Was it webmail, Thunderbird, a CRM or a website? Compare that exact path with a working one. For replies, inspect the selected sender identity and its associated SMTP server as well as the visible From address.
  3. Follow the stated failure. For SPF, compare the actual sending infrastructure with the domain being checked. For DKIM, inspect the selector and active signing configuration. For DMARC, include the relationship to the visible sender domain. Q1
  4. Compare DNS with active settings. A published TXT record does not establish that the sending platform uses the matching key, domain or route. Inspect the public value and the concrete sender's configuration together.
  5. Evaluate a harmless test message. Following a justified correction, send one clearly marked message to a controlled mailbox. Inspect its authentication results and actual arrival. Avoid using confidential customer correspondence as diagnostic material.

Correct the originating configuration

Authorise only the services that genuinely need to send and correct the specific identity mapping. Weakening DMARC policy or broadly expanding SPF does not diagnose a misconfigured sender. If forwarding is involved, investigate that additional transfer path rather than assuming the original submission path is the only relevant one.

For handoff, prepare the sanitised bounce, sending channel, relevant domains, DNS-change time and headers from the test message. A community title containing the same code is not a diagnosis of your message; the original candidate discussion was not fully readable during the current retrieval. Q3

Frequently asked questions

Why are only replies rejected?

First check whether replies select a different identity or SMTP route from new messages.

Is having an SPF record enough?

No. It must match the actual sending path, and the particular rejection may also involve other authentication requirements.

Describe your case

Support with this issue

We can correlate the sending path, DNS records and authentication results.

Describe your case →Related service: Data & improvements

Sources