cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2588
Views
5
Helpful
7
Replies

Setting up an Exchange server with DMARC on ESA

stevenk2
Level 1
Level 1

We have an Exchange 2010 server that sits behind an IronPort C170, and we'd like to enable DMARC/DKIM.  I was able to follow the Cisco guide for setting up DMARC on our C170, and everything appears to be correct (including when I go to test the signing profiles to our public DNS records/DKIM keys), but when I go to send outbound emails, they land in quarantine due to a DMARC failure.  I combed through all of the settings to make sure that I had everything correct on the C170, but one thing I noticed when checking our MX record is that we have a header mismatch on our emails.  This is due to our Exchange server using its' internal FQDN machine name in the outbound email headers, where our MX record returns the FQDN and IP of our C170.  The question would be if this would cause the DMARC rejections, and if so, how do we go about addressing the issue so that our outbound emails don't get rejected?

 

In doing some research, it seems as though you can adjust the email headers in Exchange, though I'm not sure of the wisdom of doing so.  And even if that can be done, can we simply change that so that it's the same as our MX record?  Also, from a security standpoint, do we want/need to somehow mask or block our Exchange server name from the email headers regardless?  And what is the effect of doing so in relation to DMARC?

7 Replies 7

So, generally you don't need DMARC between the Exchange server and the ESA...



It sounds like the mail from your Exchange server is getting treated like its "external" mail .

On the ESA, do you have 2 listeners or 1? (Under Network/Listeners)



Generally you set up the ESA with an "inbound" listener, and an "outbound" listener.

You set the IPs of the Exchange server in the "Relayed" sender group, so that mail gets treated as "outbound", eg, no DMARC/DKIM, outbound policies, etc.



>The question would be if this would cause the DMARC rejections, and if so, how do we go about

>addressing the issue so that our outbound emails don't get rejected?

See above comments about mail flow



>In doing some research, it seems as though you can adjust the email headers in Exchange,

>though I'm not sure of the wisdom of doing so. And even if that can be done, can we simply

>change that so that it's the same as our MX record?

That just creates more of a mess than you need... and could make troubleshooting harder later.



>Also, from a security standpoint, do we want/need to somehow mask or block our Exchange

>server name from the email headers regardless?

Some would say so, but I don't think its worth it...



>And what is the effect of doing so in relation to DMARC?



Since, in the end, DMARC is only between the ESA and other external systems, it won't matter












Thanks for the response on this, Ken.  So if I'm understanding correctly, this means that DMARC is really only enabled and relevant on inbound emails?  Outbound emails go out without DKIM?

 

Currently, we only have one listener on our ESA (for inbound emails).  Outbound are apparently routed using the 'Relayed' settings.  Would best practice be to have two separate listeners, one for inbound and one for outbound?

Right, from the ESA's point of view, DMARC is only relevant on incoming mail.

The ESA does DKIM, SPF and DMARC lookups on incoming mail, and if it fails/passes DKIM & SPF, DMARC will tell it what to do...



Generally I find it easier to troubleshoot with 2 listeners, each on its own IP, but 1 is fine.

In your case, make sure the policy that the 'Relayed' sender group is using has DMARC checking turned off.




Let me add a few thoughts here about our SPF/DKIM/DMARC experiences over the last 3 years. This document will be edited as more information becomes available...

 

Outbound Traffic - active domains

 

Make sure your SPF records are correct and contain at least all your mail servers as well as all the known external service providers sending emails in your behalf. Make sure to review your SPF record every 3 months.

Make sure you sign every outbund email with a  DKIM key. Roll over those keys at least on a yearly basis. We have two DKIM keys per domain, one per user initaited emails and one for system initiated emails.

Make sure your DMARC records are are at least in monitoring mode for the main and all subdomains.

 

Inbound Traffic - active domains

 

Step 1 :

 

Validate PTR, SPF and DKIM

Create a bad PTR sender policy and add all business critical senders into this policy so they can bypass PTR checks.

Create a bad SPF or none sender policy and add all business critcial senders into this policy so they can bypass SPF checks. We use a message filter to keep a copy of such emails and drop SPF status of Fail,PermError, SoftFail and TempError  for HELO, MAILFROM and PRA.

Create a bad DKIM or none sender policy and add all business critcial senders into this policy so they can bypass DKIM checks. We also use a message filter to keep such emails and drop DKIM status of Fail.

Create a bad ARC or non sender policy and just add bad ARC senders/verdicts  into this policy. We will at a later step create a message filter to validate or reject ARC headers.

Create a policy called SenderInventory and add all existing known good senders to that policy. Make sure you exclude this policy from DMARC checks.

 

Step 2 :

Change your DMARC DNS records at least for monitoring mode of main and subdomains. Send the RUA and RUF records to a well known DMARC Aggregator as it is simply not possible to do this task without the help of them.

 

Options we have tested and are working are:

DMARCIAN

DmarcAnalyzer

MXToolbox DMARC

Agari DMARC

Proofpoint DMARC

Valimail DMARC

 

Pricing depends on # of email domains and volume of email.

 

What you mainly need to get out over at least a  3 month period is a good sender inventory of all valid internal and external senders sending emails in your behalf. Add them to the SenderInventory policy.

 

Step 3 :

 

Change the setup of your ESA so that every incoming and outcoming email is handled by them. Dont worry about systems like O365 which are already signing email messages with DKIM as you will most likely just sign them again and remove existing signatures.

 

Step 4 :

 

if your sender inventory is complete change the DMARC setup of your ESA to honor the rejection of any DMARC enable senders. This is also the moment where you should start changing your DMARC records action from None to Q first and to Q later.

 

I call this kind of setup SmartDMARC as you are not fully implementing DMARC for inbound until you have a good enough sender inventory, but can you go into Outbound Reject mode very quickly once you feel confident about your sender lists. For larger domains with many external senders this is the best way to go forward without impacting email delivery.

 

Please feel free to comment and I will try to answer

 

-Marc

 

 

Thanks, Marc!

 

However, this brings up an issue from my original post/question here.  Our email headers are not aligned - outbound emails from our Exchange server contain the server name; our public MX record does not.  So the question becomes how to get those aligned, since presumably the SPF record will never be valid unless they are.  My original thought was to change the header for our Exchange server on the server itself, but it sounds like the better answer may be to just add an SPF entry that aligns with our existing header.  Is it possible/acceptable to have multiple SPF entries, one that matches our MX record and one that matches our Exchange server?

There are a few ways you could solve this.

 

In my opinion the best way would be to have a SPF entry for every email system which can sent emails to the external world.

 

In our case we have the domain spf records but also one spf entry for every ESA appliance allowed to do so. instead of rewriting the headers on the Exchange server I would more likely look at at domainmap and masqerading feature of the ESA listenerconfig command.

 

This allows as an example to rewrite internal senders like application@internal.domain.com to become application@outbound.domain.com. By doing this all the outbound email adresses are properly alligned and can even be DKIM signed by the ESA.

 

Please let me know if I misunderstood your question

 

-Marc

 

Sounds like a Mail Flow Policy attributed to the Sender Group that the internal Exchange Servers are a member of, (or is inheriting from the default Mail Flow Policy) has had email authentication verification checks enabled.
- And as only DMARC has a built-in profile with actions, (SPF / DKIM required a manual filter / content filter to act on the result ) then this would appear to be most likely in relation to DMARC. Message Tracking should advise in the details.
- At least you've seen this in action, as I would 'recommend' setting the DMARC Default Policy to 'No Action' initially and Not to 'Send aggregate feedback reports' initially. But it would hide this issue unless the logs are being checked before moving to turn these on.

Enable ?
1) - as in enable checking incoming mail with SPF/DKIM/DMARC verification ? ( which is more for verifying other domains, but will include your domain/sub-domains being used by 3rd party mail systems - mailchimp, sendgrid etc. )
2) - or enable DKIM signing on outbound mail and setup associated SPF / DKIM / DMARC DNS records in public DNS for your own domains?

Outbound mail from internal Exchange server being verified for email authentication
- Within the HAT, a Mail Flow Policy is attributed to each Sender Group and the All (or none) default Sender Group
You should have a Sender Group for your Exchange Servers (possibly also other 'internal' mail servers)
This will be using a Mail Flow Policy with the Connection Behavior RELAY
This Mail Flow Policy will have SPF / DKIM / DMARC verification settings that should be set to OFF ( but may be set to Use Default (On) inheriting from the default Mail Flow Policy - I tend to not enable these type of settings via the default policy, however much time this may save, because of the potential for such an accident where some settings are more related to ACCEPT connections and some to RELAY connections. )

Basically, only enable email authentication verification on Mail Flow Policy with the Connection Behavior ACCEPT
But each Sender Group needs to be taken on its own merits, as beyond connection behavior, usually you are using a Sender Group to 'whitelist' from a number of checks.

MX Records - nothing to do with email authentication. With the only exception being if +mx was used in an SPF record.

You can strip Received Headers ( if using a dedicated Listener or dedicated outbound ESA there is a Listener setting, else you could strip Received Headers via a more accurate Sender Group based filter). It is obviously 'recommended' to hide internal naming conventions and network IP ranges etc.
But how advantageous, you would need to ask a hacker after an event.