Skip to main content
Solved

DMARC policy configuration for Office 365 environment

  • 28 November 2018
  • 7 replies
  • 138 views

Dear colleagues,

We are your clients. We use Office 365 as mail system. We've enabled DMARK in reject 100% mode recently.

And we've stumbled acrossed a problem.

Docusign sometimes sends notifications on behalf of our users - so sender is ouruser@ourdomain.com BUT of course email is from Docusign IP.

DMARC policy rejects such messages as Docusign is not a permitted sender (Docusign IPs are not ).

Can we configure Docusign not to email on behalf of @ourdomain.com ?

What is the best practice?

Thanks!

 

7 replies

Userlevel 3

I was curious on whether you are using a DocuSign integration or not? Such as DocuSign for Salesforce?

Userlevel 3

No, we don't have such integration. Docusign for some reason does the following: sets FROM: ouruser1@ourdomain.com and send it to ouruser2@ourdomain.com from Docusign IP. That is bad situation from DMARC's point of view. Unless we add Docusign IP to our SPF. But we do not want if possible. That is the issue. Will continue with Docusign support and write results here later.

Userlevel 1

I have seen this in the past when using the "Send on Behalf Of" administrative setting but I have only seen this used with the DocuSign for Salesforce integration. I think the DocuSign case is the best way to go, but please post the resolution once it has been found. Might help future community users.

Userlevel 3

Hello,

Thank you for posting to the DocuSign Community!

DocuSign can be configured to send emails on your behalf, from "dse@docusign.net" for example, in fact this is the default setting used by the majority of our accounts. It would stand to reason if your account is using the "Send Email on Behalf of" feature, resulting in emails being sent from "sender@yourdomain.com" your account was configured away from the default method at some time.

Such configurations require continued maintenance of SPF configurations to ensure all relevant IP address and other data is kept up to date. If you are seeing intermittent failures, aspects of the configurations falling out of validity may be the cause. Though I will add, these issues are often complex and due to the nature and content such troubleshooting, are best not discussed in a public forum.

  

Kind Regards,

Damian

Community Moderator

Userlevel 3

Dear colleagues,

I can confirm that David was correct - we had "Send on Behalf Of" SOBO function enabled somewhere inside Docusign. With support's help we switched this option off and now emails are coming as dse@docusign.net and so DMARC feels himself much better.

Thanks everyone!

BR,

Nikolai

Userlevel 3

Great to hear you were able to resolve.

Badge

if you are using Azure and Office 365 you will need to add an allowance for spoofed senders to your incoming rules. In our case we have one for Netsuite and Docusign which sends with our CIO’s name

In the Tenant Allow/Block List, you can create allow entries for spoofed senders before they're detected and blocked by spoof intelligence. In the Microsoft Defender portal at https://security.microsoft.com, go to Policies & rules > Threat Policies > Rules section > Tenant Allow/Block Lists.

 

Consequently Defender would also flag some of the common email address as being impersonated. ex: ap@domainname.com or payables@domainname.com especially when it came to trying to receive email from outside the company when they also used those email display names

Reply