Is 550 5.7.26 a reputation problem?

No. It is an authentication failure. Gmail could not tie the message to the domain in the From header, either because nothing passed SPF or DKIM, or because what passed belonged to a different domain than the one your recipient sees. Reputation bounces use different wording, usually 550 5.7.1 with a low reputation message.

I already have an SPF record and I still get 550 5.7.26. Why?

Almost always DMARC alignment. SPF can pass for the vendor sending on your behalf while the visible From header stays on your domain, and DMARC only counts a pass that belongs to the From domain. The fix is enabling the vendor's own domain authentication so the DKIM signature carries your domain, not theirs.

Should I delete my DMARC record to stop the bounces?

Do not delete it. Lower the policy to p=none while you repair alignment, keep the rua reporting address so you can see which senders still fail, and raise the policy again once every legitimate sender passes. Deleting the record throws away the only visibility you have into who sends as your domain.

Gmail 550 5.7.26 Unauthenticated Email: Cause and Fix

What 550 5.7.26 is telling you

Say a 12-person accounting firm sends quotes and invoices from its own domain. On a Tuesday the office manager starts getting every message back from customers on Gmail, and somewhere in the returned text sits 550-5.7.26. Nothing about the way they send changed that week. What changed was a DNS edit two weeks earlier, or an invoicing tool someone switched on without mentioning it.

That code means Gmail could not tie the message to the domain in the visible From address. It is an authentication verdict, not an opinion about your content or your sending history. Gmail did not weigh the message and decide against it; it declined to evaluate the message at all.

Two wordings follow the code, and they point at different fixes:

"Unauthenticated email from yourdomain.com is not accepted due to domain's DMARC policy." Your domain publishes a DMARC policy asking receivers to reject unauthenticated mail, the message failed DMARC, and Gmail did what you asked it to do. The policy is not the bug. Something in your sending stopped qualifying for it.
"This mail has been blocked because the sender is unauthenticated." Nothing passed. Google's sender guidelines require every sender to set up SPF or DKIM, and this is the result when neither one does its job.

Both are permanent rejections. The message is gone, not queued for a retry, and the recipient never saw it. That matters for quotes and invoices, because the sender usually reads the silence as a slow customer rather than as a bounce.

How this differs from 550 5.7.1

These two get confused constantly, and the confusion costs weeks. 550 5.7.1 with a low reputation message is a reputation judgement: Gmail knows who you are, has watched your sending, and does not like the pattern. The remedy there is slow and behavioural, measured in weeks of clean volume.

5.7.26 is binary. Either the message authenticates or it does not. There is no warmup, no list hygiene, no gradual recovery. Publish the right records, get one test message to pass, and the next send goes through.

The quick test we use: if the bounces stop the moment a DNS record is correct, it was authentication. If they persist after authentication provably passes, it is reputation. Running a warmup plan against a 5.7.26 bounce treats the wrong illness.

The alignment rule Gmail enforces

This is where most 5.7.26 cases actually live, and it is the part that surprises people who already have an SPF record.

DMARC does not ask whether SPF passed. It asks whether the thing that passed belongs to the domain your recipient can see. There are two checks, and only one of them has to succeed:

SPF alignment. The domain in the envelope sender, the return path, has to match the domain in the From header.
DKIM alignment. The domain in the signature's d= tag has to match the domain in the From header.

RFC 7489 defines two modes for each, set with the aspf and adkim tags in your DMARC record. Relaxed, which is the default when you leave the tags out, accepts a match at the organizational domain level, so mail.example.com aligns with example.com. Strict requires an exact match. Google's own DMARC troubleshooting guidance says the same thing in plainer terms: to pass DMARC, outgoing messages must pass either SPF or DKIM, and a strict alignment setting increases the chance that messages are rejected or sent to spam.

The common failure looks like this. A billing platform sends on your behalf. The From header reads billing@example.com. SPF passes, because the platform authorizes its own sending domain in its own record. DKIM passes, because the platform signs with d=billingvendor.net. Both checks are green, and DMARC still fails, because neither green check belongs to example.com. Publish an enforcing policy over that and every invoice to a Gmail address stops.

Diagnose it in ten minutes

What we check first on a client project, in this order:

Read the full bounce, not the summary line. Note the exact domain Gmail names. It is frequently not the domain the client believes they send from, and that one detail often ends the investigation.
Inventory everything that sends as you. Workspace or Microsoft 365 mailboxes, the CRM, the invoicing or electronic billing provider, the store platform, the newsletter tool, the helpdesk, the scanner in the hallway. Each one is a separate authentication problem.
Send a test message to a Gmail address you control from each sending system, open it, choose Show original, and read the Authentication-Results header.

That header is the whole answer. You are not looking for the words pass and fail on their own. You are looking at which domain passed. A spf=pass next to an envelope domain that belongs to a vendor, or a dkim=pass whose d= is not yours, is a failure dressed as a success.

Then look up your own DMARC record and note the policy. A domain sitting at p=none will not produce the DMARC wording of this bounce, which tells you immediately that you are in the second case: no passing authentication at all.

Fixing it for Google Workspace

Three things, and the second one is usually what is missing.

First, one SPF record, and only one. A domain with two TXT records starting v=spf1 fails SPF outright. For a domain that sends only through Workspace:

example.com.  TXT  "v=spf1 include:_spf.google.com ~all"

Second, DKIM, which is not on by default. Each domain has to be generated and published from the Admin console under the Gmail authentication settings. Google's default selector prefix is google, so the record lands at google._domainkey, and you should pick the 2048-bit key when your DNS host supports it:

google._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkq..."

Publish the record first, then click Start authentication in the console. Google says activation can take up to 48 hours, though it is often live within the hour. Do not skip that button: a published key whose authentication was never started signs nothing.

Third, the DMARC record itself, at _dmarc:

_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

If you are recovering from a 5.7.26 storm caused by your own enforcement, dropping to p=none stops the bleeding as soon as DNS propagates, and it is the honest move while you repair alignment. Treat it as a pause, not a destination. Our rollout guide covers the ladder back up.

Fixing it for Microsoft 365

Same idea, different plumbing. Microsoft 365 handles DKIM for the tenant's own onmicrosoft.com domain automatically, so until you enable it for your custom domain, mail from that domain is signed with a d= that is not the domain in your From header. Both checks can look healthy while DMARC fails on alignment.

The fix is enabling DKIM for the custom domain, which means two CNAME records rather than a TXT:

selector1._domainkey.example.com.  CNAME  selector1-example-com._domainkey.tenant.onmicrosoft.com.
selector2._domainkey.example.com.  CNAME  selector2-example-com._domainkey.tenant.onmicrosoft.com.

Two selectors exist so Microsoft can rotate keys without an outage. Do not guess the values. Read them from the portal, or from Exchange Online PowerShell with Get-DkimSigningConfig, which returns the exact Selector1CNAME and Selector2CNAME for your tenant, then enable signing for the domain. Our Microsoft 365 checklist has the full sequence.

Fixing it for the tools that send as you

The CRM, the invoicing provider, the store, the newsletter. Every one of these puts your domain in the From header and its own infrastructure underneath, which is exactly the alignment trap above.

Adding the vendor to your SPF record is not enough, and it is not really the point. What you need is the vendor's domain authentication feature, whatever they call it: a sending domain, a dedicated sending domain, a branded sender setup. It publishes a DKIM key under your domain so their signature carries d=example.com, and it usually moves the return path under your domain as well. That is what turns their pass into your pass.

Two warnings from the field. SPF is capped at ten DNS lookups by RFC 7208, and stacking vendor includes exhausts that budget faster than people expect, which produces a PermError and a different family of bounces; see the lookup limit guide if your record is already long. And the marketing platforms each have their own quirks, with a different name for the same setting on every one.

Where the bulk sender thresholds come in

Google's sender guidelines, in force since February 2024, set two tiers. Every sender, at any volume, needs SPF or DKIM set up, valid forward and reverse DNS for the sending host, and a TLS connection. Senders of more than 5,000 messages a day to Gmail accounts carry more: SPF and DKIM both, a DMARC record on the sending domain which may sit at p=none, From-header alignment with either the SPF domain or the DKIM domain for direct mail, messages formatted to RFC 5322, and spam rates reported in Postmaster Tools kept below 0.30 percent.

The trap for small businesses is assuming the 5,000 line protects them. It does not. The first tier applies to a five-person company sending forty messages a day, and it is the tier that produces the second 5.7.26 wording. If your volume is anywhere near the threshold, aim at the bulk requirements anyway: the gap between the two tiers is a week of work, not a project.

How Guanacos Tech helps

Most 5.7.26 cases we take on are not one broken record. They are four systems sending as one domain, two of them authenticated properly, one added last year and forgotten, and a DMARC policy published by someone who read a good article and skipped the reporting phase. We inventory the senders, fix alignment one system at a time, verify each with a real message instead of a lookup tool, and stay on the DMARC reports until the domain enforces safely. If you have a bounce in hand and want it read properly, book a call, or start with the free troubleshooter.

Gmail 550 5.7.26 "unauthenticated email": the exact cause and the fix