Skip to content
ReputeCastReputeCast Docs

Gmail 550 5.7.26: unauthenticated email blocked

How-to guide
For:
Publishers and marketers, Workspace admins
Needs permission:
domains:managesensitive, providers:view
In the app:
Settings, then Senders

Gmail 550 5.7.26 is a permanent refusal: the message failed email authentication, so Gmail blocked it. The fix is in your DNS records, not in your list. This page shows how to read the reply and get SPF, DKIM and DMARC passing for every sending provider you use.

What Gmail means

Section titled “What Gmail means”

Gmail sends the code with one of three texts:

This email has been blocked because the sender is unauthenticated. Gmail requires all senders to authenticate with either SPF or DKIM. Authentication results: DKIM = did not pass SPF [domain-name] with ip: [ip-address] = did not pass.

The (E)MAIL FROM domain [domain-name] has an SPF record with a hard fail policy (-all) but it fails to pass SPF checks with the ip: [ip-address]. To best protect our users from spam and phishing, the message has been blocked.

Unauthenticated email from domain-name is not accepted due to domain’s DMARC policy. Contact the administrator of domain-name domain if this was legitimate email.

Gmail also has temporary versions: 421 4.7.26 rate limits unauthenticated mail instead of blocking it, and 451 4.7.26 means temporary DNS failures prevented the DMARC check. Source: Gmail SMTP errors and codes, Google Workspace Help. Checked October 2026.

Why it happens

Section titled “Why it happens”
  • Neither SPF nor DKIM passed. The sending provider’s DKIM records aren’t published, or SPF doesn’t list the sending provider.
  • SPF hard-failed. Your SPF record ends in -all and doesn’t include the server that sent the message, for example a sending provider you added to a route later.
  • DMARC failed. Your DMARC policy is quarantine or reject, and neither SPF nor DKIM is aligned with the From domain. This happens when the sending provider signs DKIM with its own domain and uses its own return path.

How ReputeCast classifies it

Section titled “How ReputeCast classifies it”
  • Bounce class: policy_block for the first and third texts. The SPF hard-fail text mentions spam, so it is spam_block. The bare code without text is policy_block.
  • Report row: Blocked · policy or reputation.
  • Suppression: the refusal is about your domain, not the address. Most built-in adapters record it as a soft bounce, so nothing is suppressed. With Amazon SES, Resend, Postal, SendGrid, Mailjet and SMTP bounce mailboxes it can be recorded as a hard bounce, depending on how the sending provider reports it, and then the address is suppressed. See when ReputeCast suppresses an address.

Send Readiness checks the same records before every campaign. In its Authentication group, a missing SPF record, an SPF record that doesn’t authorize one of the campaign’s sending providers, unverified DKIM, or a missing or invalid DMARC record blocks the send. Less than 90% of mail aligned with DMARC over the last 7 days is a warning.

Before you begin

Section titled “Before you begin”
  • domains:manage to see and check the DNS records of a sending domain.
  • Access to the DNS host of your domain.
  • providers:view to read the event log.

Fix authentication

Section titled “Fix authentication”
  1. Read Gmail’s text. Open Sending providers, then Events & sync, filter Event type to Soft bounce or Hard bounce and search for a Gmail recipient. Original code · diagnostic shows which check failed and, in the first text, the domain and IP address Gmail tested.
  2. Open Settings, then Senders and the sending domain. Its records page lists the exact DNS records each sending provider needs for the domain, each with a status (Verified, Pending or Missing), and checks them every 30 seconds while it is open.
  3. Publish the missing or wrong records at your DNS host. A domain name can have only one SPF record (RFC 7208, section 3.2, checked October 2026), so merge what the records page asks for into the existing one. Follow set up SPF, DKIM and DMARC for the exact steps.
  4. Where the sending provider supports a custom MAIL FROM (return path) domain, set it up so SPF aligns with your From domain as well as DKIM.
  5. Wait for the records to show Verified. ReputeCast also checks DNS every 30 minutes, and a change shows up in Send Readiness within the hour. Then open the next campaign’s Review & send: the Send Readiness Authentication group must pass.

Check that it worked

Section titled “Check that it worked”
  • Every record on the sending domain’s page shows Verified.
  • The Authentication group of Send Readiness passes for the campaign.
  • The next campaign’s report has no 550 5.7.26 in Original codes.

Troubleshooting

Section titled “Troubleshooting”
  • Only one sending provider triggers it. Its DKIM records or its SPF include: are missing. Routes split mail across providers, so check every sending provider on the campaign’s route.
  • DMARC passes for some mail and fails for the rest. Read the DMARC aggregate reports to find the sources that fail alignment.
  • Addresses were suppressed for this bounce. After you fix authentication, you can remove them from Audience, then Suppression list with Remove from the list.
Section titled “Related”
Report a problem with this pageReputeCast websiteHostReputeContent licensed under CC BY 4.0