Gmail 550 5.7.26: why your mail bounced and how to fix it

What the bounce means

A 550 5.7.26 rejection from Gmail means a message using your domain in the From: address arrived unauthenticated: it did not pass SPF or DKIM in a way that aligns with your domain. Since Google's February 2024 sender rules, Gmail rejects that mail rather than accept a forgery.

You will see one of three wordings, and they point at different causes:

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.

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

550 5.7.26 Unauthenticated email from example.com is not accepted
due to domain's DMARC policy. Contact the administrator of
example.com domain if this was legitimate email.

The first is the unauthenticated flavor: the sender failed Google's baseline, in force for every sender since February 2024, that mail carry at least SPF or DKIM. The second is the SPF hard-fail flavor: the envelope domain publishes an SPF record ending in -all, the sending IP is not in it, and Gmail honored that hard fail. The third is the DMARC-policy flavor: your domain publishes p=reject, and this message failed DMARC, so Gmail honored your policy and rejected it.

The three things that cause it

Every 550 5.7.26 traces back to one of three situations. Identify yours first:

• 1. The sending tool was never authenticated. A new ESP, CRM, or form tool sends as your domain, but you never published its SPF include or its DKIM key. There is nothing for Gmail to check, so it fails.
• 2. Authentication exists but does not align. The tool signs with its own domain and SPF passes for its return-path, but neither lines up with your From: domain. DMARC needs alignment, not just a pass, so it still fails. This is the most common and most confusing cause.
• 3. The mail is forged. Someone is sending as you and Gmail is rejecting it. In that case the bounce is not a problem to fix, it is your authentication doing its job.

How to fix each

• Cause 1, unauthenticated tool: add the sending tool's SPF include to your SPF record and publish its DKIM key (most providers give you a CNAME or TXT to add). Our per-tool setup guides walk the exact records provider by provider.
• Cause 2, broken alignment: configure aligned DKIM for the tool, usually by CNAMEing the provider's DKIM selector onto a subdomain you control, so the signature is for your domain, not theirs. Aligned DKIM is the most reliable way to pass DMARC for third-party senders.
• Cause 3, a forged source: nothing to fix on that stream. Confirm from your DMARC reports that the source is not one of your own tools, then leave your policy enforcing.

The hard part is usually telling cause 2 from cause 3, both look like “failing mail from a source I half-recognize.” That is exactly what DMARC aggregate reports answer, and what trustyourinbox classifies for you: known sender versus unknown, aligned versus not, forwarded versus forged.

How to confirm it is fixed

• Re-check the records. Run a free DMARC audit (and the SPF and DKIM checkers) to confirm the record you added resolves and parses.
• Send a test and read the headers. Mail yourself, open the original, and confirm the Authentication-Results shows dkim=pass (or spf=pass) and dmarc=pass. Our header analyzer reads it in plain English.
• Watch the reports. Over the next day or two, the failing source should flip to passing in your DMARC aggregate reports. If it does not, the record is published but not aligned, recheck cause 2.

Frequently asked