Holding a vendor to it

“We fully support DMARC” is true of nearly every platform and tells you nothing. The conversation only becomes useful when the question is specific enough that the answer has to be yes or no.

The two questions

1. "Can you sign our mail with DKIM using d=example.com,
    rather than your own domain?"

2. "Can you use a return-path at a subdomain of
    example.com, rather than your bounce domain?"

Then, always:

3. "Is either of those available on our current plan?"

Either one satisfies DMARC alignment; DKIM is the more valuable because it survives forwarding. Question 3 is the one that determines your timeline, and it is the one people forget to ask until the configuration screen is missing.

Reading the answers

“Yes, here is the CNAME.” Publish it, then verify from a delivered message — a dashboard showing “verified” means they can resolve your record, not that they are using it.
“We already sign everything with DKIM.” Ask for the d= value. If it is their domain, the answer to your actual question is no.
“That is an enterprise feature.” A commercial question now, not a technical one. Get the price and the renewal date, and hand it to whoever owns the contract.
“You just need to add us to your SPF record.” A support script. Adding an include does nothing if they send with their own envelope domain — say so plainly and ask to be escalated.
“DMARC will break our sending.” It will break their unaligned sending, which is the thing you are asking them to change.

When the answer is genuinely no

Some platforms cannot align at any price. The options are then finite, and it is better to put all three in writing than to let the programme stall waiting for a fourth to appear.

Move that stream to a subdomain and give the subdomain its own weaker policy. Contains the exception rather than weakening the apex.
Change the visible From address to a subdomain the vendor can align with. Visible to recipients, and usually acceptable for one stream.
Replace the vendor. Not your decision, and it becomes the right one when the alternative is holding the whole estate at p=none.

Put the refusal in writing

A vendor that cannot support alignment is a documented constraint on the programme, and the reason a date moves. Recorded, it is a procurement input at the next renewal. Unrecorded, it becomes your missed deadline.

Knowledge check

A vendor says “we support DMARC — just add our include to your SPF record”. What has that established?

Nothing about alignment — if they send with their own envelope domain, your SPF record is never consulted for their mail.
That their mail will pass DMARC once the record propagates.
That they sign with DKIM using your domain.
That they need to be added before they can configure a custom return-path.

Correct — Nothing about alignment — if they send with their own envelope domain, your SPF record is never consulted for their mail. SPF is evaluated against the envelope sender’s domain. Until that is a domain of yours, adding includes changes nothing, and it spends lookups from a budget of ten for no benefit.

Not this — That their mail will pass DMARC once the record propagates. It will pass SPF for their domain, which it already did. Alignment with your From domain is untouched.

Not this — That they sign with DKIM using your domain. Nothing in that answer mentions DKIM. It is the question worth asking next.

Not this — That they need to be added before they can configure a custom return-path. A custom return-path moves the envelope to your subdomain, which then needs its own SPF record. The apex include is not a prerequisite.

The two questions

Reading the answers

When the answer is genuinely no

Try it on a real domain