12-27-2019 05:20 PM
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?
12-27-2019 07:18 PM
12-30-2019 10:29 AM
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?
12-30-2019 11:09 AM
12-30-2019 12:12 PM
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
12-30-2019 01:12 PM
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?
12-30-2019 05:48 PM
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
01-02-2020 03:09 AM
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide