# What are Gmail and Yahoo error codes and how can I fix them? > Gmail and Yahoo error codes explain a temporary or permanent SMTP failure. Preserve the full response, identify its cause, repair it, and retest. Gmail and Yahoo error codes are SMTP responses that tell a sending server why delivery was deferred or rejected. A `4xx` response is temporary and a `5xx` response is permanent for that attempt, but neither numeric code is a complete diagnosis. Preserve the entire response and its sending context, identify the evidence you control, apply the narrowest repair, then retest through the same production path. ## Quick takeaways - A `4xx` SMTP response asks the sending system to retry, while a `5xx` response rejects the delivery attempt. - Gmail and Yahoo use response text alongside numeric and enhanced status codes, so the full response matters more than the number alone. - A Gmail `550 5.7.26` response can indicate different authentication branches, including SPF, DKIM, and DMARC-related failures. - Public DNS checks show published records, not the authentication result of a specific production message. - Receiver reputation and policy decisions are provider-specific. A sender cannot prove or change them through DNS alone. - Do not lower a DMARC policy to conceal an authentication failure. Repair the affected sending path. ## What does the failure mean? SMTP replies tell the sending server whether a recipient system accepted, temporarily deferred, or rejected a message. [Google's SMTP error overview](https://knowledge.workspace.google.com/admin/support/troubleshooting/about-smtp-error-messages) explains that replies beginning with `4` are temporary failures and replies beginning with `5` are permanent failures. A temporary response still needs investigation when it repeats. A permanent response needs a supported correction before retrying the same path. The following is an illustrative redacted response fragment. It shows the evidence pattern to preserve, not a universal Gmail or Yahoo diagnosis. ```text 4xx: temporary SMTP failure 5xx: permanent SMTP failure 550 5.7.26 550 5.7.1 ``` The response class identifies how the receiver handled that delivery attempt. The enhanced status code and explanatory text identify the branch to investigate. [Google's SMTP error reference](https://support.google.com/mail/answer/3726730?hl=en) documents multiple authentication-related conditions under `550 5.7.26`, including messages that do not pass SPF or DKIM checks, SPF hard-fail situations, and unauthenticated mail that Gmail does not accept under the sender domain's DMARC policy. ### Response evidence packet Keep a labelled evidence packet for every repeated Gmail or Yahoo response: - **Complete SMTP response and enhanced status code:** Preserve the exact returned text, including punctuation and links. - **Provider and recipient domain:** Record whether the recipient uses Gmail, Yahoo, or another destination, plus the recipient domain. - **Timestamp and timezone:** Record when the response occurred in a timezone that incident responders can compare with mail logs. - **Sender IP and sending service:** Record the outbound IP and the application, mailbox, ESP, relay, or gateway that submitted the message. - **Authenticated identifiers:** Record the envelope sender, visible From domain, DKIM `d=` domain, DKIM selector, and results from a receiver-added `Authentication-Results` field when available. - **Sending application:** Identify the exact application or workflow that produced the message. - **Recipient scope:** State whether the response affects one recipient, one recipient domain, or an entire sending stream. - **Controlled retry outcome:** Record whether one approved retry later succeeded, deferred again, or received the same permanent response. The full response and context prevent a common mistake: changing a public DNS record because a numeric code sounds authentication-related, when the actual response points to a recipient, route, content, or provider-policy issue. ![Flow showing how to preserve a Gmail or Yahoo SMTP response, classify it, inspect sender-controlled evidence, and retest the same path](/images/editorial/what-are-gmail-and-yahoo-error-codes-and-how-can-i-fix-them/what-are-gmail-and-yahoo-error-codes-and-how-can-i-fix-them-response-evidence-flow.webp "1200x829") *Source: Palisade.* ## What usually causes it? ### Gmail reports an authentication failure under 550 5.7.26 Gmail documents more than one cause under `550 5.7.26`. A message may lack passing SPF and DKIM authentication, fail SPF where the domain publishes a hard-fail `-all` mechanism, or fail Gmail's documented DMARC-related branch for unauthenticated mail. Match the complete Gmail response to [Google's documented SMTP error branch](https://support.google.com/mail/answer/3726730?hl=en) before editing DNS. For DMARC, SPF or DKIM must pass and align with the visible From domain. [RFC 8601 defines `Authentication-Results`](https://www.rfc-editor.org/rfc/rfc8601.html), the header field receiving systems use to communicate message authentication status. The header is stronger evidence than a DNS lookup because it describes the delivered test message. ### Gmail returns 550 5.7.1 for another sender problem `550 5.7.1` is not a universal blocklist verdict. Google's reference documents distinct conditions under this response family, including direct-to-MX restrictions, recipient or domain policy conditions, and IP or [domain reputation](/tools/domain-reputation) signals. Use the explanatory text to select the next action. If the response identifies an unsupported direct connection, review the sending service's supported relay route. If it identifies reputation or a policy condition, inspect the affected stream and compare it with [Google's Gmail sender guidelines](https://support.google.com/a/answer/81126?hl=en). A DNS edit does not prove or alter Google's private reputation assessment. ### Yahoo temporarily defers the message [Yahoo's SMTP error-code reference](https://senders.yahooinc.com/smtp-error-codes/) separates temporary `421` and `451` responses from permanent failures. Yahoo documents temporary categories that can relate to unusual traffic, spam-like characteristics, user complaints, temporary nameserver failures, or temporary authentication evaluation errors. A repeated deferral is evidence to inspect the sending path and retry behavior. It does not prove that an SPF, DKIM, or DMARC record is wrong. ### Yahoo permanently rejects the message Yahoo also documents permanent response categories, but the accompanying text determines whether the issue concerns a connection, a message, a recipient, authentication, or receiver policy. Do not assign one meaning to `553` or `554` when the documented response text is unavailable. The practical conclusion is an operational inference: combine Yahoo's full response with the message evidence before changing configuration. ![Checklist for diagnosing Gmail and Yahoo SMTP errors using response text, authentication results, DNS, sending route, and retry outcome](/images/editorial/what-are-gmail-and-yahoo-error-codes-and-how-can-i-fix-them/what-are-gmail-and-yahoo-error-codes-and-how-can-i-fix-them-gmail-yahoo-error-diagnosis-checklist.webp "1200x639") *Source: Palisade.* ## How do I diagnose the failure? ### 1. Preserve the complete receiver response Export the SMTP transcript or bounce exactly as received. Save the numeric code, enhanced status code, explanatory text, queue ID, timestamp, recipient domain, envelope sender, and sending IP. Do not rely on a mail-client screenshot. The response may identify a sending IP, authentication condition, or policy branch that is absent from the rendered message. ### 2. Classify the reply without treating it as a diagnosis For a `4xx` response, confirm that the mail system follows its normal retry policy. Then determine whether the same response repeats for the same provider, recipient scope, and sending path. For a `5xx` response, pause repeated attempts until you identify the documented cause. Repeating a permanent authentication or recipient error does not repair it. ### 3. Inspect authentication evidence from the same path Send or obtain a delivered test message from the same application, outbound service, envelope sender, visible From domain, and route. Record the receiver-added `Authentication-Results` field, including SPF, DKIM, and DMARC outcomes where present. The [email authentication learning hub](/learning) explains how SPF, DKIM, and DMARC relate. A public DNS record can appear correct while the production sender uses a different envelope domain, DKIM selector, or outbound relay. ### 4. Check only the public record that matches the evidence When a Gmail response identifies an authentication or DMARC branch, use the [DMARC checker](/tools/dmarc) to inspect the published DMARC record for the visible From domain. Compare the lookup with the failed message's headers. A DMARC record has this structural shape: ```text Illustrative only. Do not publish this value without reviewing your reporting and policy requirements. _dmarc.yourdomain.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com" ``` The lookup shows what public DNS returns. It cannot prove why Gmail or Yahoo handled one message a certain way, show every production sender, or reveal a receiver's private policy decision. ### 5. Map the actual sending service Map the route from the sending application through the outbound service, relay, and any gateway to Gmail or Yahoo. Identify which service sets the envelope sender, which service applies DKIM, and whether another service rewrites or relays the message. If SPF hard-fails, compare the sending IP and envelope domain with that envelope domain's SPF record. If DKIM is expected to support DMARC, compare the DKIM `d=` value with the visible From domain. The related guide on [resolving Yahoo and Gmail email error codes](/learning/how-can-you-resolve-yahoo-and-gmail-email-error-codes) can help organize the provider response with sender evidence. ## How do I fix it? ### Repair the authenticated identity identified by Gmail When Gmail's full response identifies missing SPF or DKIM authentication, repair the configuration for the actual sending path. Confirm that the outbound service uses the intended envelope domain and that its DKIM signature is present and valid. For a DMARC-related response, repair the authentication and alignment failure. Changing `p=` to a less strict value changes requested enforcement. It does not repair the sender that failed authentication. > Do not publish an SPF record copied from another tenant or service. Use the value generated for your own sending service, and change SPF only after confirming the envelope domain and authorized senders. ### Correct a recipient or address issue If the response identifies an unknown, disabled, blocked, or otherwise unavailable recipient, correct the address or recipient-side condition through the appropriate owner. SPF, DKIM, and DMARC changes do not fix a recipient-address failure. Retest only with an authorized recipient. Do not use repeated retries to probe an address. ### Treat provider-specific temporary responses as temporary For a documented Yahoo temporary response, preserve the evidence packet, allow the approved queue retry, and reduce or pause the affected stream if your sending platform and provider guidance require it. Check whether the retry succeeds through the same route. Do not turn a temporary response into a permanent diagnosis based only on its first numeric code. If it repeats, collect the full response and consult the provider documentation that matches its text. ### Escalate a persistent provider-policy response with evidence When the same provider-specific response persists after sender-controlled authentication and route checks pass, use the provider's official guidance or support route named in the returned response. Include the redacted response packet and controlled retry outcome. This is appropriate for a receiver policy or reputation decision that public DNS cannot explain. Neither Palisade nor a DNS checker can change a mailbox provider's private reputation or guarantee future acceptance. ## How do I validate the repair? Send a new message through the same application, sending service, envelope sender, visible From domain, and recipient provider that produced the failure. Compare the new SMTP result with the preserved response packet. Validate at each applicable layer: - **DNS:** Query the authoritative DNS source and a public resolver for the record you changed. - **Vendor:** Confirm the outbound service reports the intended authentication configuration, when it provides a verification state. - **Message:** Inspect the raw source of a delivered message and its trusted receiver-added `Authentication-Results` field. - **DMARC:** After reports accumulate, review aggregate-report data for the same sending source and alignment outcome. A passing DNS lookup or vendor indicator is not proof that the production message used the intended configuration. Keep the passing raw message, response comparison, configuration change, and rollback condition in the incident record. ## Check the DMARC record behind an authentication response If the Gmail or Yahoo response points to DMARC or authentication, inspect the visible From domain's published DMARC record before changing policy. Compare the result with the same-path message headers and the exact receiver response. [Check the DMARC record](/tools/dmarc) A public DMARC check cannot identify every sender using the domain, prove why one receiver rejected one message, monitor later changes, or control Gmail's or Yahoo's private policy decisions. Palisade is AI-first, agent-first DMARC software that analyzes DMARC aggregate-report data, identifies sources and authentication or alignment issues, and creates prioritized remediation tickets. It can propose a next policy step for human review, but it does not change a mailbox provider's delivery decision or autonomously change your DMARC policy. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=email_authentication&utm_content=what-are-gmail-and-yahoo-error-codes-and-how-can-i-fix-them) ## Sources and further reading - [Google Workspace Admin Help: About SMTP error messages](https://knowledge.workspace.google.com/admin/support/troubleshooting/about-smtp-error-messages) - [Google Help: SMTP errors and codes](https://support.google.com/mail/answer/3726730?hl=en) - [Google Workspace Admin Help: Email sender guidelines](https://support.google.com/a/answer/81126?hl=en) - [Yahoo Sender Hub: SMTP error codes](https://senders.yahooinc.com/smtp-error-codes/) - [RFC 8601: Authentication-Results header field](https://www.rfc-editor.org/rfc/rfc8601.html) ## Frequently asked questions ### Is a 4xx Gmail or Yahoo error safe to ignore? No. A `4xx` response is temporary for that delivery attempt, but repeated deferrals can indicate a recurring provider-specific condition. Preserve the full response and check whether controlled retries succeed through the same sending path. ### Does Gmail 550 5.7.26 always mean DMARC failed? No. Google documents multiple authentication-related branches under `550 5.7.26`, including SPF and DKIM conditions. Use the full response and receiver-added authentication results to identify the documented branch. ### Does Gmail 550 5.7.1 mean my IP is blocklisted? No. Google documents several conditions under `550 5.7.1`, including connection restrictions, policy conditions, and reputation signals. The accompanying response text determines the next investigation. ### Can a DMARC checker explain a Yahoo rejection? No. A DMARC checker can inspect the public record for the visible From domain. It cannot inspect Yahoo's private receiver policy, authenticate a past message, or prove why Yahoo rejected an individual delivery attempt. ### Should I change DMARC to p=none after a Gmail rejection? No. Lowering the DMARC policy changes requested enforcement but does not repair SPF, DKIM, alignment, a recipient issue, or a provider-specific policy response. Repair the confirmed sending-path problem first.