550 5.7.26" unauthenticated mail rejected by gmail
Resolves Gmail rejecting unauthenticated mail with 550 5.7.26 by publishing SPF and DKIM and aligning them for bulk and transactional senders. Use when Gmail returns 550 5.7.26 for your legitimate mail. Not for Gmail rejects for spam content or recipient errors.
TL;DR
Gmail returns 550 5.7.26 when a message fails authentication checks it now requires, especially for bulk senders: SPF or DKIM must pass and align, and a DMARC record must exist for the From domain. Publish all three, make sure the sending stream actually signs, and check alignment rather than assuming a record alone is enough. Then resend, because Gmail evaluates each message as received.
"550 5.7.26" unauthenticated mail rejected by gmailUse this when
- Gmail bounces legitimate mail with 550 5.7.26 while other receivers accept it.
- Rejections started after raising sending volume from the domain.
Not for this skill when
- The bounce is 5.7.1 for policy or content reasons. That is a different Gmail decision.
- Mail is rejected for a missing PTR or TLS issue. Fix that specific cause.
Steps
- Read the full bounce text and confirm it names authentication as the reason. Verify: 5.7.26 is tied to SPF, DKIM or DMARC in the message.
- Check DNS for an SPF record, a published DKIM key for the selector your sender uses, and a DMARC record at _dmarc. Verify: all three records exist and parse.
- Send a test message to a Gmail mailbox and inspect Authentication-Results there. Verify: at least one of SPF or DKIM passes and aligns with the From domain.
- For bulk streams, confirm one-click unsubscribe and low complaint handling are in place, since authentication alone does not restore bulk acceptance. Verify: the bulk requirements beyond authentication are covered.
- Resend real mail and monitor bounces for 24 hours. Verify: 5.7.26 bounces from Gmail stop.
Variant phrasings
550 5.7.26 multiple authentication checks failed gmail
The fuller bounce text variant.
gmail bulk sender authentication requirements 5.7.26
The bulk sender requirements variant.
Compatibility: Gmail sender guidelines for bulk senders, RFC 7208, RFC 6376 and RFC 7489.
Why it happens
Gmail tightened sender authentication so unauthenticated bulk mail is refused at SMTP time instead of junked. Domains that relied on a single weak signal, or vendors that never signed, cross the threshold as soon as volume qualifies them as bulk senders.
Edge cases / pitfalls
- A DMARC record with p=none satisfies the record requirement, but alignment is still evaluated.
- Subdomains used by vendors need their own authentication story. Gmail checks the actual From domain.
- Fixing DNS does not clear an existing spam-folder reputation. Expect placement to recover more slowly than the bounce.
Provenance
Resolved from the public thread: https://vectle.com/posts/pst4juVguejzxnBFBUA0DA