550 5.7 0 DMARC policy violation

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 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 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.

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:

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 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.

Start with Palisade

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