Gmail “550 5.7.26 This mail has been blocked”: the 30-minute fix

Your bounce queue just filled up with 550 5.7.26 errors and every Gmail user who was supposed to get your message didn’t. This isn’t a temporary deferral. Google rejected the messages outright, and resending won’t help until the underlying authentication problem is fixed.

Here’s what happened and how to fix it in the next 30 minutes.

What the error means

550 5.7.26 means Google’s servers refused your email because your sending domain failed Google’s bulk sender requirements.

Google introduced these requirements in February 2024 for senders delivering 5,000+ messages a day to personal Gmail addresses (gmail.com, googlemail.com). Google’s own sender guidelines FAQ confirms the ramp-up: enforcement tightened through 2025, and a domain that used to get a soft warning can now get a hard 5.7.26 reject. Google’s error code reference states plainly that messages “aren’t authenticated with these methods might be marked as spam or rejected with a 5.7.26 error.” If you’re seeing it now, you’re past the warning stage: messages are being dropped, not delayed.

The requirements, per Google’s own page:

  1. SPF must pass: your sending IP must be authorized by your domain’s SPF record
  2. DKIM must pass: the message must carry a valid DKIM signature
  3. A DMARC record must exist (at minimum p=none; the record just needs to be there). RFC 9989 §4.7 treats a record with no p tag as p=none, but publish it explicitly so nobody has to guess your intent.
  4. DMARC alignment must pass: either SPF or DKIM must align to the domain in the From: header. RFC 9989 §3.2.10 defines relaxed alignment as the Author Domain sharing an organizational domain with the authenticated identifier.
  5. One-click unsubscribe: required for promotional/marketing mail
  6. Spam complaint rate below 0.3% (Google recommends staying under 0.1%; monitor it in Google Postmaster Tools)

The most common cause of 550 5.7.26 is a missing DMARC record, DKIM not configured, or an alignment failure. Let’s check yours.

The 30-minute triage checklist

1. Check your DMARC record (2 minutes)

dig TXT _dmarc.example.com +short

Expected output, something like:

"v=DMARC1; p=none; rua=mailto:reports@example.com"

Nothing back means your DMARC record is missing entirely. That alone triggers 550 5.7.26. Add one before doing anything else.

2. Check your SPF record (3 minutes)

dig TXT example.com +short | grep "v=spf1"

You should see a record that includes your sending service, something like include:sendgrid.net or include:amazonses.com. If the record is missing or doesn’t include your email provider, SPF is failing.

If you use several sending services, confirm the record has fewer than 10 DNS lookup mechanisms. RFC 7208 §4.6.4 requires implementations to cap include/a/mx/ptr/exists/redirect lookups at 10 and return permerror above that. If you’re near the edge, this post explains what happens when you add one tool too many.

3. Find your DKIM selector and verify the key (5 minutes)

DKIM requires knowing your selector. Fastest way to find it: send a test email to a Gmail address you control, open the message, and choose “Show original” from the three-dot menu. Look for the DKIM-Signature: header. The s= field is your selector.

Then verify the key exists in DNS:

dig TXT <selector>._domainkey.example.com +short

"v=DKIM1; k=rsa; p=..." back means the key is published. Nothing back means DKIM isn’t configured at DNS level: either the key was never published, or you’re using a sending service’s shared domain instead of your own.

4. Check alignment (5 minutes)

Alignment means the domain in your DKIM d= tag (RFC 6376 §3.5 defines it as the SDID claiming responsibility for the message) or the domain in your SPF Return-Path matches your From: domain.

For DKIM alignment: the d= value in your DKIM-Signature header must match your From: domain (or a parent domain for relaxed alignment).

For SPF alignment: the Return-Path domain must match your From: domain.

You only need one of the two to align. Most transactional email providers configure DKIM alignment by default when you set up a custom sending domain. Marketing platforms sometimes don’t, especially on their shared sending domain rather than your own.

5. Check unsubscribe headers (marketing mail only)

Bulk promotional mail needs a List-Unsubscribe-Post: List-Unsubscribe=One-Click header. Check your email platform’s docs. Every major ESP supports one-click unsubscribe, but it sometimes needs enabling explicitly.

Not sure what state your domain is in right now? A free domain checker shows your DMARC record, SPF setup, and whether your domain can achieve alignment. No account needed.

Fixes by cause

Missing DMARC record:

Add a TXT record at _dmarc.example.com:

v=DMARC1; p=none; rua=mailto:your-rua-address@example.com

Start with p=none. It satisfies Google’s minimum requirement and starts collecting reports. Once SPF and DKIM are clean and you’ve read a few weeks of reports, move toward enforcement. The full process is in moving from DMARC p=none to p=reject without killing legitimate email.

SPF failing:

Add your email provider’s SPF include to your domain’s TXT record at the root:

# Postmark
include:spf.mtasv.net

# SendGrid
include:sendgrid.net

# Amazon SES
include:amazonses.com

# Google Workspace
include:_spf.google.com

# Resend
include:_spf.resend.com

DKIM not configured:

Log into your email provider and follow its DKIM setup guide. Every major provider (Postmark, SendGrid, Amazon SES, Mailchimp, Resend, Google Workspace) generates a CNAME or TXT record for you to publish in DNS. Setup takes 5 to 10 minutes; propagation another few minutes to an hour.

Alignment failing:

If you’re on a transactional provider’s default shared sending domain, switch to custom domain sending. Sending From: you@example.com while the DKIM signature says d=sendgrid.net fails alignment. Most providers let you configure your own domain for signing, usually documented as “custom domain authentication” or “domain authentication.”

How to verify it worked

After making DNS changes:

  1. Send a test email to a personal Gmail address and open “Show original.” Look for Authentication-Results: in the headers. You want dkim=pass, spf=pass, and dmarc=pass.
  2. Check Google Postmaster Tools for your domain. It shows DKIM and SPF pass rates at volume.
  3. Wait 24 to 48 hours for DMARC aggregate reports. They show per-sender authentication results for every message in your sending window. A clean report, with all legitimate senders passing, means the fix held.

One thing to watch going forward

Google’s own FAQ states that “it’s likely that DMARC alignment with both SPF and DKIM will eventually be a sender requirement.” If you’re currently passing on only one of the two, configure the other before it’s mandatory. DKIM is the safer bet: it survives email forwarding, while SPF breaks whenever a message passes through a forwarding server, because the forwarded copy arrives from an unauthorized IP.

If Microsoft mail is bouncing too, the Microsoft 550 5.7.515 fix walks through the same checks against their requirements.

The next authentication failure won’t warn you. It’ll bounce your customer’s password reset. DMARC Guardian reads your aggregate reports as they arrive and flags which sender broke alignment, so you catch it before your users do.

Check your domain’s DMARC, SPF, and alignment status free →