Why does Gmail bounce my email with 550 5.7.26?

Gmail blocked the message because it passed neither SPF nor DKIM, or because it came from a server missing from an SPF record that ends in -all. Gmail asks this of every sender, whatever the volume. The owner of the sending domain fixes it, with whoever runs the server that sent the mail. If your bounce says the mail "is not accepted due to domain's DMARC policy", read that page instead.

The bounce

Google's list of Gmail SMTP errors has three texts under 550 5.7.26. Two of them are this page's subject. The first:

This email has been blocked because the sender is unauthenticated. Gmail requires all senders to authenticate with either SPF or DKIM. Authentication results: DKIM = did not pass SPF [domain-name] with ip: [ip-address] = did not pass. For instructions on setting up authentication, go to Email sender guidelines.

The second:

The (E)MAIL FROM domain [domain-name] has an SPF record with a hard fail policy (-all) but it fails to pass SPF checks with the ip: [ip-address]. To best protect our users from spam and phishing, the message has been blocked. For more information, go to Email sender guidelines.

Gmail also has a temporary form, 421 4.7.26, which starts "This email has been rate limited because it is unauthenticated." It has the same cause and the same fix.

What Gmail checked

Gmail's sender guidelines ask every sender to "Set up SPF or DKIM email authentication for your sending domains", and say that unauthenticated messages "might be marked as spam or rejected with a 5.7.26 error."

The first text: Gmail checked SPF for the domain in the envelope sender, the bounce domain, and looked for a DKIM signature. Neither passed. The bounce names the domain SPF checked and the address of the server that sent the message.
The second text: the envelope sender's domain has an SPF record that ends in -all, which tells receivers to fail every server not on its list. The sending server is not on it, so Gmail blocked the message.

Who has to fix it

The owner of the domain the bounce names, and whoever runs the sending server.

A service sends as your domain. Add its include to your SPF record and turn on DKIM in the service. A new service that nobody set up for your domain is the usual case.
A device or server of yours sends directly. A scanner, a website, a booking system or an office server often sends with no DKIM signature, from an address your SPF record does not list. Send it through your email provider's server with a login, or add the server's address to your SPF record and sign its mail.
You never sent the message. Someone else sent mail with your domain as the return address, and Gmail's bounce came back to you. Your records did their job, and there is nothing to fix.

Changing -all to ~all does not make the mail authenticated. A message that passes neither SPF nor DKIM still gets the first text.

The records

For example.com, with Google Workspace and one newsletter service:

example.com                TXT    v=spf1 include:_spf.google.com include:_spf.newsletter.example -all
s1._domainkey.example.com  CNAME  s1.dkim.newsletter.example

SPF lists every server and service that sends as you. A domain has one SPF record, so add to it rather than publishing a second one. Fix your SPF record shows how.
DKIM is the key each service gives you, under the selector it names. Set up DKIM for a sending service has the steps.

What it looks like in your DMARC reports

In the aggregate reports for your domain, the source behind the first text shows up as a row with no authentication at all:

<row>
  <source_ip>192.0.2.10</source_ip>
  <count>40</count>
  <policy_evaluated>
    <disposition>none</disposition>
    <dkim>fail</dkim>
    <spf>fail</spf>
  </policy_evaluated>
</row>
<identifiers>
  <header_from>example.com</header_from>
</identifiers>
<auth_results>
  <spf>
    <domain>example.com</domain>
    <result>fail</result>
  </spf>
</auth_results>

auth_results has no dkim element, so the mail carried no signature, and SPF failed for your domain. disposition is "The result of applying the DMARC policy" (RFC 9990, section 3.1.1.9). With p=none it can say none for mail that Gmail blocked under its own rule, so read the checks, not the disposition.

The source behind the second text can carry a DKIM signature that passes. Its row then shows spf as fail under auth_results, for the domain the bounce names, while dkim shows pass. DMARC may even pass through DKIM, and Gmail still blocked the message for the hard fail. Add the sending server to that domain's SPF record.

In Mailmoni, the explanation of a source with no authentication says either that a service we recognise is not set up for your domain, or that the mail may be someone else sending as you.