Companies often have issue with their DNS records for their email.  These values are important for email authentication. This is how the mail server knows that your mail is genuine. Most companies have a proper SPF record added but are unfamiliar with DKIM and DMARC and the values they provide.

As of March 2018, only 9% of domains of companies are vulnerable to being spoofed ref Microsoft Docs

SPF = Sender Policy Framework

SPF is a list of who can send mails on behalf of your domain. Even though this normally is the first value you add It’s often not configured correctly.  To view the current SPF TXT records to determine the number of lookups, use NSLOOKUP.

Normal mistakes

Not adding SPF to subdomains

SPF records are not inherited, and you need to add a SPF TXT for each subdomain

Adding to many lookups when using third-party domains

You can only create one SPF TXT to your custom domain. Using multiple records is not supported but some providers may support it causing nondeterministic behavior. To avoid this, create a subdomain for each domain

Creating a lot of included SPF records

We have seen a lot of companies making workarounds with included SPF records. Even though this might work but will give a third-party access to send as main domain in your environment, resulting in a security risk.  The proper way to do this is to create subdomains and then add a new SPF record to the subdomain.

DKIM = DomainKeys identified mail

When you are sending from allowed server and DKIM is setup properly, it adds a signature to your mail so that receiving server can verify that its from you. This prevents attackers from sending messages that looks like they are from your domain

If you don’t configure DK for your domain, Microsoft  354 creates a private and a public key pair, enables DKIM signing, and then configures the Microsoft 365 default policy for your  .onmicrosoft.com domain.

Things to consider

Setup DKIM for custom domains

You will need to configure DKIM to all custom domains added to your e-mail server.

Setup DKIM for third-party services

Some bulk email providers, or software as a service provider, let you set up DKIM keys for email that originates from their service.

Identify domains that do not send email

Organizations should explicitly state if a domain does not send email by specifying DKIM so that emails claiming to be from that domain instantly gets rejected. Do this for each domain and subdomain using wildcard DKIM.

DMARC = Domain-based message authentication, reporting and conformance

Enabling DMARC helps companies to control the mails that are being sent from their domain and what the world should do with unauthorized mail.  DMARK is based upon both results from SPF and/or DKIM and at least one of them must be in place in your domain.

DMARK also gets reports back from email servers which provides insight on how your emails are moving. This allows you to identify everything that is using your email domain, including Shadow IT.

Example:

In this transcript, the sender addresses are as follows:

 Mail from address (5321.MailFrom): phish@phishing.contoso.com

 From address (5322.From): security@woodgrovebank.com

If you configured SPF, then the receiving server does a check against the Mail from address phish@phishing.contoso.com. If the message came from a valid source for the domain phishing.contoso.com, then the SPF check passes. Since the email client only displays the From address, the user sees this message came from security@woodgrovebank.com. With SPF alone, the validity of woodgrovebank.com was never authenticated.

Best Practices for implementation

Monitor the impact of implantation of DMARC

Start with a simple monitoring-mode record with a p-none policy so you can evaluate the actual traffic and see how much e-mail you would lose by implementing a DMARC.

Request that external mail system quarantine mail that fails DMARC

When most of your legitimate traffic is protected by SPF and DKIM, and you understand the impact of the DMARC, implement the quarantine policy.

Request that external mail systems not accept messages that fail DMARC

The final step is implementing a reject policy. A reject policy is a DMARC TXT record that has its policy set to reject. Receiving servers will not accept messages that gets fail on

DMARC for subdomains

DMARC is inherited unless a different policy is explicitly defined for the subdomain.