DMARC describes the sender's email policy, which is probably something your client needs to decide on.
A p=reject
for instance instructs the receiving MTA to reject any email from your customers domain that fails any DKIM and/or SPF checks. That is something that have can a big impact on mail delivery if set inappropriately.
You can recommend and argue for or against using that value and the same for the values in other DMARC tags.
Your customer then needs to decide.
Once they have decided you can craft the DNS TXT record they need to create in their DNS. That is fairly trivial actually, it is a dns text resource record
_dmarc IN TXT "tag=value[;tag=value ...]”
Or when you don’t use dns short hand
_dmarc.example.com. IN TXT "tag=value[;tag=value ...]”
Rather than applying to the full domain you can create a policy that is limited to email addresses of a sub domain mailbox@sub.example.com too
_dmarc.sub.example.com. IN TXT "tag=value[;tag=value ...]”
The impact of for instance using
_dmarc.example.com. IN TXT ( "v=DMARC1;p=reject;sp=reject;pct=100;adkim=r;aspf=r;fo=1;ri=86400;rua=mailto:dmarc-admin@example.com")
Versus
_dmarc.example.net. IN TXT ( "v=DMARC1;p=none;sp=reject;pct=10;adkim=r;aspf=r;fo=1;ri=86400;rua=mailto:dmarc-admin@example.net")
Can be quite big.