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 and Yahoo's 2024 bulk-sender rules, Gmail rejects that mail rather than risk delivering a forgery.

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

550-5.7.26 This message does not have authentication information
or fails to pass authentication checks (SPF or DKIM). To best
protect our users from spam, the message has been blocked.

550-5.7.26 Unauthenticated email from example.com is not accepted
due to domain's DMARC policy.

The first is the bulk-senderflavor: the sender failed Google's baseline that all mail carry at least SPF or DKIM. The second is the DMARC-policy flavor: your domain publishes p=quarantine or 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 genuinely forged. A spoofer 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 alignedDKIM 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 real spoofer: 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 actually 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

Is 550 5.7.26 my problem or the recipient's?

It is the sender's. The bounce means mail using your domain in the From: address reached Gmail without passing SPF or DKIM in a way that aligns with that domain. The recipient did nothing wrong; the fix is on the sending side.

Does 550 5.7.26 mean I was hacked?

Not necessarily. It means something sending as your domain is not authenticated. That is often a legitimate tool you set up but never configured for SPF or DKIM. It can also be a genuine spoofer, in which case the bounce means your protection is working.

How long does it take to fix 550 5.7.26?

The fix is publishing aligned SPF or DKIM for the sending tool, which is a DNS change. DNS updates usually propagate within minutes to a few hours. Once the record resolves, the next message authenticates and the bounce stops.

Do I need DMARC to fix 550 5.7.26?

For the bulk-sender flavor, Gmail requires at least SPF or DKIM; DMARC is strongly recommended but not strictly required to clear that specific bounce. For the DMARC-policy flavor, the rejection comes from your own published policy, so the fix is to authenticate the sender so it aligns.