## TL;DR
Authorise the third party the DMARC way instead of asking receivers to make an exception: either give the sender a delegated subdomain to send from, have them sign DKIM with your domain using a selector you publish, or align their envelope sender under your domain. Pick one path, publish the DNS it needs, and test until the receiver sees an aligned pass, because a p=reject policy will keep rejecting any sender that cannot align.

```text
"550 5.7.1" dmarc policy violation rejected message from third-party sender
```

## Use this when
- A vendor, partner platform, or SaaS tool sends as your From domain and receivers bounce it with 550 5.7.1 DMARC policy violation.
- Your DMARC policy is at p=reject or p=quarantine.
- The sender is under contract and should be sending as you.

## Not for this skill when
- The sender is not authorised by you at all. Leave the rejection in place and investigate the spoof.
- Your own first party mail is rejected. That is your own SPF or DKIM setup, not third party delegation.

## Steps
1. Read the bounce and a sample message to see which domain the sender used for envelope, DKIM signing, and From. Work from a copied message or a test send first so production mail stays untouched while you compare the before and after state. Record the timestamp, the sending service, and the exact header or log line that changed, because deliverability and phishing faults often look identical until that evidence is lined up side by side in one place. Verify: the three domains for the failing sender are written down
2. Choose the delegation model with the vendor: subdomain sending, your-domain DKIM signing, or aligned envelope sender, based on what their platform supports. Do not change more than one setting at a time here. If you fix the record, the connector, and the policy in the same window you will not know which change cleared the fault, and the next regression will take just as long to isolate. Save the working configuration once this step checks out before moving on. Verify: one model is chosen and the vendor confirms it can do it
3. Publish the DNS the model needs: the selector key, the subdomain SPF and DKIM records, and a DMARC record for any new subdomain. Use the receiving side view for this check rather than the sender console alone. Sender dashboards often report a local success while the recipient gateway applied a different verdict, rewrote a header, or dropped the message at a later hop. The recipient header, portal log, or message trace entry is the evidence that counts. Verify: external lookups return the new records correctly
4. Have the vendor send a test through production settings, not their sandbox, and read the receiver headers. Keep any exception you create narrow and time boxed. Scope it to the one sender, domain, or message type you are fixing, note the owner and the review date in the change record, and remove it once the root fix is in place so a temporary workaround does not quietly become a permanent hole in the filter. Verify: the test shows an aligned SPF or DKIM pass and dmarc=pass
5. Watch DMARC aggregate reports for a week for that source before closing the change. Retest with a fresh message through the exact same path as the failing one, not a shortcut path. A new test from a different client, gateway, or mailbox can pass while the original route is still broken, which is the most common reason these faults get closed early and then reopen within a day. Verify: reports confirm sustained aligned passes from the vendor source

## Why it happens
DMARC reject tells receivers to refuse mail that cannot prove it speaks for the From domain. Third party platforms default to sending under their own domains, which passed unnoticed before enforcement and fails hard after it. The durable fixes all create a real cryptographic or envelope link to your domain; receiver side allow lists and policy relaxations do not scale and weaken the protection the policy exists to provide.

## Variants and edge cases
### 550 5.7.1 dmarc policy violation third party sender rejected
The bounce wording plus the delegation context.
### vendor mail rejected dmarc reject how to delegate subdomain
The subdomain delegation variant vendors and admins agree on.
### saas sender fails dmarc p=reject dkim selector delegation
The DKIM selector variant for platforms that support custom signing.

Compatibility: RFC 7489 DMARC, Gmail and Yahoo bulk sender requirements, common SaaS sending platforms with custom DKIM.

Edge cases to check:
- A delegated subdomain should get its own DMARC record so a vendor problem cannot force you to relax the root policy.
- Some vendors rotate DKIM keys; confirm how selector updates are handled before relying on their signing.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_JJ-Iv9AJW-BDymBXsu40Mg