# 550 5.7 0 DMARC policy violation

> 550 5.7 0 DMARC policy violation needs provider-specific evidence. Check the exact SMTP response, sending domain, and published DMARC record.

A `550 5.7.0 DMARC policy violation` response indicates that a receiving or relay system refused a message and associated the refusal with a policy decision. The code alone does not safely identify the mailbox provider, the exact failed authentication check, or the correct DNS change. Preserve the complete SMTP response, identify the visible From domain and sending service, then compare that evidence with the published DMARC record.

## Quick takeaways

- A `550 5.7.0` response is SMTP evidence from a specific receiving or relay path, not a complete diagnosis.
- The same enhanced-status-code family can be used for different policy decisions by different systems.
- Do not change a DMARC record until you know which domain and production sending path produced the refusal.
- A public DMARC lookup can show the currently published record, but it cannot prove why one receiver refused one message.
- The full bounce text, message headers, and receiving provider documentation are the evidence needed to connect a refusal to a particular authentication condition.

## Why a DMARC-related SMTP refusal needs more evidence

DMARC is part of an email authentication decision, but an SMTP refusal is still made by the system receiving or relaying the message. The response may be generated by the recipient's mailbox provider, a secure email gateway, or another service in the delivery path. Without the complete response and the system that generated it, the phrase "DMARC policy violation" is too broad to map to one remediation.

Keep the original bounce or delivery log. The useful evidence includes the recipient domain, the sending domain shown in the message, the server that returned the response, the timestamp, and the full unedited response text. If a delivered copy exists, preserve its raw headers as well.

A DMARC-related decision can depend on identifiers that are not visible in a public DNS lookup. The domain in the visible From address may differ from the envelope sender or the domain used by a DKIM signature. A sending service can also use a subdomain with its own DMARC policy. For protocol context before reviewing the error, see [DMARC](/learning/dmarc).

The safe decision rule is:

- If you have only the short error text, collect the complete SMTP response and delivery-path evidence before changing DNS.
- If you have the sending domain, inspect its public DMARC record and record the result.
- If you have message headers, compare the authentication results with the exact sending path.
- If the receiving provider publishes documentation for the exact response, use that provider guidance to determine the required repair.

![Decision record for investigating a 550 5.7.0 DMARC policy violation, starting with the full SMTP response and ending with record and message evidence](/images/editorial/550-5-7-0-dmarc-policy-violation/550-5-7-0-dmarc-policy-violation-decision-record.webp "1200x829")

*Source: Palisade.*

## When the answer changes

The next action changes with the evidence available. A message rejected by one recipient system is not proof that every recipient will make the same decision, and a passing public record lookup is not proof that the application sent with the expected authenticated identifiers.

### When the sender uses a subdomain

Check the exact domain in the visible From address. A sending path that uses a subdomain can be subject to a distinct record or a subdomain policy. Read [DMARC policy for subdomains](/learning/dmarc-policy-for-subdomains) before assuming the organizational-domain record is the only relevant policy.

### When the error is from Microsoft 365

Do not treat every Microsoft 365 `550 5.7.x` response as the same condition. The existing guide on [Microsoft 365 550 5.7.x access denied errors](/learning/fix-microsoft-365-550-5-7-x-access-denied) covers a related error family, but the provider's complete response remains the evidence that determines whether the situations match.

### When the message was sent through a third-party service

Identify the service and the domain configuration used for that specific message. A domain can have multiple legitimate sending sources, and one source can fail while another succeeds. Review the sending service's delivery logs and authentication status before publishing a replacement DNS record.

> Do not replace a DMARC record because of one rejected message unless the affected sending source, visible From domain, and documented receiving-system condition are known. An incorrect change can disrupt legitimate mail from other sources.

## Worked evidence record

Record the evidence in a ticket or incident note before making a change. Use placeholders, not customer data, when sharing the case outside the authorized team.

```text
Observed response: 550 5.7.0 DMARC policy violation
Recipient domain: recipient.example
Visible From domain: yourdomain.com
Envelope sender domain: [from the sending system]
DKIM signing domain: [from the message headers]
Returning server: [from the complete SMTP response]
Sending service: [application, ESP, or relay]
Published DMARC record: [current DNS result]
Provider documentation: [exact URL for the returning system]
```

This record separates observations from conclusions. The response establishes that delivery failed at a particular point. It does not establish which identifier failed, whether SPF or DKIM was involved, or whether changing `p` will fix the message.

For example, a lookup might return a DMARC TXT record shaped like this:

```text
v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com
```

This is illustrative only. Do not publish this value unchanged. The record shows a requested DMARC policy and an aggregate-report destination, but it does not reveal the authentication outcome for the rejected message. Compare it with the headers and the sending service's evidence before deciding what to repair.

## Check the evidence you have

Start with the input that can answer a narrow question.

- If you have a domain name, [check the published DMARC record](/tools/dmarc) and save the result with the incident.
- If you have a bounce, obtain the complete response and identify the returning server and recipient domain.
- If you have message headers, inspect the authentication results from the actual production path.
- If you have a provider-specific error reference, follow the documented condition for that provider instead of assuming a generic `550 5.7.0` interpretation.

After the immediate case is understood, an IT team or MSP may need to review whether other sending sources use the same domain and have consistent authentication evidence. Palisade analyzes DMARC aggregate-report data, identifies sending sources and authentication or alignment issues, and creates prioritized remediation tickets. A human reviews the evidence and applies any DNS or policy change.

[Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=dmarc_policy_alignment&utm_content=550-5-7-0-dmarc-policy-violation)

A DMARC platform does not prove why a particular receiver returned this SMTP response, change the DMARC policy automatically, or guarantee future delivery.

## Sources and further reading

- [Palisade DMARC checker](/tools/dmarc)
- [DMARC learning center](/learning/dmarc)
- [DMARC policy for subdomains](/learning/dmarc-policy-for-subdomains)
- [SMTP error 550 5.7.509 and DMARC verification](/learning/smtp-error-codes/550-5-7-509)

## Frequently asked questions

### What is 550 5.7 0 DMARC policy violation?

A `550 5.7.0 DMARC policy violation` is an SMTP rejection in which the receiving or relay server refused the message and tied that refusal to a policy decision about the sending domain. The short code does not identify the provider or the exact check that failed. Use the full SMTP response, the returning server, and the message's sending-domain evidence to work out what the system evaluated.

### What does DMARC violation mean?

A DMARC violation means a receiver decided a message did not meet the DMARC requirements for the domain in its visible From address, usually because no passing SPF or DKIM result was aligned with that domain. Different systems apply the phrase to different conditions, so check the receiving provider's own documentation for the exact response you received. Do not assume it always points to the same SPF, DKIM, or DNS fault.

### How do I fix email error 550 5.7 1?

Start with the complete `550 5.7.1` response and the documentation of the system that returned it, because 5.7.1 covers different conditions from 5.7.0 and often has nothing to do with DMARC. Identify the returning server, the recipient domain, and the sending application. Inspect that production path before you change any DNS record.

### How do I fix a DMARC policy?

Identify every legitimate sending source for the domain first, then publish the policy that matches what those senders actually do. A public record check shows what DNS publishes, not whether each application authenticates correctly or whether a receiving provider will accept future messages. Change `p` only once the sender evidence supports it.

### Can a DMARC record check explain a rejected message?

A DMARC record check cannot explain one rejection, because it only shows the TXT record published right now. It cannot show the headers from the rejected message, the receiver's private policy decision, or how the sending application authenticated. Pair the record result with the full bounce text and the raw headers.