Error 550 5.7.26 “This mail is unauthenticated” — why Gmail rejected your message and how to fix it

What this error means

Google rejected your message at delivery. The bounce typically reads:

550-5.7.26 This mail is unauthenticated, which poses a security
550-5.7.26 risk to the sender and Gmail users, and has been blocked.
550-5.7.26 The sender must authenticate with at least one of SPF or
550-5.7.26 DKIM.

Variants of 5.7.26 mention SPF, DKIM or domain alignment.Gmail could not authenticate the message as required.SPF checks whether the sending IP is authorised; DKIM verifies a cryptographic signature. Neither proves the sender’s intent.

Why you’re seeing it

• SPF or DKIM did not pass as required. All senders need SPF or DKIM. Bulk senders need both plus DMARC; DMARC passes when at least one passing method aligns with the From domain.
• A third-party service sends as your domain without authorisation. Invoicing platforms, booking systems, web-shop plugins and CRMs are the usual suspects. The service works fine for months while Gmail builds a reputation picture, then rejections begin.
• Forwarding broke SPF. Mail forwarded through another server (an alias, an old mailbox redirect) arrives from an IP your SPF never authorised. DKIM can survive forwarding if the signed content is unchanged; SPF doesn’t — which is why configuring both matters.
• Your domain has no DMARC record. Google requires a DMARC policy for bulk senders and uses its presence as a trust signal for everyone else.
• DNS errors. Syntax errors and duplicate SPF records can cause permerror. Exceeding the lookup limit causes permerror on the evaluated path; aligned DKIM can still pass DMARC.

How to fix it

1. Check the published SPF, DKIM and DMARC records.A free Merula account monitors one domain’s public configuration. Verify message-level alignment using test-message headers or received DMARC reports; DNS checks alone cannot confirm that a sending service authenticates its mail.
2. Find the sender that failed. Check the bounced message’s original sending service. In Google Workspace, Gmail headers (Authentication-Results) show exactly which check failed.
3. Authorise it properly: add the service to your SPF record and enable DKIM signing with your own domain in the service’s admin settings. Prefer DKIM — it survives forwarding and is the stronger long-term signal.
4. Publish DMARC with a reporting address. Received aggregate reports show sources and authentication results seen by the reporting receivers. Many arrive after 24–48 hours, but delays and incomplete coverage are possible.
5. Fix the record, not just the symptom. If your SPF is at or near 10 lookups, consolidate now; the next tool you add can tip a path into permerror.

EU context

Google’s requirements apply identically across all member states, and they align with what European security authorities already recommend: national CSIRTs across the EU — following CERT-EU’s DMARC guidance — advise deploying SPF, DKIM and DMARC, starting in monitoring mode and moving to enforcement. For businesses with NIS2-related obligations, or supplying companies that have them, demonstrable email authentication is shifting from best practice to contractual expectation.