If you’ve ever received an email that appeared to come from your bank, PayPal or some other reputable company, only to discover that it was actually a phishing attempt, you might have wondered how the sender managed to make their email address look so convincing. Unfortunately, one of the fundamental problems with email is that the underlying technology was developed long before spam, phishing and online fraud became the enormous problems they are today. As a result, it’s surprisingly easy to send an email that appears to originate from a domain you don’t actually own, unless the receiving email provider has appropriate security measures in place.
Fortunately, there are several technologies designed to prevent this, one of which is something called DMARC. Although it’s been around for more than a decade, it’s becoming increasingly important for businesses that want to protect their domains against impersonation and ensure that legitimate emails are delivered successfully. However, configuring it incorrectly can cause some fairly serious problems, particularly if your business uses several different systems to send emails.
What Exactly Is DMARC?
DMARC stands for Domain-based Message Authentication, Reporting and Conformance, which is a rather complicated name for something with a relatively straightforward purpose. Essentially, it allows the owner of a domain to tell receiving email servers how to handle messages that claim to come from that domain but fail certain authentication checks.
For example, imagine somebody attempts to send a fraudulent email pretending to be from accounts@example.com. Without appropriate protection, the recipient’s email system might have difficulty determining whether the message genuinely originated from the company that owns example.com. DMARC helps address this by allowing the domain owner to publish a policy specifying what should happen when an email fails authentication, potentially instructing the receiving server to reject the message entirely.
However, DMARC doesn’t actually authenticate emails on its own. Instead, it works alongside two existing technologies called SPF and DKIM, which you’ll need to understand before implementing it properly.
What’s the Difference Between SPF, DKIM and DMARC?
SPF, or Sender Policy Framework, allows a domain owner to specify which servers are authorised to send emails on behalf of a particular domain. This information is published through DNS records, which receiving email servers can check to determine whether an incoming message originated from an authorised source.
DKIM, or DomainKeys Identified Mail, works rather differently. Instead of checking which server sent the message, it uses a digital signature that allows the receiving server to verify that the email was signed by a particular domain and that certain parts of the message haven’t been modified since it was signed.
DMARC builds upon these technologies by checking whether the domain authenticated through SPF or DKIM matches, or ‘aligns’ with, the domain displayed in the email’s From address. An email only needs one of these methods to pass with the correct alignment to satisfy DMARC, although I’d generally recommend configuring both SPF and DKIM wherever possible.
This distinction is important because simply having an SPF record doesn’t necessarily mean that your emails will pass DMARC. The domain being authenticated also needs to align with the address your recipients actually see.
Why Can DMARC Cause Problems?
This is where things become a little more complicated, particularly for businesses using services such as Mailchimp, Microsoft 365 or other third-party email platforms.
Let’s say your company uses Microsoft 365 for normal business emails, but also sends newsletters through Mailchimp and automated notifications through its website. Each of these systems might be configured to send messages using an address ending in your company’s domain name, but they won’t necessarily authenticate those messages in the same way.
If you introduce a strict DMARC policy without checking these services first, you could discover that legitimate messages are suddenly being rejected or sent to recipients’ spam folders.
I’ve come across situations where businesses have configured email authentication without fully understanding how many different systems are sending messages on their behalf. It’s surprisingly easy to overlook something like an enquiry form, CRM system or automated invoice platform, particularly if it was configured several years ago by somebody who no longer works for the company.
The result can be rather frustrating, because everything might appear to be working correctly from the sending system’s perspective, while the intended recipient never actually receives the message.
How Do You Set Up DMARC?
Fortunately, you don’t need to introduce the strictest possible policy immediately. In fact, I’d strongly recommend against doing so unless you’re already confident that all your legitimate email services are configured correctly.
DMARC is controlled through a DNS TXT record, usually created at _dmarc.yourdomain.co.uk. A relatively straightforward starting configuration might look something like this:
v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.co.uk
The important part here is p=none, which tells receiving email servers that you’re not requesting any special action against messages that fail DMARC authentication. Instead, you’re effectively placing your domain into a monitoring mode, allowing you to see which systems are sending emails using your domain and whether they’re passing the required checks.
The rua value specifies where aggregate authentication reports should be sent. These reports are generally produced in XML format, which isn’t particularly convenient to read manually, although there are services available that can process them into more understandable reports.
Once you’ve established which systems are legitimately sending emails, you can check that SPF and DKIM are configured correctly and resolve any authentication failures before considering a stricter policy.
Moving from Monitoring to Enforcement
DMARC supports three main policies: none, quarantine and reject. As we’ve already established, none is primarily used for monitoring, while quarantine requests that receiving email servers treat messages failing authentication as suspicious, typically placing them into a spam or junk folder. The strictest option, reject, requests that those messages be rejected altogether.
Personally, I’d recommend starting with p=none and reviewing the reports for several weeks before making any changes. Once you’re confident that legitimate emails are passing authentication, you can consider moving to p=quarantine and eventually p=reject.
The UK’s National Cyber Security Centre recommends a similarly gradual approach, allowing organisations to identify legitimate sending services before introducing policies that could interfere with email delivery.
It’s also worth remembering that DMARC doesn’t eliminate every type of phishing. Somebody could still register a domain that looks similar to yours, for example, and use that to impersonate your business. What DMARC does is make it considerably more difficult for somebody to successfully send unauthorised emails using your actual domain name.
Is It Worth the Effort?
I think so, particularly if your business relies heavily on email for communicating with customers. DMARC can help protect your domain from being impersonated, while also providing useful information about the various systems sending emails on your behalf.
However, I wouldn’t recommend simply copying a strict DMARC record from an online tutorial and assuming that everything will work correctly. Take the time to understand your existing email configuration, identify any third-party services and monitor the results before introducing stricter restrictions.
For smaller businesses using a single email provider, the process might be relatively straightforward. For larger organisations with multiple websites, CRM systems and marketing platforms, it can require considerably more investigation.
Ultimately, DMARC is one of those technical improvements that most people will never notice when it’s working properly, but can cause an enormous amount of frustration when it’s configured incorrectly.
Given how much businesses depend on email, I’d suggest taking the time to get it right.