Protecting your Organisation’s Email Domains and Reputation Protecting your Organisation’s Email Domains and Reputation 

Protecting your Organisation’s Email Domains and Reputation 

With the rise in email-borne phishing attacks, it’s time that you started doing something to protect your organization’s email domains and your organization’s reputation.

By now you should have deployed some form of solution to protect your users when they are targeted by malicious incoming emails. A good example of such a solution is Microsoft Defender for Office 365, but this blog post doesn’t address that threat.  

Spear Phishing  

The specific threat this blog post addresses is one in which your organization is not directly involved, but nonetheless could be hugely impacted. The threat this blog post covers is when a malicious bad actor uses your business’ email domain to send an email to a third party, which could be one of your customers or one of your suppliers. Technically this is very easy to do because when the SMTP standard was first published in the 1980s there was no such concept as malicious emails and so the SMTP protocol doesn’t contain any security features. SMTP, for example, allows any computer to send emails claiming to be from any source address. It wasn’t until 2002 that the basic protection included in the Sender Protection Framework (SPF) specification was initially drafted. A common example of such a security threat is when a malicious bad actor sends one of your customers a phishing email containing an invoice with fake banking details. Yes, your customer could lose money because they pay the wrong bank account, but the actual risk to you is that your business will lose reputation. 

Building your Defences 

So what can you do? The answer is Domain-based Message Authentication, Reporting & Conformance, commonly referred to as DMARC. Your domain’s DMARC policy tells recipient email servers what to do when they receive an email that doesn’t come from a legitimate source of emails for a domain, such as your primary mail service or your MailChimp account. All domains used for email services should have a SPF record to define where emails can originate, and hopefully also have Domain Keys Identified Mail (DKIM) configured to cryptographically sign emails which allow recipient email services to validate the origin of an email. If you don’t have DKIM set up, you should, and quickly. If your email provided doesn’t support DKIM, find another email provider, and quickly. 

The default DMARC policy for a domain is ‘none’, but you can change this policy to either ‘quarantine’ or ‘reject’, meaning recipient email services know which action to apply when they receive an email from your domain that doesn’t appear to come from a legitimate source. Leaving a domain’s DMARC policy set to ‘none’ doesn’t provide you with any protection. 

DMARC Deployment Challenges 

Businesses don’t always know all of their email sources, which adds to the complexity of deployment of DMARC. Typically, a business will leave a domain’s DMARC policy set to ‘none’ and send DMARC failure reports to a DMARC reporting service so they know where unauthorized emails are originating. The DMARC reporting options for a domain are also configured in the domain’s DMARC record along with the DMARC policy. The DMARC reporting options define SMTP addresses where XML reports containing DMARC failures should be sent. If one of the unauthorized sources is legitimate then that source can be authorized using SPF and DKIM, and when you’re happy you’ve authorized all your legitimate email sources then you can switch the DMARC policy to ‘quarantine’, or more preferably ‘reject’. This phase of the deployment is when you find out if emails are coming from a mission-critical system, like your CRM system or website, that hasn’t been configured as a legitimate source of emails for your domain. 

DMARC Adherence 

DMARC protection of a domain can be quite fluid, and that’s because recipient email services don’t always honour DMARC policies. Often an email service will quarantine emails received from non-authorized sources even if the DMARC policy is configured as reject, but at least the emails are quarantined instead of being delivered to users’ inboxes. 

How to Proceed?

Deploying DMARC for your business’ email domain does require some planning and it’s a good idea to enlist help from someone with experience of DMARC deployment, but the result is that you’ve increased the protection of your email service and your business’ reputation. Adding DMARC to your domain also improves your domain’s email deliverability, so you may find that your users’ emails more often get delivered to recipients’ inboxes rather than spam folders. 

Oivan can help you improve your email domain’s security with a simple email deliverability check to give you a clear understanding. The email deliverability check we do for free, and if any remedial actions need to be taken we can help you deploy those changes to protect your email service and protect your business’ reputation. 

Get In Touch

Want to hear more about our services? Let’s talk! Send us a message for more information.

Cybersecurity Services

"*" indicates required fields

This field is for validation purposes and should be left unchanged.