The 550 5.7.1 DMARC policy violation error means the recipient’s server rejected your email because it failed DMARC authentication — also known as “unauthenticated mail is prohibited” or “DMARC evaluation failed.”
Fix it by verifying your SPF, DKIM, and DMARC DNS records, ensuring all sending sources are authorized, and confirming domain alignment between your email headers and authentication mechanisms.
DMARC failures don’t just bounce individual emails — they signal to receiving servers that your domain lacks proper authentication controls.
Repeated failures erode sender reputation and push legitimate mail toward spam folders (or outright rejection). The fix requires DNS changes, but the diagnosis determines which records need attention.
Quick skim — 550 5.7.1 error overview
DMARC policy violations occur when authentication checks fail, and the domain’s DMARC policy instructs rejection.
| Attribute | Details |
| Error code | 550 5.7.1 (DMARC variant) |
| Category | Authentication/policy failure |
| Meaning | Email failed DMARC evaluation; policy requires rejection |
| Severity | Permanent (requires DNS and sending configuration changes) |
| Common causes | Missing SPF/DKIM, alignment failures, unauthorized senders |
| Fix approach | Verify SPF → verify DKIM → check alignment → adjust policy |
What does a DMARC policy violation mean?
DMARC (Domain-based Message Authentication, Reporting, and Conformance) ties SPF and DKIM together with a policy layer. When an email arrives, the receiving server checks:
- Does DKIM pass? (Is the signature valid?)
- Does SPF pass? (Is the sending IP authorized?)
- Does either align with the From header domain?
If both SPF and DKIM fail (or neither aligns), DMARC fails. Your published DMARC policy then tells the receiver what to do — p=none (monitor only), p=quarantine (spam folder), or p=reject (bounce).
DMARC alignment explained
Alignment means the authenticated domain matches the visible “From” domain:
| Check | Authenticated Domain | Must Match |
| SPF alignment | MAIL FROM (Return-Path) | From the header domain |
| DKIM alignment | d= domain in signature | From the header domain |
Relaxed alignment allows subdomains to match (mail.example.com aligns with example.com). Strict alignment requires exact matches.
Provider variations
Here’s how these are different for each provider:
| Provider | Error Text |
| Gmail | 550 5.7.1 Unauthenticated email from domain.com is not accepted due to domain’s DMARC policy |
| Microsoft 365 | 550 5.7.1 Message rejected per DMARC policy |
| Yahoo | 554 5.7.9 Message not accepted for policy reasons |
Why does the 550 5.7.1 error occur?
DMARC failures stem from authentication gaps or alignment mismatches. Understanding the root cause directs your fix.
SPF not configured
Your domain lacks an SPF record, or the record doesn’t include all legitimate sending IPs. Common gaps:
- New email service added without SPF update
- SPF exceeds 10 DNS lookups (causes permerror)
- Third-party tools (CRM, marketing platforms) not authorized
DKIM not signing
Emails leave your server without DKIM signatures, or signatures fail validation:
- Public key not published in DNS
- Key mismatch between signing server and DNS record
- Intermediary modified message body (breaks signature)
- DKIM signing disabled on mail server
Alignment failure
SPF and DKIM may pass individually but fail to align with the From header:
- SPF authenticates bounce.esp.com but From shows yourdomain.com
- DKIM signs with d=esp.com but From shows yourdomain.com
- Third-party sends on your behalf without proper delegation
Strict DMARC policy
A p=reject policy blocks any mail failing DMARC. Organizations sometimes implement strict policies before authorizing all legitimate senders, causing their own mail to bounce.
Blacklisted IP
Even with valid authentication, some providers layer reputation checks. A blacklisted sending IP can trigger 5.7.1 alongside (or instead of) DMARC-specific codes.
How do you fix DMARC policy violations?
Systematic verification across SPF, DKIM, and DMARC identifies the failure point.
Verify SPF records
Check your SPF record includes all authorized senders:
dig TXT yourdomain.com | grep spf
Confirm the record:
- Exists as a single TXT record (multiple SPF records cause failures)
- Includes your mail server IPs
- Includes third-party services (add include:_spf.google.com for Google Workspace, include:sendgrid.net for SendGrid, etc.)
- Stays under 10 DNS lookups
Use the SPF lookup tool to validate syntax and lookup, count.
Enable DKIM signing
Verify DKIM is active on your sending infrastructure:
- Check your email service’s DKIM settings (most ESPs have a toggle)
- Copy the public key TXT record from your provider
- Publish the record in DNS at the specified selector (e.g., selector._domainkey.yourdomain.com)
- Wait for DNS propagation (up to 48 hours, usually faster)
Test with the DKIM lookup tool.
Check DMARC alignment
Send a test email to yourself (or a verification service) and examine the Authentication-Results header:
Authentication-Results: mx.google.com;
spf=pass (sender IP is authorized) smtp.mailfrom=yourdomain.com;
dkim=pass header.d=yourdomain.com;
dmarc=pass (p=REJECT)
If SPF or DKIM passes but DMARC fails, alignment is the problem. Verify:
- SPF domain (MAIL FROM) matches your From header domain
- DKIM d= domain matches your From header domain
For third-party senders, configure custom MAIL FROM domains and DKIM signing with your domain (most ESPs support this).
Adjust DMARC policy
If you’re troubleshooting, temporarily relax your policy:
v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.comThe p=none setting allows delivery while you receive aggregate reports identifying failures. Once all legitimate sources authenticate properly, move to p=quarantine then p=reject.
Use the DMARC generator to create properly formatted records.
Analyze DMARC reports
DMARC aggregate reports reveal which sources fail authentication:
- Enable reporting with rua=mailto: in your DMARC record
- Use a DMARC report analyzer (Google Admin Toolbox, third-party services)
- Identify unauthorized senders or misconfigured legitimate senders
- Update SPF/DKIM to authorize legitimate sources
Check IP reputation
Authentication alone doesn’t guarantee delivery. Verify your sending IP isn’t blacklisted:
- Run an email deliverability test
- Check major blacklists (Spamhaus, Barracuda, SORBS)
- Request delisting if necessary
How do you prevent DMARC failures?
Ongoing monitoring catches problems before they cascade.
Inventory sending sources
Document every system sending email as your domain:
- CRM systems
- Primary mail server
- Marketing platforms
- Internal applications
- Support ticketing tools
- Transactional email services
When adding new services, update SPF and configure DKIM immediately.
Monitor DMARC reports
Weekly review of aggregate reports identifies:
- New unauthorized senders (spoofing attempts)
- Legitimate senders with broken authentication
- Alignment drift after infrastructure changes
Test before major sends
Before launching campaigns or adding new sending infrastructure:
- Send test messages to verification services
- Examine Authentication-Results headers
- Confirm DMARC=pass before scaling volume
Still stuck after trying the fix?
Some email errors are easy to clear. Others point to deeper deliverability issues involving authentication, sender reputation, blacklisting, routing, or mailbox provider policy. If you would rather have an expert review it, speak with an email delieverability consultant for free and we can help diagnose the issue and fix it on your behalf.
We look beyond the error message itself to find what is actually breaking delivery, trust, or inbox placement.
From SPF, DKIM, and DMARC to blacklist cleanup, DNS alignment, and sending setup, we can guide or implement the fix.
We assess whether the error is part of a bigger pattern hurting opens, replies, and overall campaign performance.
Talk to a real deliverability expert, get honest guidance, and see the next best step without pressure or upsells.
When should you book a consultation? If the error keeps coming back, affects multiple mailboxes or domains, started after an ESP or DNS change, or is tied to spam placement, low inboxing, high bounce rates, or authentication failures, it is usually faster to get an expert involved early.
Frequently asked questions
Here are some commonly asked questions on this topic:
SPF authorizes which IPs can send for your domain. DKIM verifies that a message wasn’t modified in transit using cryptographic signatures. DMARC ties them together with alignment requirements and a policy for handling failures. All three work together — DMARC fails if neither SPF nor DKIM passes with proper alignment.
No. Start with p=none to collect reports without affecting delivery. Analyze reports to identify all legitimate senders, authorize them properly, then move to p=quarantine (spam folder failures) before p=reject (bounce failures). Premature rejection blocks legitimate mail.
SPF passing doesn’t guarantee DMARC passing. DMARC requires alignment — the SPF-authenticated domain (MAIL FROM) must match the visible From header domain. Third-party senders often use their own MAIL FROM domain, causing SPF to pass but DMARC alignment to fail.
Temporarily, yes — recipient administrators can whitelist your domain. Permanently, no — you must fix your authentication. Whitelisting bypasses security controls and isn’t a sustainable solution.
