What does 550 5.7.26 mean?
Gmail returns this error when a message fails DMARC authentication. You'll typically see one of these diagnostic strings in the bounce:
550-5.7.26 Unauthenticated email from [your-domain.com] is not accepted due to domain's DMARC policy.
550-5.7.26 Your email has been blocked because the sender is unauthenticated. Gmail requires all senders to authenticate with either SPF or DKIM.
In plain terms: Gmail checked whether SPF or DKIM passed and aligned with the domain in your From: header. Neither did. Gmail applied your domain's published DMARC policy and blocked the message.
Since February 2024, Gmail requires all senders to authenticate with SPF or DKIM. Bulk senders (5,000+ messages/day) must also publish a DMARC record with alignment. This error became much more common after Gmail's 2024 sender enforcement changes.
DMARCit shows you exactly which service caused the rejection and whether SPF, DKIM, or alignment failed — without reading XML.
Why did this happen?
One root cause — failed DMARC alignment — but several common triggers, starting with the most frequent:
Trigger 1: A third-party service is sending as your domain without alignment
Most SaaS platforms (Mailchimp, HubSpot, Salesforce, Zendesk, etc.) use their own domain in the email envelope (Return-Path), not yours. SPF passes for their domain, but DMARC checks alignment against your From: domain — and fails.
This is the most common trigger. The message may pass SPF and DKIM individually, but neither result aligns with your domain, so DMARC fails.
You'll see this in headers as:
spf=pass; dkim=pass; dmarc=fail
That pass-pass-fail pattern is the telltale sign of an alignment problem.
Trigger 2: SPF is broken (too many DNS lookups)
Your SPF record exceeds the 10 DNS lookup limit defined in RFC 7208, causing a PermError. Gmail treats PermError as an SPF failure. If DKIM also isn't aligned, DMARC fails.
This happens faster than most admins expect. Each include: in your SPF record can consume multiple lookups recursively. A typical stack of Google Workspace + a marketing platform + a transactional sender can push past 10. → See: SPF PermError — Too many DNS lookups.
Trigger 3: DKIM isn't configured for your sending domain
Your email platform is signing with DKIM, but using the platform's default domain instead of yours. DKIM passes for the platform but doesn't align with your From: domain.
Or: DKIM was configured once but the key was rotated, DNS wasn't updated, and signatures now fail verification entirely. → See: DKIM body hash did not verify.
Trigger 4: Email forwarding broke both SPF and DKIM
A recipient's server-side forwarding rule relayed the message. The forwarding server's IP isn't in your SPF record (SPF fails). If the forwarder also modified the message — added a footer, tagged the subject — DKIM breaks too. Both fail, DMARC fails, Gmail rejects.
Trigger 5: You moved to DMARC enforcement before all senders were onboarded
You set p=reject or p=quarantine before every legitimate sending source had aligned authentication. Messages from un-onboarded services now get rejected instead of just reported.
How to fix 550 5.7.26
Step 1: Identify the sending source
Check the bounce notification for clues about which system sent the message. If you have access to full message headers, look at three fields:
| Header field | What it tells you |
|---|---|
Return-Path: | Which domain is in the envelope sender (this is what SPF checks) |
DKIM-Signature: d= | Which domain signed the message (this is what DKIM alignment checks) |
Authentication-Results: | What passed, what failed, and whether alignment succeeded |
If you're receiving DMARC aggregate reports, the sending IP and per-message authentication results are in the XML data.
Step 2: Fix alignment for that sender
The fix depends on the platform:
- If the platform supports custom DKIM signing (most do): Configure DKIM to sign with your domain. This is typically 1–2 CNAME or TXT records in DNS. DKIM alignment is the most reliable fix because it survives forwarding.
- If the platform supports a custom Return-Path (fewer do): Configure it to use a subdomain of your domain (e.g.,
bounce.yourdomain.com). This gives you SPF alignment under relaxed mode. - If the platform supports neither: Route that mail through your primary email gateway (e.g., Microsoft 365 or Google Workspace) so it inherits your existing authentication.
Step 3: Verify SPF is under the 10-lookup limit
Run an SPF check on your domain. If it exceeds 10 DNS lookups, you'll get PermError on every message — regardless of which sender triggered this bounce. Fix by removing unused includes, moving vendors to subdomains, or using hosted SPF.
Step 4: Confirm the fix
After making changes, wait 24–48 hours for the next cycle of DMARC aggregate reports. Verify that the sending source now shows SPF or DKIM alignment passing. If you don't have a way to read your DMARC reports, this is where monitoring tooling pays for itself.
This isn't a one-time fix
Email authentication tends to break again because:
- New services get added constantly. Marketing signs up for a new email tool. HR adopts a recruiting platform. A developer enables transactional email from a SaaS app. Each one sends as your domain — often without IT knowing and without authentication.
- SPF records drift. Vendors rotate sending IPs without notice. If you've flattened your SPF record to stay under the lookup limit, every IP rotation is a potential silent failure. If you haven't flattened, every new vendor include pushes you closer to PermError.
- Forwarding is structural. You can't control how recipients forward your mail. Server-side forwarding will break SPF — and sometimes DKIM — for as long as email forwarding exists.
- DKIM keys expire and rotate. Microsoft 365 key rotation can take up to 96 hours. Google Workspace may create an authentication gap while DNS propagates. Miss the update window and you're sending unsigned mail.
The only way to catch these failures before your clients notice is continuous monitoring.
See which sender failed — before your clients tell you
DMARCit processes your DMARC aggregate reports and shows you every service sending as your domain. You'll see exactly who's passing, who's failing, and why — in a dashboard, not XML.
When authentication breaks, you can catch it before it turns into client-facing delivery issues.
7-day free trial · Cancel anytime