Bounce codes · Temporary or permanent · also 4.7.26

550 5.7.26: Unauthenticated sender (no SPF or DKIM pass)

Gmail returns 5.7.26 when a message passes neither SPF nor DKIM, so Google cannot tell who actually sent it. The 421 4.7.26 form rate-limits you first; 550 5.7.26 blocks outright. Fix it by publishing an SPF record that covers your sending service and signing every message with DKIM.

The exact messages

Gmail / Google Workspace

550 5.7.26 This email has been blocked because the sender is unauthenticated. Gmail requires all senders to authenticate with either SPF or DKIM.

Gmail / Google Workspace

421 4.7.26 This email has been rate limited because it is unauthenticated. Gmail requires all senders to authenticate with either SPF or DKIM.

Gmail / Google Workspace

451 4.7.26 Unauthenticated email from domain-name is not accepted due to domain's DMARC policy, but temporary DNS failures prevent authentication. Please contact the administrator of domain-name domain if this was a legitimate email.

Microsoft 365 / Exchange Online

4.7.26 Access denied, a message sent over IPv6 [2a01:111:f200:2004::240] must pass either SPF or DKIM validation, this message is not signed

Why it happens

No SPF record on the sending domain, or one that does not include the server or service that actually sent the message.
No DKIM signature, or a DKIM key published under a selector your sender is not using.
A new sending tool was added (a cold email platform, a CRM, a helpdesk) without updating SPF or setting up its DKIM.
The SPF record exceeds 10 DNS lookups, so receivers treat it as a permanent error rather than a pass.

How to fix it

Check the domain with an SPF checker and confirm the sending service is included and the lookup count is 10 or under.
Turn on DKIM signing in the sending platform (Google Workspace and Microsoft 365 both require you to enable it) and publish the key it gives you.
Send a test to a Gmail address and read "Show original": SPF and DKIM should both say PASS.
Resend only after both pass; retrying unauthenticated mail keeps the domain on the rate-limited path.

If you send cold email

Every cold email domain needs SPF and DKIM before the first send, including the fresh lookalike domains bought for outreach. Setting up the mailbox but forgetting DKIM is the single most common reason a brand-new domain hits 5.7.26 on day one.

How WarmHawk handles it

WarmHawk checks SPF, DKIM and DMARC for each sending domain against live DNS and keeps "could not check" separate from "failed", so a flaky resolver never looks like a broken record. New mailboxes warm up by sending to partner inboxes and recording where each email landed, so an authentication problem shows up in the warmup results before the mailbox graduates to campaigns. How WarmHawk works →

Check your domain now

These free checkers read your live DNS: no account, up to 15 domains at once.

SPF record checker →DKIM checker →Full domain health check →

Related bounce codes

Sources, checked 2026-09-29: Google Workspace: Gmail SMTP errors and codes · Google: Email sender guidelines · Microsoft Learn: NDRs and SMTP errors in Exchange Online. Have a different bounce? Paste it into the decoder →

Questions

5.7.26 questions

What does 5.7.26 mean?+

Is 5.7.26 a temporary or permanent error?+

Both forms exist. A reply starting with 4 (such as 4.7.26) is temporary, and the sending server will retry; a reply starting with 5 is permanent, and the message will not be retried until you fix the cause.

How do I fix 5.7.26?+

Check the domain with an SPF checker and confirm the sending service is included and the lookup count is 10 or under. Turn on DKIM signing in the sending platform (Google Workspace and Microsoft 365 both require you to enable it) and publish the key it gives you. Send a test to a Gmail address and read "Show original": SPF and DKIM should both say PASS. Resend only after both pass; retrying unauthenticated mail keeps the domain on the rate-limited path.