Lines of DMARC-ation: Better Protection for Email

Email is one of the oldest vectors for threats into your IT – and it is still one of the most common. Email servers can pose security risks in two ways. First, through malicious email that is received (and according to Verizon’s 2024 Data Breach Investigation report, if a user opens a phishing email, it takes 47 seconds for them to click the link and submit their credentials).

But second – and less well recognized – is the risk of your email services being hijacked and used to send spam or malicious emails. Like phishing or receiving malicious emails, being used as a way of sending malicious emails offers very real risks to organizations, including loss of reputation and trust, potential penalties or fines, or having your email domain blacklisted and blocked.

Protocols Designed to Protect

There are protocols that have been designed to ensure that emails are sent safely. These are part of your DNS record, the Internet definition for your domain.

• Sender Policy Framework (SPF). SPF defines a list of approved email servers which can send emails from your organization – this prevents external parties from masking as your domain while using a different server.
• DomainKeys Identified Mail (DKIM). DKIM is a digital signature applied to all of your emails, using public key infrastructure to define an encryption key for messages sent through your servers which can then be verified by your recipients.
• Domain-based Message Authentication, Reporting, and Conformance (DMARC). DMARC expands on DKIM and SPF by providing guidelines on what servers should do if an email fails either verification. Configuring a DMARC policy that automatically quarantines or blocks email when it fails SPF or DKIM can help protect your domain from being used for fraudulent activities. However, there is a risk of blocking legitimate emails if SPF and DKIM have not been properly configured first. 

Challenges of Managed DMARC

 There are two challenges with managing DMARC policy. 

• Policy trade-offs. Setting a policy that allows all emails is higher risk from a security perspective but low risk from an email deliverability perspective. Setting a policy to quarantine or block emails is lower risk from a security perspective, but increases risk of email deliverability issues. Organizations need to have good data DMARC data to make these decisions. 
•  Data overload. Every time an email is sent from the domain, the receiving server will send back a DMARC report that includes the results of the SPF and DKIM checks. While this data is extremely valuable for making DMARC policy decisions, the volume of reports can quickly overwhelm an organization that doesn’t have a good way to centralize and analyze the incoming data. 

How Thrive Manages DMARC

 Thrive Managed DMARC Analysis service includes a purpose-built DMARC reporting solution to collect and manage all of the incoming DMARC data for a client. The tool creates reports that make it easy to pinpoint potential issues with SPF and DKIM configuration. This keeps the client from being overwhelmed with data and helps them make decisions about DMARC policy. 

As part of managing email domains, Thrive deployment engineers make recommendations based on the initial reporting from the DMARC reporting solution. Then after a tuning period, Thrive will follow up with guidance on when the client is ready to switch to a more secure DMARC policy without making unacceptable trade-offs in email deliverability. 

DMARC policy is part of the DNS record for the client’s domain. If Thrive is managing the client’s DNS record, then updating the DMARC policy is within scope for that service. If Thrive is not managing the client’s DNS record, Thrive will provide guidance to the client on recommended DMARC changes, but will leave it to the client IT teams to implement the recommendations.