Deployment

Email forwarding can sometimes throw a wrench in DMARC authentication results, and we often get questions about how to manage forwarded emails, especially with mailing lists. Emails are forwarded automatically all the time, more so than most people expect. Forwarding happens automatically when you send an email to myfriend@example.com and that person has set up their email to be forwarded to a separate inbox, like myfriend@dmarcian.com. Another common instance of automatic forwarding is a mailing list, like Google Groups. From the perspective of the email receiver—the one that is generating DMARC XML reports—your email appears to be coming from an infrastructure that has nothing to do with you. In Google Groups, DMARC data that displays forwarding will show your domain as a sender, a Google IP as the sender, and a variety of receivers who send the DMARC report as part of their DMARC check. This number can increase quite

Though Cisco email security appliances (ESA) can be configured to send DMARC aggregate (RUA) reports, they have a limited number of daily DMARC reports they provide. This limit can be easily reached by organizations sending large volumes of email, especially if multiple subdomains are seen in the From header of messages received. The number of subdomains seen is an issue because of a deficiency in how the Cisco IronPort system generates DMARC reports. Instead of creating a single XML report containing data for the top-level domain and any subdomains (e.g. example.com along with www.example.com, server.example.com, etc), each server instance generates a completely separate report for each—this causes the limit to be reached rapidly. Increasing the daily limit will ensure that you have the proper visibility and are helping other organizations with their DMARC projects. The daily DMARC report default setting is 1000, which can be increased only through the command-line

We often get questions about how DMARC policies apply to subdomains and how to establish a subdomain policy. Here’s some information to provide clarity and answer those questions. Because subdomains contend with the same abuse potential as parent domains, aka top-level or root domains, the astute authors of the DMARC control wrote specific conditions for subdomain policies. It goes like this: subdomains inherit the parent domain’s DMARC policy unless you indicate a subdomain policy using the sp= tag in the parent DMARC record or publish a p= tag on a subdomain. Keeping in mind that cybercriminals leverage unprotected subdomains for phishing exploits, it’s important to have a DMARC deployment plan for every subdomain you create, whether the parent domain DMARC policy is inherited, an sp= tag is published to rule the subdomains, or a p= tag is indicated for the subdomain. The DMARC policy definitions and actions apply to subdomain

In this article, we present a guide on deploying DMARC on Cisco’s Email Security Appliance(ESA). If you believe that you already have your system’s DMARC authentication and reporting set up correctly, please take the time to read through the information and compare it to your current settings. These settings are industry best practices, and we encourage you to not diverge from them. Your ESA’s AsyncOS version should be 13+. If 14, it should be 14.0.2 or greater due to a bug in lower versions of 14. NOTES: If you don’t set this up correctly, please don’t set it up at all. If it isn’t configured correctly, you’ll pollute valid data being sent from other sources, and your DMARC data may be blacklisted by aggregators. Varying settings from the recommendations in how or whether your environment performs SPF or DKIM verification will affect the ability of the system to perform adequate

Reports generated from our DMARC Management Platform give you insight into what is happening with a particular aspect of your domains. A useful resource to keep decision makers and stakeholders informed and updated relative to DMARC deployment and maintenance, reports help to bridge this gap. For dmarcian’s MSP and MSSP Partners, reports can be utilized to provide information to their client base. Since MSP clients can’t view their domain details on the dmarcian platform, reports are a way MSPs can keep their clients informed of their DMARC project. The following reports can be generated from our platform: Domain Status Reports: contains domain status information including email authentication deployment state and volume statistics. This report is based on the past seven days of data from the time it was generated. Issue Summary Reports: lists outstanding issues related to email authentication deployment. Account Progress Reports: provides an overview of all domains in

One of the outstanding features of DMARC is the feedback you get related to email sent from any source using your domain as the RFC5322 identity (friendly from). However, this is contingent on the receiver’s email security provider having the ability to perform DMARC verification on inbound email as well as sending the result of those checks in the form of an aggregate report. One such solution is Cisco’s Cloud Email Security (CES). When DMARC authentication for inbound email is enabled, the CES appliance can be configured to send DMARC aggregate reports containing the results of those inbound checks. This data is critical for domain owners relative to their DMARC deployment efforts. These reports are helpful, but more helpful yet is to know who is sending these reports. Knowing the source of the reports is beneficial if you need to follow up with them; better yet, you can easily identify

The dmarcian team categorizes the sources we see our customers use and include resources that assist in configuring sources to send DMARC-compliant email. Sometimes, however, we are unable to find any publicly available documentation on how to achieve DMARC compliance for a particular source—a service that sends email on behalf of another domain. In these cases, the customer must reach out to the source, or vendor, to request assistance. “Not all third-party providers officially support DMARC, and their first response may be negative,” says Ash Morin, dmarcian’s Director of Deployment. “However, the reality is that they may simply not understand the scope of the request. In our experience, a service provider will often find out that they are in fact capable of supporting DMARC once the requirements are explained clearly to them.” If you find yourself in a situation where you need to contact a source but don’t know what

For those of you that use Network Solutions as your DNS provider, here are brief instructions for publishing and adding a DMARC record. The post How to Publish a DMARC Record with Network Solutions appeared first on dmarcian.

Here’s a checklist you can use to get DMARC into place. The post DMARC Deployment Checklist appeared first on dmarcian.

The SPF Surveyor is a diagnostic tool that presents a graphical view of SPF records for a specific domain. This view can help you figure out which entries are in use and which ones are no longer needed. The post SPF Surveyor: See your SPF Record Activity appeared first on dmarcian.