Gmail 550-5.7.26: Unauthenticated Email Rejected

What the bounce actually looks like

A real bounce from Gmail reads roughly like this:

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

The hyphen in "550-" trips a lot of people up. It is not a different error code. SMTP uses a hyphen after the code on every line of a multi-line response except the last one, so "550-5.7.26" and "550 5.7.26" are the same thing.

The part almost nobody explains: one code, two problems

Search for this code and you will find page after page telling you to fix your DMARC record. That advice is right about half the time.

Gmail uses 550 5.7.26 for two genuinely different failures. The code is identical. The message after it is not. This second version is the one people miss:

This email has been blocked because the sender is unauthenticated.
Gmail requires all senders to authenticate with either SPF or DKIM.

Same code, different problem, different fix. Look at the words, not the number.

Telling the two apart

The whole diagnosis is in one sentence of the bounce. Read what comes after the code.

→If it mentions "domain's DMARC policy": you have published a DMARC record, and it tells receivers to reject mail that fails. Your message failed. Something you are sending from is not covered by your SPF record, or is not signing with DKIM, or is passing one of them on a domain that does not align with your From: address. Gmail is doing exactly what you asked it to do.
→If it says Gmail "requires all senders to authenticate with either SPF or DKIM": the problem is simpler and more basic. Your domain has no usable authentication at all. There is nothing for Gmail to check, and since February 2024 that alone is enough to be rejected.
→If you are not sure: check whether a DMARC record exists on your domain. If one exists, you are in the first case. If none exists, you are in the second. Our DMARC explainer covers what the record does.

Fixing case one: you are failing your own DMARC policy

A DMARC policy of p=reject or p=quarantine only makes sense once every legitimate source of your mail authenticates properly. Most failures here come from a sending service somebody set up and nobody added to the record.

1.List every system that sends as your domain. Your mailbox provider, your website contact forms and order emails, your newsletter tool, your invoicing software, your helpdesk, your CRM. This list is always longer than people expect.
2.Make sure each one is covered. Every sender needs to be included in your SPF record, or to sign with DKIM using your domain, or ideally both. Our SPF setup guide walks through the record itself.
3.Check alignment. Passing SPF or DKIM is not enough on its own. The domain in your From: header has to line up with the domain that passed. This is the single most common reason a message passes SPF and still fails DMARC.
4.Read your DMARC aggregate reports. They name the sources that are failing and the IPs they came from. That is far faster than guessing. Our DMARC setup guide covers turning reporting on.
5.Only then tighten the policy. If mail is already being rejected, it is reasonable to move temporarily to p=none while you fix the sources, so legitimate mail flows while you work. Move back up once the reports are clean.

Fixing case two: no authentication at all

This one is more work to discover than to fix, because the answer is almost always sitting in your mail provider's admin panel.

1.Publish an SPF record listing the services allowed to send as your domain. One SPF record per domain, no more. See how to set up SPF on a custom domain.
2.Turn on DKIM with your mail provider. Google Workspace, Microsoft 365 and every serious sending platform will generate the keys and give you the DNS records to publish. You do not create these by hand.
3.Add DMARC. Even a monitoring-only record gives you the reports that tell you what is really sending as you. See how to set up DMARC.
4.Wait for DNS to propagate, then send a test message to a Gmail address and check that it lands. Bounces stop as soon as the records are live and correct.

What Gmail requires from every sender

These rules have applied to everyone sending to Gmail since February 2024, no matter how small the volume.

→SPF or DKIM set up for your sending domain.
→A TLS connection for transmitting mail.
→Valid forward and reverse DNS records for your sending IP.
→A spam complaint rate below 0.3%. That is the figure Google documents. If you have read that the threshold is lower, that number is not from Google.
→Messages formatted to RFC 5322, with a valid From: address, and no impersonation of Gmail From: headers.

And more if you send in bulk

Bulk sender rules kick in at roughly 5,000 messages a day to personal Gmail addresses. On top of everything above, bulk senders need:

→SPF and DKIM and DMARC. All three, not a choice between them.
→From: alignment. The domain in your From: header must align with either the SPF domain or the DKIM domain.
→One-click unsubscribe in marketing and subscribed messages, implemented properly so the request is honoured within two days.
→Bulk status that does not lapse. Google states plainly: Bulk sender status doesn't have an expiration date. Dropping back under 5,000 a day does not release you from the obligations. Owners get this wrong constantly, usually after one big campaign.

Why this is worse in 2026 than it was in 2024

When the requirements first landed, non-compliant mail mostly got slowed down or filtered. That grace period is over. Google's own wording:

Starting November 2025, Gmail is ramping up its enforcement on
non-compliant traffic. Messages that fail to meet the email sender
requirements will experience disruptions, including temporary and
permanent rejections.

Permanent rejections means hard bounces. In 2026, unauthenticated mail to Gmail does not land in spam. It does not arrive at all, and neither you nor the recipient sees it unless you read your bounces.

The business cost of leaving this

Order confirmations, password resets, invoices and delivery notifications all go through the same pipe. If Gmail is rejecting your mail, a large share of your customers are simply not hearing from you.

Worse, it is invisible from the inside. Your own team gets your mail fine, because internal delivery does not go through Gmail's checks. You find out when customers start asking where their confirmation went.

If you want a quick read on where your domain stands, run it through the checker on this page, or work through our fix guides for the DNS records themselves.

Frequently asked questions

Is 550-5.7.26 the same as 550 5.7.26?

Yes. The hyphen is SMTP multi-line continuation, which means more lines of the same response follow. Every line except the last uses a hyphen after the code. It carries no meaning of its own and does not indicate a different error.

I already have SPF. Why am I still bouncing?

Two common reasons. Either the specific service sending the message is not covered by your SPF record, or SPF is passing on a different domain to the one in your From: header, which fails DMARC alignment. Your DMARC aggregate reports will name the source. So will the Authentication-Results header on a test message sent to a Gmail address.

Do these rules apply to me if I only send a few emails a day?

Yes. The all-senders requirements apply at any volume: SPF or DKIM, TLS, valid forward and reverse DNS, a spam rate below 0.3%, and RFC 5322 formatting. The extra bulk requirements only start at around 5,000 messages a day to personal Gmail addresses, but the baseline applies to everyone.

I sent one big campaign and then went back to normal. Am I still a bulk sender?

Google says bulk sender status does not have an expiration date. Once you have crossed the threshold, plan on the bulk requirements applying to you from then on. Set up SPF, DKIM and DMARC properly and one-click unsubscribe, and you never have to think about the threshold again.

How long after fixing DNS will mail start delivering?

As soon as the records are live and correct. DNS changes take anywhere from a few minutes to a few hours to propagate depending on your TTL. There is no review process and nothing to submit to Google. Send a test message to a Gmail address and check the headers to confirm.