How can I get my third-party senders DMARC compliant?

There are a few different ways that you can approach your situation with third-party senders. It will, of course, depend on what capabilities your third-party sender has in implementing these suggestions:

1. Integrate Externally: Your third-party senders can use their own mail servers to send your email. If this is an option, you can provide them with a sub-domain so they can put their own DKIM record and SPF record in for DNS. You can also give your third-party sender a DKIM private key to sign the emails and publish the public key in your DNS and/or add their sending IP to your SPF record. 

2. Integrate Internally: You can have your third-party sender relay your emails through your own mail server/s. Please note, you will need to ensure that the envelope is correct. You also need to take precautions that you are not creating an open relay situation on your side. 

3. Do Not Integrate (request they do not spoof): Ask your third-party senders to use their own domains in the from: header. If these emails need to have a reply, you can have them point this reply alias to you, or have the third-party sender set the reply-to: header to one of your email addresses.

In ensuring an authenticated email stream, it is necessary for companies to work with those who send an email on their behalf.  Service providers such as Salesforce are a good example but usually, these are marketing vendors who intend to send on behalf of the subscriber company.  The steps to achieving an authenticated mail stream are generally well understood and are as follows:

1. Send messages in compliance with SPF records published on the customer domain – This is generally well understood and is often accomplished by the customer adding an include: the third party.tld in their SPF record, assuming the vendors are current and complete. The customer may require explicit IP egress addresses to enter into the domain's SPF record, rather than an include: mechanism.
2. Ensure that customer's emails use the correct RFC 5321 Mail.From in the SMTP conversation; the domain used here this must match the custom domain in the message's RFC 5322 From header.
3. Implement DKIM signing for the customer domain; must use at least a 1024 bit signing key and the signing domain (d=) must align with the custom domain in the message's RFC 5322 From header.
4. MUST pass one of the above authentication mechanisms; implementing both will reduce the possibility of authentication failures and is strongly recommended.

Additional information from an implementation perspective can be retrieved from the appropriate standard website. Agari has tremendous experience in assisting our customers and their third party senders and hopes this basic list of requirements helps toward that endeavor. Don’t hesitate to contact us if we may be of further assistance.