Domain-based Message Authentication, Reporting, and Conformance (DMARC) is an email authentication protocol that helps domain owners protect their domains from unauthorized use, such as spoofing and phishing. It builds on existing authentication methods and allows domain owners to publish a clear policy for how receiving mail servers should handle messages that fail authentication. It builds upon two underlying protocols: SPF and DKIM.

At a high level, DMARC answers two questions:

• Is this email legitimately associated with the domain it claims to come from?
• If not, what should the receiving server do about it?

This post explains the essentials of DMARC at a high level and how it works in practice.

SPF is a DNS-based mechanism that lists authorized IP addresses and hostnames allowed to send email on behalf of a domain.

SPF validation is performed against the envelope From address (also known as the Return-Path), which is typicall not displayed to end users by email clients. This address is used by mail servers for bounce and delivery notification messages.

The receiving server checks the SPF record in the sender domain's DNS. If the sending server's IP is not listed, the SPF check fails. SPF frequently fails during email forwarding because the forwarding server's IP address is not authorized in the original sender domain's SPF record.

DKIM provides a cryptographic signature to verify that an email was sent by the domain owner and has not been altered in transit.

Unlike SPF, DKIM is used to sign the message body as well as selected headers. In particular, the From: header is usually included in the signature. While the envelope From and the From: header are usually the same when you send a personal email from your email client, they almost always differ for mails received from mailing lists, automated systems and email marketing campaigns.

DMARC provides a policy layer. It requires Identifier Alignment, meaning that the domain in the From: header must match the domain validated by SPF or DKIM.

In other words, for a messages to pass DMARC, it must satisfy the following two conditions:

1. Authentication: Either SPF or DKIM must pass.
2. Alignment: The domain validated by the passing authentication method must align with the domain in the "From:" header.

Finally, the sender domain owner defines the DMARC policy which specifies what the receiver should do with email messages that fail DMARC for the domain. There are 3 policy levels:

1. none: No action on failure, the message is delivered normally.
2. quarantine: The message is sent to the recipient's spam folder.
3. reject: The message is rejected.

In practice, most mailbox providers do not enforce DMARC policies rigidly, but use this as a signal as part of their spam filtering processes, along with whether SPF and DKIM pass, and many other often proprietary signals.

Implementing DMARC is critical for organizations that want to protect their brand and ensure high deliverability.

From a security perspective, DMARC significantly reduces the risk of phishing attacks that impersonate a legitimate domain. From a deliverability standpoint, many mailbox providers view DMARC as a signal of good sending practices. Domains without DMARC, or with misconfigured policies, are more likely to see their mail filtered or blocked.

DMARC also provides operational insight. Reporting data can reveal misconfigured systems, unauthorized senders, and opportunities to tighten authentication without disrupting legitimate mail.

Email forwarding occurs when a receiving mail server redirects a message to another destination. In this process, the forwarding server becomes the new sending server. This breaks SPF, because the forwarding server’s IP address is not authorized in the original sender’s SPF record. DKIM, however, usually survives forwarding, provided the message is not modified and the sender's DKIM setup is correct.

This creates an obvious problem from a DMARC perspective:

• SPF fails due to the forwarding
• DKIM must pass and be aligned for DMARC to succeed

Unfortunately, not all senders sign their email messages with DKIM, and even when they do, misconfigurations can invalidate the signature. Without a valid DKIM signature, DMARC will fail which increases the likelihood of the receiving mail server rejecting the email message, especially for domains with a "reject" DMARC policy.

As noted above, most email providers do not apply DMARC policies literally. In addition, well-designed forwarding services mitigate these issues using the following two techniques:

1. Sender Rewriting Scheme (SRS): Rewrites the envelope From to ensure that the forwarded emails pass SPF checks. This helps somewhat, but does not provide DMARC alignment.
2. Authenticated Received Chain (ARC): Adds cryptographically signed headers that preserve the authentication results (SPF, DKIM, DMARC) observed before forwarding. Receiving mail servers can use ARC to make more informed decisions.

DMARC is an important component of modern email authentication that provides a clear framework for validating sender identity, protecting domains from abuse, and improving email deliverability.

Since February 2024, both Google and Yahoo require DMARC for "bulk" senders, and recommend that all senders set up DMARC and that forwarders employ ARC. See Google's email sender guidelines and Yahoo's Sender Requirements & Recommendations for details.

For organizations that rely on email, DMARC is no longer optional: it is an essential part of a trustworthy email ecosystem.