554 5.7.5 Permanent Error Evaluating DMARC Policy: How to Fix It

Email Authentication

The error "554 5.7.5 Permanent error evaluating DMARC policy" means your email was rejected because it failed DMARC authentication. The receiving mail server checked your domain's DMARC policy and determined the message didn't meet the requirements.

This isn't a temporary issue — the "permanent error" classification means the server won't retry delivery. You need to fix the underlying authentication problem.

What This Error Means

When a mail server returns 554 5.7.5, it's telling you:

• 554: Permanent failure (transaction failed)
• 5.7.5: Authentication/policy issue (specifically DMARC)
• "Permanent error evaluating DMARC policy": Your email failed DMARC checks

The message was rejected outright — it didn't go to spam, it bounced.

Why DMARC Rejects Emails

DMARC (Domain-based Message Authentication, Reporting & Conformance) works by checking two things:

1. SPF alignment: Does the sending server match your SPF record, AND does the envelope domain align with the From header domain?
2. DKIM alignment: Is there a valid DKIM signature, AND does the signing domain align with the From header domain?

For DMARC to pass, at least one of these must succeed with proper alignment. If both fail, and your DMARC policy is set to reject, the email bounces with the 554 5.7.5 error.

Common Causes

1. Sending Through a Third-Party Service Without Proper Setup

You're sending email through a service (marketing platform, CRM, etc.) but:

• Their servers aren't in your SPF record
• They're not signing with your DKIM key
• They're signing with their domain instead of yours

Example: You send through Mailchimp but your SPF doesn't include include:servers.mcsv.net and DKIM isn't configured for your domain.

2. Forwarded Emails

Email forwarding breaks SPF (the forwarding server isn't your authorized sender) and may break DKIM (if the forwarder modifies the message). When the forwarded email reaches its destination:

• SPF fails (wrong sending IP)
• DKIM may fail (modified content)
• DMARC fails (neither passes with alignment)

3. Misconfigured SPF Record

Your SPF record exists but doesn't include all legitimate sending sources:

v=spf1 include:_spf.google.com -all

If you also send through SendGrid, those emails fail SPF because SendGrid's servers aren't authorized.

4. Missing or Invalid DKIM

• DKIM isn't set up at all
• DKIM key has expired or been rotated incorrectly
• Wrong selector configured
• Key mismatch between what's published and what's signing

5. DMARC Policy Set to Reject

Your DMARC policy might be correctly rejecting messages from unauthorized sources — but those "unauthorized" sources include legitimate email you're trying to send.

v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain.com

With p=reject, any authentication failure results in a bounce.

How to Diagnose the Problem

Step 1: Check Your Current Authentication Setup

Use these tools to see your current configuration:

• SPF Record Check — verify SPF is correct
• DKIM Test — verify DKIM is working
• DMARC Record Checker — verify DMARC policy

Step 2: Examine Email Headers

If you have access to a delivered email (or the bounce message), check the authentication results:

Authentication-Results: mx.google.com;
       dkim=fail header.i=@yourdomain.com;
       spf=softfail (google.com: domain of sender@yourdomain.com does not designate 192.0.2.1 as permitted sender);
       dmarc=fail (p=REJECT) header.from=yourdomain.com

This tells you exactly what failed:

• dkim=fail — DKIM signature invalid or missing
• spf=softfail — sending IP not authorized
• dmarc=fail (p=REJECT) — DMARC failed, policy caused rejection

Step 3: Identify the Sending Source

Determine where the failing emails originate:

• Your email server directly?
• A marketing platform?
• A CRM or helpdesk system?
• A forwarding service?

Each source needs proper authentication.

How to Fix It

Fix 1: Update SPF to Include All Senders

Add all legitimate sending services to your SPF record:

v=spf1 include:_spf.google.com include:sendgrid.net include:servers.mcsv.net -all

Common includes:

• Google Workspace: include:_spf.google.com
• Microsoft 365: include:spf.protection.outlook.com
• SendGrid: include:sendgrid.net
• Mailchimp: include:servers.mcsv.net
• Amazon SES: include:amazonses.com

Fix 2: Configure DKIM for Each Sender

Each service that sends email on your behalf should sign with DKIM:

1. Generate DKIM keys in your sending service's dashboard
2. Add the provided DNS record (usually a TXT or CNAME)
3. Enable DKIM signing in the service settings
4. Verify with a DKIM test

Fix 3: Temporarily Relax DMARC Policy

If you need emails to flow while you fix authentication:

v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com

p=none tells receivers to report failures but not reject or quarantine. This is a monitoring mode — use it to gather data about what's failing, then fix those sources before moving back to enforcement.

Fix 4: Handle Forwarding

For forwarded emails, consider:

• ARC (Authenticated Received Chain): Modern mail servers support ARC, which preserves authentication through forwarding
• SRS (Sender Rewriting Scheme): Some forwarders rewrite the envelope sender
• Direct delivery: Have important emails delivered directly, not forwarded

Prevention

Monitor DMARC Reports

Enable DMARC reporting to catch authentication failures before they cause bounces:

v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@yourdomain.com

The rua address receives aggregate reports showing which emails passed and failed authentication.

Audit Sending Sources Regularly

When you add a new email service or change infrastructure:

1. Check if it affects email sending
2. Update SPF if needed
3. Configure DKIM for the service
4. Verify authentication before going live

Use Monitoring Tools

Automated monitoring catches authentication breaks before they cause widespread delivery failures.

DMARC Policy Progression

If you're setting up DMARC from scratch, don't start with p=reject:

1. Start with monitoring: p=none — collect reports, no enforcement
2. Move to quarantine: p=quarantine — failing emails go to spam
3. Finally enforce: p=reject — failing emails bounce

This progression lets you identify and fix authentication issues before they cause bounces.

Related Articles

---

Stop Chasing Authentication Errors

The Email Deliverability Suite monitors your SPF, DKIM, DMARC, MX records and blacklist status daily. Get alerts when authentication breaks — before your emails start bouncing.