Gmail's 550-5.7.26 error means your email failed DMARC authentication. The fix: ensure your SPF record includes the sending service, DKIM is configured and signing with your domain, and either SPF or DKIM aligns with your From: header domain. Check with MXToolbox → DMARC lookup on your domain. Most common cause: a sending service (ESP, CRM, form tool) isn't included in your SPF record or doesn't have DKIM configured.
Gmail 550-5.7.26 DMARC Authentication Failed: How to Fix It
The Error
550-5.7.26 This mail has been blocked because the sender is unauthenticated.
Gmail requires all senders to authenticate with either SPF or DKIM.
This is Gmail telling you: your email failed DMARC. It's a permanent rejection — Gmail won't retry.
Diagnosis (5 Minutes)
Step 1: Check Your Authentication Records
Go to MXToolbox and check:
SPF: Enter your domain → SPF Lookup
- Does the record exist?
- Does it include your sending service?
- Is it under the 10 DNS lookup limit?
DKIM: Check that your ESP's DKIM record is published in DNS.
DMARC: Enter your domain → DMARC Lookup
- Does a DMARC record exist?
- What's the policy? (p=none/quarantine/reject)
Step 2: Identify the Failing Sender
The bounce message should include the sending IP. Cross-reference:
- Is this your ESP? → Check SPF includes the ESP
- Is this a third-party service? → Add it to SPF and configure DKIM
- Is this an unknown IP? → This might be spoofing (DMARC is doing its job)
Step 3: Check Alignment
DMARC requires that either:
- SPF alignment: The envelope sender domain (Return-Path) matches the From: domain
- DKIM alignment: The DKIM d= domain matches the From: domain
At least one must align. If your ESP sends with a different Return-Path domain but signs with your DKIM domain, DKIM alignment saves you. If neither aligns, DMARC fails.
Common Causes and Fixes
Cause 1: ESP Not in SPF Record
Symptom: You added a new ESP but didn't update your SPF record. Fix: Add the ESP's include to your SPF record:
v=spf1 include:_spf.google.com include:sendgrid.net -all
Cause 2: DKIM Not Configured
Symptom: You set up an ESP but skipped the DKIM DNS records. Fix: Go to your ESP's settings, find DKIM configuration, add the DNS records they provide.
Cause 3: Third-Party Service Sending As Your Domain
Symptom: A CRM, helpdesk, billing system, or form tool sends email "from" your domain without authentication. Fix: Either add the service to SPF/DKIM, or change the service to send from its own domain.
Cause 4: DMARC at p=reject Too Early
Symptom: You advanced DMARC to reject before authorizing all senders. Fix: Temporarily move back to p=quarantine or p=none, review DMARC reports, authorize all legitimate senders, then re-advance.
Practitioner note: 9 out of 10 times I see this error, it's a forgotten third-party service. The sales team installed a booking tool, the finance team uses an invoicing platform, someone set up a Typeform — all sending as the company domain without authentication. Check every service in your organization that sends email.
Practitioner note: If you recently changed ESP, the old DKIM records are still in DNS but no longer valid. The new ESP needs its own DKIM records added. Don't delete the old ones until you've verified the new ones work.
If you can't identify the failing sender or the fix isn't working, schedule a consultation — I'll trace the exact authentication failure and fix it.
Sources
- Google: 550-5.7.26 Error
- RFC 7489: DMARC
v1.0 · March 2026
Frequently Asked Questions
What does 550-5.7.26 mean?
It means Gmail rejected your message because DMARC authentication failed. Neither SPF nor DKIM aligned with your From: domain. This is a permanent rejection — the message will not be retried.
How do I fix this quickly?
Step 1: Check your SPF record includes the sending service. Step 2: Verify DKIM is configured and signing. Step 3: Ensure alignment — the domain in SPF or DKIM must match your From: header domain. Step 4: Wait 1-4 hours for DNS propagation. Step 5: Send a test email.
Why did this just start happening?
Common triggers: you recently changed DNS records, added a new sending service without updating SPF, your ESP changed their DKIM configuration, or you set up DMARC with p=quarantine/reject and a sender you forgot about is now being rejected.
I'm using Google Workspace — why am I getting this?
If you send through Google Workspace but your DMARC record has p=reject and a third-party service (CRM, form tool, helpdesk) sends as your domain without proper authentication, those third-party emails get rejected. The fix: authorize the third-party service in your SPF and configure DKIM.
Does this affect all my email or just some?
Only email that fails DMARC authentication. If you send from multiple services, some may pass (properly authenticated) while others fail (not properly configured). Check DMARC aggregate reports to identify which senders are failing.
Want this handled for you?
Free 30-minute strategy call. Walk away with a plan either way.