08 Feb What is DMARC, and why do I need to worry about it?
As of March 2023, Microsoft 365 started sending aggregate DMARC reports. This update fixed a blind spot that had existed; previously, where Microsoft didn’t report on DMARC results, you would miss crucial insights and legitimate senders that could then be blocked from sending emails once p=reject was enabled.
Another milestone improvement has now been announced, with Microsoft honouring DMARC policies in M365 and both Google and Yahoo enforcing these policies as of February 2024. Without action, your emails may not reach your intended recipients.
What is DMARC?
Domain-based Message Authentication, Reporting, and Conformance (DMARC) is a critical component of email cybersecurity that greatly reduces an attacker’s ability to get phishing and spoofed email to an end user’s inbox. It’s used by free platforms such as Gmail, and it’s also available in many corporate email filtering cybersecurity solutions. It’s important to understand the way DMARC is set up so that it can be properly implemented. With DMARC an organisation can protect from phishing emails, which are increasingly used to add malware to a network or access security credentials.
SPF and DKIM Integration
DMARC isn’t just one cybersecurity component. It’s a collaboration of several rules that together determine if an email message reaches a user’s inbox. The email administrator determines these sets of rules, but the two main components for inbox filtering is Sender Policy Framework (SPF) and DomainKeys Identified Mail (DKIM). DNS records are also used to determine if an email server is registered and authorised to send email for the organisation.
SPF is a DNS TXT record that indicates the authorised email servers that can send an email on your domain’s behalf. When a recipient email server receives a message with DMARC rules enabled, it looks for the SPF record first. This DNS TXT record should have IP addresses or hostnames registered to send mail. This could be only on-premise email servers or third-party servers such as those used with Google Suite for businesses.
DKIM is a little more involved than SPF. DKIM also requires a TXT record, but this record is the domain’s public key. DKIM implements asymmetric public-private key encryption. With public-private key encryption, a domain’s public key is used to encrypt a message. In the case of DMARC, a signature is encrypted with the public key published on DNS servers and verified at the recipient’s email server using the domain’s private key. Private keys should be protected because an attacker with your private key can decrypt any messages sent using your public key.
When an inbound server receives a message with DKIM, it compares the signature using the published public key with the message decrypted using a newly generated key. If the string result is the same, then the recipient’s email server can confirm that the message was not altered in any way. This also ensures that the sender is truly from the listed domain and not spoofed using a fraudulent sender address.
DMARC Rules
With SPF and DKIM integrated, the administrator can now set up DMARC rules. DMARC rules are also set in DNS. It tells recipient servers to implement DMARC. If no DMARC record is found, then it’s skipped entirely leaving your domain open to spoofing.
The following is an example DMARC TXT record:
v=DMARC1\;p=none\;rua=mailto:admin@yourdomain.com\;ruf=mailto:admin@yourdomain.com\;pct=100
The first part of a DMARC record indicates that DMARC should be applied. This is the “v=DMARC1” section of the record. This section should always be the first part of the rules because it triggers the email system to look further into the record to find DMARC rules.
The “p=none” section tells the server what to do if DMARC records fail. In this example, the system does nothing with the email, but the administrator gets a report on messages that fail DMARC. You can also set this value to “reject” to outright reject the email or “quarantine” to set it aside until an administrator can review it.
The “rua=mailto:admin@yourdomain.com” rule tells the server where to send reports. Reports should go to an administrator to review any failures, especially if you have “p=none” configured. It will help administrators determine if malicious emails could be reaching user inboxes.
DMARC servers aggregate reports for forensics, and “ruf=mailto:admin@yourdomain.com” is the rule that tells the server where to send these reports. These reports are real-time, so they are always available for administrator review.
Most administrators don’t realise the amount of email that gets sent on behalf of the domain, so the “pct=100” rule sets a percentage of emails that will have DMARC rules applied. In this example, 100% of emails will be verified against DMARC rules. This is the typical value, but you might want to lower the percentage if you are testing your new rules especially with the “p=none” value.
DMARC seems complex, but with the right setup, it’s a valuable cybersecurity tool that defends against phishing and malicious email content. With phishing on the rise as one of the most common ways attackers can steal data, it’s important for organisations to implement the right application and rules that stop these messages before they can reach a user’s inbox.
While SPF provides a certain degree of protection against email spoofing, DMARC is far more dependable
Don’t wait – take action and be DMARC compliant today.
Without DMARC, your emails may not reach your intended recipients and your email cybersecurity is at risk.
With DMARC an organisation can protect from phishing emails, which are increasingly used to add malware to a network or access security credentials and reduces an attacker’s ability to get these emails to an end user’s inbox.
Need help with being DMARC compliant? Give us a call today to schedule a chat.
Featured Image Credit – Torsten Dettlaff