DMARC ReplyTo

Question

Attempting to plan a DMARC implementation for use with Exchange Online Protection.  Does DMARC analyze the RFC5322.ReplyTo header of a message?  I look at the RFC and don't see any references to ReplyTo analysis.  

If it doesn't, do you have any recommendations on how to stop email spoofing as shown below?  Assuming I own contoso.com but not dr.com.

From: "Jones, Mike" <*** Email address is removed for privacy ***>

To: "Smith, Roger" <*** Email address is removed for privacy ***>

Subject: Transfer Inquiry

Reply-To: Mike Jones <*** Email address is removed for privacy ***>

Answer 1

Thank you for the confirmation Larry.  In regards to the SPF configuration you identified, based on my understanding of SPF, this configuration would also not perform any analysis against the reply-to address if specified in the message envelope.  Are you aware of any Exchange Online Protection settings that would allow a EOP customer to set restrictions on the Reply-To field?  I understand that by doing so it may flag messages that are not malicious, but I'd like to understand EOPs capabilities around evaluating Reply-To for spoofing.  Some executives in my org received messages similar to the one below.  I'm trying to identify if there are any EOP features that would evaluate the reply-to header for spoofing to see if it makes sense to implement technical fix or just continue to manage user behavior to ensure that they don't take action on these types of messages.

From: "Jones, Mike" <*** Email address is removed for privacy ***>

To: "Smith, Roger" <*** Email address is removed for privacy ***>

Subject: Transfer Inquiry

Reply-To: Mike Jones <*** Email address is removed for privacy ***>

Roger, Can you please transfer $50,000 to account 21342341 to support the merger?  Due to the criticality of this request it should take priority over other tasks.  Please email me when complete.

Answer 2

Thank you Doris, but unless I'm missing something, I don't think your response answers my question.  I understand that DMARC has the ability to reject messages based on evaluation of RFC5322.From domain, but my questions is in reference to if it also does some evaluation against the RFC5322.ReplyTo field.  If it doesn't then SPF, DKIM and DMARC don't appear to have any control over the "Reply To:" data and could result in a user sending a response to an unexpected recipient.

Answer 3

Hi ME3994,

Yes, you are right. The configuration above won’t analyze the ReplyTo header of a message either.

However, after configuring this spam filter, it will delete or quarantine (depends on you) the spoofing emails which sent with the email addresses in your organization. Because if SPF hard fail is enabled, emails from an IP address which is outside the IP range that is defined in the SPF record will failed the detect.

In the same time, you may continue to manage user behavior to let them confirmed with the sender in other ways (like phone calls) before taking actions on any security conscious messages.

Thanks,

Larry

Answer 4

Hi ME3994,

DMARC won’t analyze the RFC5322.ReplyTo header of a message.

If your concern is to stop email spoofing, you may follow the steps below to edit the default spam filter:

1. Login to EAC (Exchange admin center) with an admin account.
2. Click protection->spam filter->double click the Default one.
3. Click spam and bulk actions, then choose Delete Message or Quarantine Message under the spam and bulk actionssection.
4. Turn on SPF record:hard fail in the advanced options section and then click Save.

Then the spoofed emails will be deleted or quarantined. More information can be found in the article below:

https://technet.microsoft.com/en-us/library/jj200684%28v=exchg.150%29.aspx

If anything is unclear, feel free to let us know.

Thanks,

Larry

Answer 5

Hello,

If you are sending email messages on behalf of a domain that you do not own that publishes a DMARC record with policy p=reject (for example, @yahoo.com, @aol.com, @paypal.com), your messages will be marked as spam when sending to another EOP tenant or may even be rejected due to failed authentication, both when sending to EOP and when sending to 3rd party receivers.

There are common cases when this occurs. Check the blog and see what should you do>>>

blogs.msdn.microsoft.com/.../

Thanks,