DMARC and email security: why you shouldn't do without it

The correct cooperation between SPF, DKIM and DMARC explained

Michael Hudak

February 15, 2025

What is DMARC?

Why DMARC is so important

How DMARC works

Step-by-step guide to implementation

Conclusion

Abstract

Email security is essential for companies and organizations regardless of their size. Phishing attacks and spoofing attempts can lead to data loss, reputational damage and significant financial losses. One of the most effective measures to counter such risks is DMARC. In this blog article, we explain what DMARC is, how it works and how you can implement it to protect your email communication.

DMARC stands for "Domain-based Message Authentication, Reporting and Conformance" and is a mechanism that enables email operators to use and extend existing authentication and policy procedures such as SPF (Sender Policy Framework) and DKIM (DomainKeys Identified Mail). The aim is to support email senders and recipients in the fight against spam, phishing and spoofing (the falsification of a sender address).

SPF and DKIM are considered essential building blocks of email authentication, as they provide the recipient with reliable information about the domain from which the email originated. These technologies determine how authorized email servers are identified (SPF) and whether a message has remained unchanged in transit (DKIM). However, for a long time there was no universal and easily accessible way to both publish the desired policies of a domain and receive feedback on authentication results and the handling of incoming emails. Companies and organizations that had already set up SPF and DKIM found it difficult to find out whether their defensive measures were actually working.

In the past, individual senders and recipients therefore often made their own, time-consuming arrangements to coordinate guidelines, delivery directions and reporting. However, this approach was very individual and required intensive manual coordination. In addition, it could not be easily scaled to large user and customer groups.

This is where DMARC comes in: It defines a standardized procedure by which domain owners (e.g. companies or organizations) can provide the following information to the mail servers on the recipient side:

• How recipients should deal with messages that appear to come from their domain but cannot be authenticated.
• How email providers should report on authentication results.

DMARC thus builds on SPF and DKIM, but supplements them with additional mechanisms for comprehensive feedback and binding guidelines. In practice, this means the following:

• The domain owner publishes a specific DMARC record via DNS, which states which policy (e.g. "do nothing", "treat as spam" or "reject") should be applied to messages that are not clearly authenticated.
• For each incoming email, the receiving server checks whether the domain used in the sender address also matches in SPF and DKIM. If necessary, the specified guidelines (policy) are applied.
• The recipient regularly sends reports back to the address stored in the DMARC record. This allows domain owners to track how many mails actually exist and how many fail due to errors or manipulation attempts.

Unlike older methods, such as ADSP, the authentication technology (SPF or DKIM) is not permanently linked to a specific policy, but can be used flexibly. At the same time, DMARC cannot function without an existing SPF or DKIM configuration.

Alignment plays an important role here, as it checks that the two sending addresses in an email message match. These two addresses are not checked against each other in the individual authentication procedures and can therefore have different domains. For a successful alignment, there must either be an exact match of the domain (e.g. example.com = example.com) or a hierarchy match between a superordinate and a subordinate domain (e.g. example.com and mail.example.com). This principle of alignment ensures that the displayed sender address matches the actual sender address of the email, which is an effective means of preventing domain spoofing.

DMARC uses this alignment check to ensure that the email is authenticated by both SPF and DKIM. If at least one of the two methods is successful, the email will not be blocked unless the sender's policy requires stricter measures. This flexibility makes DMARC a robust and reliable tool in the context of email sender authentication.

For domain owners, this has the advantage that DMARC enables a more complete overview of email traffic and provides feedback that was previously hardly available. For example, unauthorized email sources can be easily identified, incorrectly configured servers can be corrected and phishing attacks can be detected at an early stage. At the same time, however, companies and organizations must bear in mind that strict DMARC policies may block legitimate but incorrectly configured email systems. Gradual implementation and testing is therefore crucial to avoid unintentionally rejecting genuine emails.

Overall, DMARC combines the two established authentication methods SPF and DKIM under a standardized policy system with a feedback loop. This approach improves trust in email communication and effectively protects senders and recipients against domain abuse, provided DMARC is set up correctly and actively monitored.

DMARC is a crucial enhancement to existing email authentication methods because it allows domain owners to set clear policies for dealing with unauthenticated messages while receiving feedback on the actual enforcement of these policies. In this way, the proportion of successfully delivered spoofed emails can be significantly reduced, which is particularly helpful against phishing attacks where fraudsters send emails under the name of a supposedly trusted domain. By linking SPF and DKIM, senders can also better check to what extent their authentication measures are effective and whether emails that actually originate from them are reliably delivered. DMARC thus provides senders with a tool to monitor the authentication of their mail traffic on a broad basis and, if necessary, to react if new or unknown senders pretend to be part of their own domain.

An important objective of DMARC is to keep the implementation effort for both senders and recipients as low as possible and at the same time not to impair the smooth transport of legitimate emails. Especially in an infrastructure as widespread as the current SMTP e-mail system, scalability is essential, which is why DMARC deliberately dispenses with additional intermediate instances or complex agreements between senders and recipients. Instead, it uses DNS as a central medium to determine how to deal with unauthenticated messages and where to send detailed reports on email volumes. Thanks to this clear and standardized approach, domain owners can quickly identify whether their authentication is effective, where there may be configuration gaps or whether criminal actors are misusing the domain for fraudulent purposes.

At the same time, it should be noted that DMARC only addresses a specific type of abuse and does not solve all forms of email fraud. For example, the detection of emails that use a visually similar but technically different domain does not fall within the scope of this procedure. Similarly, "display name" manipulation, where the sender's name is used instead of the actual sender domain, is not covered. The content analysis on which some spam filters are based is also not part of the DMARC concept. Nevertheless, the widespread introduction of DMARC is a decisive step towards making email traffic more secure overall and significantly reducing the effectiveness of phishing attacks.

DMARC is based on the two existing SPF and DKIM procedures and combines them at a central point by comparing the domain determined during these checks with the sender address. For an incoming email, the receiving server first checks whether the domain that can be seen in the visible sender field matches the authenticated information from SPF or DKIM. This match is known as domain alignment. In the case of SPF, the server checks whether the domain in the SMTP envelope matches the email sender in the From field, while DKIM checks whether the signature belongs to a domain that in turn matches the domain specified in the From field.

If the server detects that the domain specified in the From field is not correctly connected to SPF or DKIM, DMARC decides which policy should be applied. This policy is defined by the domain and is published via DNS. With this policy stored in the DNS, the domain owner determines whether an unauthenticated email should be delivered, marked as spam or completely rejected. At the same time, the DMARC settings anchored in the DNS allow the configuration of reports that provide information on how often messages were successfully checked or where authentication errors occurred.

Recipient servers send these reports to a previously stored e-mail address specified by the domain owner. This creates a transparent overview that makes it possible to track whether and how messages actually reach the recipients and which emails are blocked on the way there or filed in the spam folder. This feedback enables companies to quickly identify any configuration errors and take corrective action if necessary before legitimate emails are incorrectly rejected. This close integration of SPF, DKIM and DMARC, coupled with the ability to provide recipients with clear instructions and at the same time receive valuable feedback on the effectiveness of these instructions, forms the core of the DMARC mechanism and makes it one of the most important foundations for secure email communication.

A central component of DMARC is the concept of identifier alignment, which ensures that the origin domain of the email (as seen by the recipient) matches the domain used in the authentication process (as seen by the server). This section uses three examples based on SPF to explain how the mechanism works in practice. Note that the mechanism also works in the same way for DKIM. For the sake of simplicity, it is assumed in all examples that the SPF validation provides a positive result. In addition, some header fields and the message content are removed, which are not relevant in this context.

The following expressions are used so that the identifiers can be understood correctly:

• The identifier RFC 5322.From refers to the specification in RFC 5322, which defines the structure and requirements for the "From" field in email messages. RFC 5322 describes how email headers should be formatted, including the "From" header, to ensure that sender addresses are correctly structured and interpreted by email systems. This RFC is critical to maintaining the consistency and compatibility of email communications. This identifier can also be seen by the email user as the sender address.
• The identifier RFC 5321.MAIL FROM refers to the MAIL FROM command in the SMTP protocol, which is standardized in RFC 5321. This command is used to define the sender address of an e-mail message. When sending an e-mail, the client sends the MAIL FROM command to the server to specify the sender address. The server then checks whether it can accept the e-mail. Although there are manipulations such as spoofing, the MAIL FROM command is a central part of the email sending process. However, a user does not normally see this address in their mail service.

Example 1: SPF alignment (exact match)

MAIL FROM: <sender@example.com>
---
From: sender@example.com
Date: Fri, Feb 15 2002 16:54:30 -0800
To: receiver@example.org
Subject: here's a sample
                        

In this example, the email fields RFC 5321.MAIL FROM and RFC 5322.From share the same DNS domain example.com. This is an exact alignment as both identifiers match. DMARC considers this a successful alignment and the message is considered authentic.

Example 2: SPF alignment (domain match)

MAIL FROM: <sender@child.example.com>
---
From: sender@example.com
Date: Fri, Feb 15 2002 16:54:30 -0800
To: receiver@example.org
Subject: here's a sample
                        

Here, the RFC 5321.MAIL FROM is a subdomain of the RFC 5322.From domain (example.com). This relationship is referred to as "parent domain alignment". Whether this situation develops into a successful alignment depends on the DMARC policy of the domain owner:

• Relaxed mode "relaxed" (aspf=r): In this case, only the domain must match, possible subdomains are ignored. The result is positive.
• Strict mode "strict" (aspf=s): In this case, the host names must match, so the result is negative.

Example 3: SPF not aligned

MAIL FROM: <sender@example.net>
---
From: sender@child.example.com
Date: Fri, Feb 15 2002 16:54:30 -0800
To: receiver@example.org
Subject: here's a sample
                        

In this case, the RFC 5321.MAIL FROM domain (example.net) is neither the same nor a main domain of the RFC 5322.Fromdomain (child.example.com). As a result, the identifiers are not aligned. DMARC considers this an error and the message could be filtered or rejected depending on the DMARC policy of the domain owner.

1. Testing and setting up SPF and DKIM

• Make sure that a valid SPF entry exists for your domain that lists all authorized e-mail servers.
• Activate DKIM by storing public DKIM keys in the DNS and using private keys on the mail server for signing.

2. Create DMARC entry

• Create a TXT entry with the name _dmarc.yourdomain.com in the DNS of your domain.
• This entry contains the DMARC policy string, for example: v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com; ruf=mailto:dmarc-failures@yourdomain.com;

The most important components are

• v=DMARC1: Version of DMARC.
• p=: The desired DMARC policy (none, quarantine or reject).
• rua=: Address for aggregate reports. Here you can obtain statistical summaries of e-mails.
• ruf=: Address for forensic reports. Detailed information on failed emails is reported here.

3. Test phase with "p=none"

• Always start with the none policy to avoid misconfigurations.
• Analyze the reports you receive (aggregate reports) and correct your SPF/DKIM settings if necessary.

4. Upgrading of the directive

• If you are sure that SPF and DKIM work reliably, you can increase the policy to quarantine or even reject.
• It is only at this level that DMRAC becomes active and can have an influence.
• Continue to monitor the reports to ensure that legitimate emails are not blocked.

DMARC is an essential component of modern email security. While SPF and DKIM already provide a certain level of protection, DMARC ensures that these mechanisms are applied consistently and that attempts to defraud your domain can be detected and stopped. Even if it takes a certain amount of effort to set up and continuously monitor, it is worth it in the long term to protect your customers, business partners and your brand.

It is best to start with a test phase (p=none), analyze your reports and then gradually increase the level of protection. In this way, you can ensure that legitimate communication is not blocked by mistake and that you can react promptly to possible configuration errors.

With DMARC you set an important milestone to successfully fend off spoofing and phishing attacks - a clear signal to potential attackers that your domain is protected and a reassuring feeling for all those who trust you.

Links

Microsoft documentation for setting up DMARC: Set up DMARC to validate the From address domain for senders in Microsoft 365