## The basics By this point, you should have tackled both the SPF, and DKIM entries for all of the services sending on your behalf. Well, that you are aware of anyway, there is always more to find and shortly shadow IT, and less than helpful third parties will soon be revealed. ### SPF By this point I expect you have been through the SPF record and made it more explicit, removed any misconfigurations, and generally resolved the common issues - [[SPF - Writing the wrongs|made it more explicit, removed any misconfigurations, and generally resolved the common issues]]. It should be actively/automatically monitored, and checked for misconfigurations and issues, it should be reporting back to teams such as your: - Service Desk - SysAdmins - Security team - Network team These teams are often the first to encounter, troubleshoot, and fix the issues that stem from the record(s). Every organisation is different and the process behind/management of these records may fall under a different departments remit. ### DKIM At this point trying to have a [[DKIM - Auth me up Scotty|DKIM record]] in place for every mail sending service in use is extremely helpful, and will reduce the time spent on the incoming reports. ## Staging an initial DMARC record ![](https://media.tenor.com/images/015c6354e3e61960f7a60d10cf96a692/tenor.gif) __I have spent my whole life trying to figure out crazy ways of doing things.__ ### Setup Thankfully DMARC records can be quite simple and there are plenty of online generators and tools to manage them, for simplicities sake [I am including a link to the MXToolbox version.](https://mxtoolbox.com/DMARCRecordGenerator.aspx) Initially you want the record to have an action of none for the domain i.e. `p=none` and `sp=none`, along with DMARC aggregate and DMARC failure reports going to the reporting service. I would suggest as an initial configuration additionally setting: - Reporting Percentage to 100% (this might be lowered when elevating up the severity of the actions). - `fo=1` (failure reporting) to ensure that any misalignment is picked up, this enhanced option will ensure comprehensive reporting - That both `RUA` (aggregate) and `RUF` (forensic) reports are accepted. - `aspf=r` (SPF Alignment) is set to relaxed initially. - `adkim=r` (DKIM Alignment) is set to relaxed initially. For the `rua` and `ruf` reports - I can wholeheartedly recommend [URI-Ports](https://www.uriports.com/) and [ReportURI](https://report-uri.com/products) for the purpose of receiving and dealing with them. Both services offer a decent way to break down the reports, although URI-Ports has the nicer interface / scale for Small to Medium sized MSPs and companies. Additionally they offer a hosted MTA-STS / TLS-RPT service as part of their plans. For larger firms there are other solutions available and I would suggest partnering with the service that fully meets your needs. ### Monitor Now we wait, the reporting period by default is daily, and as a minimum I would suggest at least a couple of weeks before escalating to the quarantine stages. Depending on the complexity of the environment this may be as long as a quarter, or even up to a year. After a reasonable length of time [which will vary depending on the size of organisation, and usage patterns] you will eventually (and hopefully) have found, and dealt with any services which were not initially known about / configured. _****Make note: This process will be dealt need to be followed again with both the quarantine, and reject stages.****_ Skipping stages may result in customer complaints, annoyed users, and potentially a loss of data. ### Going Full 2020 - Quarantine ![](https://media.tenor.com/images/1ac6b3d890e909d8e105660f2ba2c044/tenor.gif) Quarantine to go with your Quarantini, Sir? Now that we've had a reasonable timeframe elapse from the initial implementation, and reacted and worked on any issues that arise - we can tweak the record to escalate into the first stage of protection. Please note changing from `p=none` to `p=quarantine` does not guarantee that the receiving server will block any emails which are incorrectly aligned, spoofing, or not listed in the record at all. Depending on the servers configuration it may still go through to the inbox, be redirected to junk, or quarantined at the organisational level. Additionally mailflow rules and other customisations may react different to this escalated configuration depending on the mail servers configuration. Continue to monitor for another acceptable period of time, and ensure that any valid sources which are showing up with issues are dealt with in the SPF and DKIM records where possible. ### The trifecta - You shall not pass The final step is to turn the filtering up to 100%, and REJECT, and continue to monitor the returns on the reports coming back to the monitoring service. You may notice that even more hosts report in than the NONE and QUARANTINE stages. This is due to the REJECT statement needing to be followed where as NONE and QUARANTINE will not always result in a return. Unfortunately - there is still a blind spot for office 365 at the time this article was written. Microsoft does not return or feedback on any DMARC reporting options regardless of the severity or configuration of the DMARC record. Hopefully this will change with time. Once all three elements are properly configured and tested, the pillars forming the trifecta are complete. From this point forward, Emails impersonating the domain(s) configured are unable to be spoofed. This has immense benefits in realising the ultimate protection of the brand, company/individual, and ensuring the shadow IT services are not able to be used blindly without the proper validation of the IT department/MSP. ![](https://media.tenor.com/images/e4b27de1e37fc49e0c9985d97da651ca/tenor.gif) Layering it all together with no exceptions makes for a Happy FSociety. ### Next Steps Have you heard of our lord and saviour? TLS-RPT and MTA-STS? --- [[Epistemic status|Colophon: Brewing]]