How to Implement DMARC in Your Company

How to Implement DMARC in Your Company

How to Implement DMARC in Your Company

Do you want to avoid phishing scams that use your company's domain name as a scam? The Doman-based Messaging, Authentication, Reporting and Conformance (DMARC) standard can help you achieve that. Continue reading to understand how to implement DMARC in your organization.

If your firm has technical personnel that understands DNS and your email system, this is something that can be done in-house. If you don't want to tackle it alone, there are DMARC Service Provider firms that can set up DMARC for you, as well as collect and analyses all of the email use statistics you'll be getting.

The steps following presume that the email administrator has previously set up the authentication techniques SPF (Sender Policy Framework) and DKIM (DomainKeys Identified Mail).

The preliminary work

You must perform some prior work before deploying DMARC, including, of course, executive-level permission because this is a company-wide problem.

Next, compile a list of all approved email domains for your organization, including any external domains (such as marketing firms) that send mail on your behalf. This becomes the official list of approved email addresses—a whitelist if you will—for sending your letter. Any IP address that sends mail in your company's name but isn't on this list will have its messages deleted in the end. (But not straight away.) You'll have an opportunity to double-check that you've got every legitimate source.)

Notify the person or service provider in charge of your DNS infrastructure that you will need to modify your DNS record at a certain point.

To receive your DMARC reports, create an email address. You'll be able to choose how many reports you get, but you can anticipate receiving one daily aggregate report.

Ready for deployment

With those first steps done, it’s time for deployment.

Get out the list of all the domain names that send emails on your behalf. You need to deploy a DMARC DNS record for all of these domains

A text record connected to the parent domain is the DMARC record. "_dmarc.your," where "your" is substituted with your real domain name. The format of that record is described in the standards on the website. There's a wizard there that will guide you through creating your first DMARC record. The disposition of messages that are not DMARC aligned is what you write in the record. You want the ISPs to pass all of the messages through (that is, deliver them to their designated recipients) at first. You'll eventually want to state that records that don't match your DMARC record must be deleted.

When you set up the DMARC record, you’ll specify the email address where aggregate reports should be sent on a periodic basis, usually once a day.

The reports are sent in an easy-to-understand XML format. They detail the sources of your domains' messages as well as their DMARC alignment. A notification from Gmail, for example, may show that a certain IP address sent 300 messages using your company's domain name, none of which complied with your DMARC policy. That implies they are very certainly phishing emails, and you already know it's legal for ISPs to reject them instead of sending them. However, the mails might be from a legal domain that didn't make it into your domain list at first. Perhaps it's from a third-party email service provider you're not aware of. In this scenario, you must contact that provider and request that SPF and DKIM authentication be applied. They should no longer appear on DMARC reports after that, and you can be certain that their emails will not be deleted.

It's almost probable that the DMARC reports will include notations of messages that you don't recognize. That is because those are phishing emails. If your domain has been phished, this is how it will seem. The idea is that after you've completely activated DMARC, the communications will be deleted and will never be sent. This is where DMARC comes into play.

To obtain a decent picture of the email trends, you'll need at least a week's worth of reports. Once you have a solid idea of who is sending valid emails on your behalf, you can set up your policy and, if you haven't previously, your SPF and DKIM authentication.

Because it is based on the sending domain and maps it to a set of IP addresses, SPF is the easiest to set up. So you've got your domains, and you've got the IP addresses that are sending legitimately because you figured it out via the DMARC reports. The next step is to produce the required SPF record and publish it on the Internet.

Setting up DKIM is a little more difficult because it requires changing the settings of the email-sending system. An Exchange server, or an external third party, or a gateway in front of the Exchange server, is usually the cause. That device must be updated to execute a DKIM signature, which must subsequently be advertised to the DNS in accordance with DKIM standards.

Published by Pintu Bhatt

Comment here...

Login / Sign up for adding comments.

Similar Articles