550-5.7.26 This email has been blocked because the sender is unauthenticated

Gmail returned 550-5.7.26 because your message failed both SPF and DKIM for the domain it came from, and Gmail rejects that combination at the door rather than filing it in spam. The fix is a DNS edit. Get either SPF or DKIM passing for the sending domain and the block clears as soon as the new record is visible to Gmail’s resolvers, which is usually minutes to a few hours and at worst 48 hours. You don’t need a support ticket, a new IP or an enforcing DMARC policy.

The steps below run in order of time-to-effect, with the propagation window stated on each one, so you know what clears while you’re still at your desk and what you’ll be checking tomorrow morning.

Which 550-5.7.26 you have

The current full text of the bounce reads: “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] with ip: [ip] = did not pass.” That last sentence is the diagnosis. It names the domain Gmail checked and the IP the mail came from, and it tells you both legs failed.

Google keeps three wordings under the 5.7.26 code, and each points at a different fault. There’s also a rate-limited sibling, “421 4.7.26 This email has been rate limited because it is unauthenticated”, with the same cause and a temporary code. The bulk-sender SPF-only and DKIM-only failures moved to their own codes, 5.7.27 and 5.7.30, so match your string against the table before you touch DNS.

The bulk tier is 5,000 or more messages a day to Gmail, and the bulk-only codes (5.7.27, 5.7.29, 5.7.30) come from that tier. The authentication basics, SPF or DKIM passing and a valid PTR, apply to senders at any volume, which is why a small company sending a newsletter hits 550-5.7.26 as readily as a large platform does.

Step 1: read the string and find out which leg failed (seconds)

The “Authentication results” line in the bounce tells you what Gmail saw. If both legs read “did not pass”, you have the basic variant and either fix works. If the text mentions a hard fail policy, your SPF record exists and is strict, and the sending IP isn’t in it. If it mentions your DMARC policy, your own record is doing the rejecting.

Before you edit anything, run the free scan on the sending domain. It reads the live SPF, DKIM and DMARC records and shows which leg is missing, which is malformed, and which is present and passing, so you fix the right record first and have a baseline to compare against once the change is visible.

Step 2: give the sending IP a PTR record (hours, provider-dependent)

The IP that connects to Gmail needs a reverse DNS record, and the hostname in that PTR has to resolve forward to the same IP. Mainstream mail providers do this for you and you can skip ahead. It bites people sending from their own server or a cloud VM, and a missing PTR is the whole story behind the sibling code 550 5.7.25.

You can’t set this in your domain’s DNS. The owner of the IP block sets it, which means your hosting or cloud provider’s control panel or a support request. Expect hours rather than minutes, and put the request in before you start the record edits below so the two windows overlap.

Step 3: get SPF or DKIM passing (minutes to 48 hours)

One guardrail first. Receivers evaluate SPF against the Return-Path domain, the RFC5321.MailFrom address the bounce went back to, and that’s often a different domain from the one in your From header. A marketing platform sending on your behalf usually sets the Return-Path to its own bounce domain, which means SPF on your domain was never going to pass for that mail and you should lean on DKIM instead. Look at where the bounce arrived before you decide SPF “should” pass.

If the Return-Path is your domain, add your real sending services to that domain’s SPF record. A working record for a Google Workspace domain looks like this:

v=spf1 include:_spf.google.com -all

Add an include: for each platform that sends as you, and keep the total under ten DNS lookups. The full walkthrough, including what to do when the record is already at the lookup limit, is on the SPF page. A large part of the internet hasn’t got this far: of the 316,600,902 domains carrying a grade in the September 2026 census, 166,497,698 (52.6%) publish no SPF record at all.

If SPF can’t pass, or as well as SPF, turn on DKIM signing at whichever platform sends the mail. Your provider gives you a selector and a public key to publish as a TXT record. Either leg passing clears the basic 550-5.7.26 block.

Lower the TTL on the record before you edit it if your DNS host lets you. Gmail honours the new record as soon as its resolvers see it, so a short TTL turns a possible 48-hour wait into minutes. There’s no queue and no review on Google’s side once the record is visible.

Step 4: make DKIM align with your From domain (the same DNS window plus a key rollout)

Passing DKIM and aligned DKIM are different things. Aligned means the domain in the d= tag of the signature matches the domain in your From address. A Google Workspace tenant that hasn’t published its own key signs with a default gappssmtp.com signature, which passes DKIM at Gmail but doesn’t align, so DMARC still fails and the DMARC-policy variant of 5.7.26 can follow. The default signature trap has its own page, with the exact records to publish.

Alignment matters beyond the bounce. Aligned DKIM survives forwarding, because the signature travels with the message, and SPF doesn’t, because the forwarding server’s IP is never in your record. If your mail passes through a mailing list, an alumni forwarder or a customer’s auto-forward, DKIM is the leg that still holds.

Timing here is the DNS window for the TXT record plus whatever your provider needs to start signing with the new key. Some providers sign the moment the key is verified; others roll the key out over a few hours. Send a test to a Gmail mailbox and open “Show original” to see dkim=pass with your domain next to it before you call this step done.

Step 5: publish a DMARC record (minutes to 48 hours)

Google’s sender requirements ask bulk senders for a published DMARC record, and the minimum is a monitoring policy with a reporting address:

_dmarc.yourdomain.com  TXT  "v=DMARC1; p=none; rua=mailto:[email protected]"

That record tells nobody to reject anything. It satisfies the requirement and starts sending you aggregate reports showing which sources pass and which fail alignment, which is how you find the platform you forgot about in step 3. Move to p=quarantine or p=reject later, once the reports show your own mail aligning, and do it by choice rather than because a bounce made you. The DMARC page walks through the record and what each tag does.

Most senders who publish a record stop there. Of the 78,444,857 domains with a DMARC record in the September 2026 census, 36,602,897 have moved to an enforcing policy. Gmail doesn’t test for enforcement when it decides on 550-5.7.26; it tests whether SPF or DKIM passed. The enforcing figure describes how far most senders go, and a p=none record is a complete answer to this bounce.

Step 6: TLS and one-click unsubscribe (immediate, sender-side)

These two need no DNS and take effect on the next message you send. Outbound TLS is on by default at any modern provider, and if you run your own mail server you confirm it in the MTA config. Bulk mail without it bounces with its own code, 550 5.7.29.

For marketing and subscribed mail, add the RFC 8058 headers, both List-Unsubscribe and List-Unsubscribe-Post, so Gmail can show its one-click unsubscribe. Marketing platforms set these for you; check the raw headers of a sent message rather than assuming.

Step 7: what only clean sending repairs (days to weeks)

Everything above clears an authentication block the moment the record is visible. Reputation is slower. Register the domain in Google Postmaster Tools and keep the spam rate under a tenth of a percent; Google’s ceiling is three tenths of a percent, and crossing it produces 550 5.7.28 and the 421-4.7.0 deferrals that no DNS edit can lift. Recovery from those takes days to weeks of sending mail people asked for, at a volume that doesn’t spike.

Authentication fixes also don’t remove an IP from a third-party blocklist. If your bounces cite a blocklist by name, that’s a separate cleanup with the list operator. Fixing SPF and DKIM stops the relapses; it doesn’t delist you.

When the record is visible and the scan shows one leg passing for the sending domain, re-send the blocked message. Gmail accepts it on the strength of that one pass, and the spam-rate work carries on in the background while you get back to the campaign.

Figures as of 5 September 2026, from the September 2026 edition of the defaults.exposed census. Census numbers move every month; the current values are on the census data page.