When you see “550 5.7.26 Unauthenticated email from [yourdomain.com] is not accepted due to the domain’s DMARC policy” (or the similar 5.7.1 variant), Google has permanently rejected your email. This is a 5XX SMTP error — meaning the message won’t be retried automatically.
The rejection happens because your email failed DMARC authentication checks. Gmail requires DMARC compliance for bulk senders (sending 5,000+ emails per day) as of February 2024. However, all senders should pass DMARC to avoid this bounce.
Why are you getting a 550 5.7.26 / 5.7.1 error?
Your email failed to prove it actually came from your domain. DMARC verification depends on two authentication protocols —SPF and DKIM — and at least one must pass and align with your visible “From” address.
Here’s what causes the rejection:
| Issue | What’s happening |
| Missing or broken SPF record | Your sending IP isn’t authorized in your DNS, so SPF fails |
| Missing or broken DKIM setup | Your email signature can’t be verified, so DKIM fails |
| Domain alignment failure | Your Return-Path domain (SPF) or DKIM signing domain doesn’t match your “From” address. With relaxed alignment (default), the organizational domain must match; strict requires an exact match |
| No DMARC record configured | Bulk senders must publish DMARC or Gmail rejects mail. For non-bulk senders, missing DMARC is strongly recommended, but won’t produce this specific bounce |
| DMARC policy set to reject | Your domain’s policy (p=reject) tells receivers to block unauthenticated mail |
How to fix the 550 5.7.1 error
Follow these steps to restore email delivery.
Check your authentication records
Run a free email deliverability test to see which records are missing or misconfigured. The test shows you the exact DNS setup issues causing authentication failures.
Fix your SPF record
Add your email provider’s sending servers to your SPF record. Log in to your DNS settings (where you manage your domain) and verify your SPF TXT record includes all authorized IPs. If you’re using multiple sending services (like Mailchimp, SendGrid, or your email host), they all need to be listed.
Set up DKIM properly
Your email service provider gives you DKIM keys to add to your DNS. Copy the DNS records they provide (TXT records for Google Workspace, CNAME records for Amazon SES, etc.) and paste them into your domain’s DNS settings. Wait 24-48 hours for propagation, then send a test email to confirm the signature validates.
Configure DMARC alignment
Create a DMARC record that matches your authentication setup. Start with p=none to monitor results without blocking mail, then gradually move to p=quarantine or p=reject once you’ve confirmed SPF and DKIM pass consistently. Your DMARC domain must align with your “From” address domain (or its parent domain).
Test again before sending campaigns
After fixing your DNS records, use the email spam checker extension to verify that your emails authenticate correctly. The extension shows your authentication status and inbox placement before you send to your full list.
If your sender reputation took a hit from bounced emails, run email warmup to gradually rebuild trust with mailbox providers (after you’ve fixed authentication issues).
Still stuck with authentication errors?
DNS configuration can get technical fast (especially when you’re managing multiple sending sources or dealing with subdomain alignment issues).
If this guide didn’t resolve your 550 5.7.1 rejection, we’ll help you fix it for free.
Schedule a free consultation with an email deliverability consultant — they’ll audit your authentication setup, identify what’s breaking, and handle the technical fixes for you.
Frequently asked questions
Here are some frequently asked questions about the 550 5.7.26 / 5.7.1 error:
This specific message wording is from Gmail. Other providers use different error codes and text for DMARC failures (many also use 5.7.1 for various policy rejections). Gmail commonly returns 5.7.26 for DMARC issues.
No. You must add or update DNS records at your domain registrar. Contact your IT team or hosting provider if you don’t have DNS access.
DNS changes are often visible within minutes to a few hours, but can take up to 24-48 hours depending on TTL settings and DNS caching.
Only if the new address uses a domain with proper authentication, switching domains without fixing DNS just moves the problem elsewhere.
If you’re still seeing the same DMARC bounce, re-check your domain alignment and DMARC record syntax. If everything looks correct, your domain or IP might be blacklisted, or your reputation could be damaged.
