Hubbry Logo
DMARCDMARCMain
Open search
DMARC
Community hub
DMARC
logo
7 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
Contribute something
DMARC
DMARC
DMARC
View on Wikipedia
from Wikipedia

Domain-based Message Authentication, Reporting and Conformance (DMARC) is an email authentication protocol. It is designed to give email domain owners the ability to protect their domain from unauthorized use, commonly known as email spoofing. The purpose and primary outcome of implementing DMARC is to protect a domain from being used in business email compromise attacks, phishing email and email scams.

Once the DMARC DNS entry is published, any receiving email server can authenticate the incoming email based on the instructions published by the domain owner within the DNS entry. If the email passes the authentication, it will be delivered and can be trusted. If the email fails the check, depending on the instructions held within the DMARC record the email could be delivered, quarantined or rejected.

DMARC extends two existing email authentication mechanisms, Sender Policy Framework (SPF) and DomainKeys Identified Mail (DKIM). It allows the administrative owner of a domain to publish a policy in their DNS records to specify how to check the From: field presented to end users and how the receiver should deal with failures, and it provides a reporting mechanism for actions performed under those policies.

DMARC is defined in the Internet Engineering Task Force's published document RFC 7489,[1] dated March 2015, as "Informational".[2]

Overview

[edit]

A DMARC policy allows a sender's domain to indicate that their email messages are protected by SPF and/or DKIM, and tells a receiver what to do if neither of those authentication methods passes – such as to reject the message or quarantine it. The policy can also specify how an email receiver can report back to the sender's domain about messages that pass and/or fail.[3]

These policies are published in the public Domain Name System (DNS) as text TXT records.

DMARC does not directly address whether or not an email is spam or otherwise fraudulent. Instead, DMARC can require that a message not only pass DKIM or SPF validation, but that it also pass § Alignment. Under DMARC a message can fail even if it passes SPF or DKIM but fails alignment.[4]

Setting up DMARC may improve the deliverability of messages from legitimate senders.[5]

Alignment

[edit]

DMARC operates by checking that the domain in the message's From: field (also called "RFC5322.From"[2]) is "aligned" with other authenticated domain names. If either SPF (specified using the aspf field) or DKIM (specified using the adkim field) alignment checks pass, then the DMARC alignment test passes.

Alignment may be specified as strict or relaxed. For strict alignment, the domain names must be identical. For relaxed alignment, the top-level "Organizational Domain" must match. The Organizational Domain used to be found by checking a list of public DNS suffixes. The upcoming spec instead specifies a Tree Walk through the parent domains. So, for example, "a.b.c.d.example.com.au" and "example.com.au" have the same Organizational Domain, because _dmarc.example.com.au is the only defined DMARC record among all the subdomains involved, including _dmarc.au. As this allows domain owners to define domain roles, it is deemed to be more accurate than the Public Suffix List.[6]

Like SPF and DKIM, DMARC uses the concept of a domain owner, the entity or entities authorized to make changes to a given DNS domain.

SPF checks that the IP address of the sending server is authorized by the owner of the domain that appears in the SMTP MAIL FROM command. (The email address in MAIL FROM is also called the bounce address, envelope-from or RFC5321.MailFrom.) In addition to requiring that the SPF check passes, DMARC checks that RFC5321.MailFrom aligns with 5322.From.[2]

DKIM allows parts of an email message to be cryptographically signed, and the signature must cover the From field. Within the DKIM-Signature mail header, the d= (domain) and s= (selector) tags specify where in DNS to retrieve the public key for the signature. A valid signature proves that the signer is a domain owner, and that the From field hasn't been modified since the signature was applied. There may be several DKIM signatures on an email message; DMARC requires one valid signature where the domain in the d= tag aligns with the sender's domain stated in the From: header field.

DNS record

[edit]

DMARC records are published in DNS with a subdomain label _dmarc, for example _dmarc.example.com. Compare this to SPF at example.com, and DKIM at selector._domainkey.example.com.

The content of the TXT resource record consists of name=value tags, separated by semicolons, similar to SPF and DKIM.

The available tags are:[7]

  • adkim, DKIM alignment mode (default r for relaxed, alternatively s for strict)
  • aspf, SPF alignment mode (default r for relaxed, alternatively s for strict)
  • fo, failure reporting options (default 0, alternatively 1, d, or s)
  • p, policy (see below),
  • pct, percent of "bad" email on which to apply the policy (default 100)
  • rf, format for message-specific failure reports
  • ri, requested interval between aggregate reports
  • rua, URI to send aggregate reports to
  • ruf, URI to send failure/forensic reports to
  • sp, subdomain policy (default same as p),
  • v, version,

For example: 

"v=DMARC1;p=none;sp=quarantine;pct=100;rua=mailto:dmarcreports@example.com;"

In this example, the entity controlling the example.com DNS domain intends to monitor SPF and/or DKIM failure rates and doesn't expect email to be sent from subdomains of example.com. Note that a subdomain can publish its own DMARC record; receivers must check it out before falling back to the organizational domain record.

Step by step adoption

[edit]

The protocol provides for various ratchets, or transitional states, to allow mail admins to gradually transition from not implementing DMARC at all, all the way through to an unyielding setup.[8][9][10] The concept of stepwise adoption assumes that the goal of DMARC is the strongest setting, which is not the case for all domains. Regardless of intent, these mechanisms allow for greater flexibility.

Policy

[edit]

First and foremost, there are three policies:

  • none is the entry level policy. No special treatment is required by receivers, but enables a domain to receive feedback reports.
  • quarantine asks receivers to treat messages that fail DMARC check with suspicion. Different receivers have different means to implement that, for example flag messages or deliver them in the spam folder.
  • reject asks receivers to outright reject messages that fail DMARC check.

The policy published can be mitigated by applying it to only a percentage of the messages that fail DMARC check. Receivers are asked to select the given percentage of messages by a simple Bernoulli sampling algorithm. The rest of the messages should undergo the lower policy; that is, none if p=quarantine, quarantine if p=reject. If not specified, pct defaults to 100% of messages. The case p=quarantine; pct=0; is being used to force mailing list managers to rewrite the From: field, as some don't do so when p=none.[11]

Finally, the subdomain policy, sp= and the newly added no-domain policy, np=[12] allow tweaking the policy for specific subdomains.

Reports

[edit]

DMARC is capable of producing two separate types of reports. Aggregate reports are sent to the address specified following the rua. Forensic reports are emailed to the address following the ruf tag. These mail addresses must be specified in URI mailto format (e.g. mailto:worker@example.net ). Multiple reporting addresses are valid and must each be in full URI format, separated by a comma.[13]

Target email addresses can belong to external domains. In that case, the target domain has to set up a DMARC record to say it agrees to receive them, otherwise it would be possible to exploit reporting for spam amplification. For example, say receiver.example receives a mail message From: someone@sender.example and wishes to report it. If it finds ruf=mailto:some-id@thirdparty.example, it looks for a confirming DNS record in the namespace administered by the target, like this: 

sender.example._report._dmarc.thirdparty.example IN TXT "v=DMARC1;"

Aggregate reports

[edit]

Aggregate Reports are sent as XML files, typically once per day. The subject mentions the "Report Domain", which indicates the DNS domain name about which the report was generated, and the "Submitter", which is the entity issuing the report. The payload is in an attachment with a long filename consisting of bang-separated elements such as the report-issuing receiver, the begin and end epochs of the reported period as Unix-style time stamps, an optional unique identifier and an extension which depends on the possible compression (used to be .zip).[14]

For example: example.com!example.org!1475712000!1475798400.xml.gz.

The XML content consists of a header, containing the policy on which the report is based and report metadata, followed by a number of records. Records can be put in a database as a relation and viewed in a tabular form. The XML schema is defined in Appendix C of specifications[15] and a raw record is exemplified in dmarc.org.[16] Here we stick with a relational example, which better conveys the nature of the data. DMARC records can also be directly transformed in HTML by applying an XSL stylesheet.

DMARC rows of an aggregate record shown in tabular form
Source IP Count Disposition SPF DKIM Header from SPF domain (result) DKIM domain (result)  
192.0.2.1 12 none  Pass  Pass example.org example.org ( Pass) example.org ( Pass)  
192.0.2.1 1 none  Pass ✗ Fail example.org example.org ( Pass) example.org (✗ Fail)  
192.0.2.28 42 none ✗ Fail  Pass example.org example.org (✗ Fail) example.org ( Pass) forwarder.example ( Pass)
192.0.2.82 21 none ✗ Fail ✗ Fail example.org discusslist.example ( Pass) example.org (✗ Fail) discusslist.example ( Pass)
...

Rows are grouped by source IP and authentication results, passing just the count of each group. The leftmost result columns, labelled SPF and DKIM show DMARC-wise results, either pass or fail, taking alignment into account. The rightmost ones, with similar labels, show the name of the domain which claims to participate in the sending of the message and (in parentheses) the authentication status of that claim according to the original protocol, SPF or DKIM, regardless of Identifier Alignment. On the right side, SPF can appear at most twice, once for the Return-Path: test and once for the HELO test; DKIM can appear once for each signature present in the message. In the example, the first row represents the main mail flow from example.org, and the second row is a DKIM glitch, such as signature breakage due to a minor alteration in transit. The third and fourth rows show typical failures modes of a forwarder and a mailing list, respectively. DMARC authentication failed for the last row only; it could have affected the message disposition if example.org had specified a strict policy.

The disposition reflects the policy published actually applied to the messages, none, quarantine, or reject. Along with it, not shown in the table, DMARC provides for a policy override. Some reasons why a receiver can apply a policy different from the one requested are already provided for by the specification:

forwarded
while keeping the same bounce address, usually doesn't break DKIM,
sampled out
because a sender can choose to apply the policy to a percentage of messages only,
trusted forwarder
the message arrived from a locally known source
mailing list
the receiver heuristically determined that the message arrived from a mailing list,
local policy
receivers are obviously free to apply the policy they like, it is just cool to let senders know,
other
if none of the above applies, a comment field allows to say more.

Forensic reports

[edit]

Forensic Reports, also known as Failure Reports, are generated in real time and consist of redacted copies of individual messages that failed SPF, DKIM or both based upon what value is specified in the fo tag. Their format, an extension of Abuse Reporting Format, resembles that of regular bounces in that they contain either a "message/rfc822" or a "text/rfc822-headers".

Forensic Reports also contain the following:

  • Source of Sending IP Address
  • From email address
  • Recipient email address
  • Email subject line
  • SPF and DKIM authentication results
  • Received time
  • Email message headers which include the sending host, email message ID, DKIM signature, and any other custom header information.[17]

Compatibility

[edit]

Forwarders

[edit]

There are several different types of email forwarding, some of which may break SPF.[18] This is one of the reasons why email forwarding can affect DMARC authentication results.[19]

Mailing lists

[edit]

Mailing lists are a frequent cause of legitimate breakage of the original author's domain DKIM signature, for example by adding a prefix to the subject header. A number of workarounds are possible,[20][21] and mailing list software packages are working on solutions.[22]

Turn off all message modifications

[edit]

This workaround keeps the standard mailing list workflow, and is adopted by several large mailing list operators, but precludes the list adding footers and subject prefixes.[23] This requires careful configuration of mailing software to make sure signed headers are not reordered or modified. A misconfigured email server may put List-id in its DKIM of messages sent to a mailing list, and then the list operator is forced to reject it or do From: rewriting.

From: rewriting

[edit]

One of the most popular and least intrusive workarounds consists of rewriting the From: header field. The original author's address can then be added to the Reply-To: field.[24] Rewriting can range from just appending .INVALID[note 1] to the domain name, to allocating a temporary user ID where a modified version of the user's address is used, or an opaque ID is used, which keeps the user's "real" email address private from the list. In addition, the display name can be changed so as to show both the author and the list (or list operator).[25] Those examples would result, respectively, in one of the following: 

From: John Doe <user@example.com.INVALID>
From: John Doe <user@example.com.dmarc.fail>
From: John Doe <243576@mailinglist.example.org>
From: John Doe via MailingList <list@mailinglist.example.org>
Reply-To: John Doe <user@example.com>

The last line, Reply-To:, has to be designed in order to accommodate reply-to-author functionality, in which case reply-to-list functionality is covered by the preceding change in the From: header field. That way, the original meaning of those fields is reversed.

Altering the author is not fair in general, and can break the expected relationship between meaning and appearance of that datum. It also breaks automated use of it. There are communities which use mailing lists to coordinate their work, and deploy tools which use the From: field to attribute authorship to attachments.[26]

Other workarounds

[edit]

Wrapping the message works nicely, for those who use an email client which understands wrapped messages. Not doing any change is perhaps the most obvious solution, except that they seem to be legally required in some countries, and that routinely losing SPF authentication may render overall authentication more fragile.[27]

Sender field

[edit]

Making changes to the From: header field to pass DKIM alignment may bring the message out of compliance with RFC 5322 section 3.6.2: "The 'From:' field specifies the author(s) of the message, that is, the mailbox(es) of the person(s) or system(s) responsible for the writing of the message." Mailbox refers to the author's email address. The Sender: header is available to indicate that an email was sent on behalf of another party, but DMARC only checks policy for the From domain and ignores the Sender domain.[note 2]

Both ADSP and DMARC[4] reject using the Sender field on the non-technical basis that many user agents do not display this to the recipient.

History

[edit]

A draft DMARC specification has been maintained since 30 January 2012.[28]

In October 2013, GNU Mailman 2.1.16 was released with options to handle posters from a domain with the DMARC policy of p=reject.[22] The change tried to anticipate the interoperability issues expected in case restrictive policies were applied to domains with human users (as opposed to purely transactional mail domains).

In April 2014, Yahoo changed its DMARC policy to p=reject, thereby causing misbehavior in several mailing lists.[29][30] A few days later, AOL also changed its DMARC policy to p=reject.[31] Those moves resulted in a significant amount of disruption, and those mailbox providers have been accused of forcing the costs of their own security failures onto third parties.[32] As of 2020, the FAQ in the official DMARC wiki contains several suggestions for mailing lists to handle messages from a domain with a strict DMARC policy,[33] of which the most widely implemented is the mailing list changing the “From” header to an address in its own domain.

An IETF working group was formed in August 2014 in order to address DMARC issues, starting from interoperability concerns and possibly continuing with a revised standard specification and documentation.[34] Meanwhile, the existing DMARC specification had reached an editorial state agreed upon and implemented by many. It was published in March 2015 on the Independent Submission stream in the "Informational" (non-standard) category as RFC 7489.[35]

In March 2017, the Federal Trade Commission published a study on DMARC usage by businesses.[36] Out of 569 businesses, the study found about a third implemented any DMARC configuration, fewer than 10% used DMARC to instruct servers to reject unauthenticated messages, and a majority had implemented SPF.

Contributors

[edit]

The contributors of the DMARC specification include:[37][38]

Commercial services

[edit]

Popular services that perform DMARC analysis and/or record validation include Red Sift, Valimail, dmarcian, DMARC Advisor and EasyDmarc and Cloudflare.[43]

See also

[edit]

Notes

[edit]

References

[edit]
[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

DMARC

View on Grokipedia
from Grokipedia
DMARC, or Domain-based Message Authentication, Reporting, and Conformance, is an protocol designed to protect domain owners from unauthorized use of their domain in communications, such as spoofing and attacks. It builds upon two foundational standards—Sender Policy Framework (SPF), which verifies the sending IP address against authorized mail servers, and DomainKeys Identified Mail (DKIM), which uses cryptographic signatures to validate message integrity and origin—by aligning these mechanisms with the domain in the "From:" header and allowing domain owners to publish DNS-based policies specifying how receiving servers should handle messages that fail . Additionally, DMARC provides reporting features, including aggregate reports on volume and results as well as forensic reports on individual messages, enabling domain owners to monitor and refine their ecosystem. Developed collaboratively by major technology companies including , , Yahoo, and starting in 2010, DMARC was formally introduced as an in 2012 to address limitations in SPF and DKIM, such as their inability to enforce domain-level policies or provide unified reporting. The protocol is specified in RFC 7489, an Informational document published by the (IETF) on March 18, 2015, which defines its core mechanisms for policy advertisement, validation, and feedback. An updated specification known as DMARCbis is in the final stages of development as a Proposed Standard by the IETF, expected to be published soon. Key policy options include "none" for monitoring without action, "" to treat suspicious emails as potential spam, and "reject" to block unauthenticated messages outright, giving domain owners granular control over enforcement. As of mid-2025, DMARC adoption has grown significantly, with approximately 18.2% of analyzed domains (from a sample of 10 million) implementing a valid DMARC record, though only about 10.6% enforce or reject policies, highlighting ongoing challenges in full deployment. This increase—up roughly 75% from prior years—reflects mandates from governments and organizations, such as U.S. federal agencies requiring DMARC for enhanced , and its proven effectiveness in reducing by up to 90% through spoofing prevention. Despite widespread recognition, with over 66% of senders aware of complementary SPF and DKIM usage, barriers like configuration complexity persist, underscoring DMARC's role as a critical yet evolving layer in the stack.

Introduction

Definition and Purpose

Domain-based Message Authentication, Reporting, and Conformance (DMARC) is a scalable protocol that enables domain owners to express domain-level policies for message validation, disposition, and reporting when emails fail authentication checks based on underlying mechanisms like SPF and DKIM. Specified in RFC 7489 published in March 2015, DMARC builds on these foundational protocols by allowing organizations to publish DNS records that instruct receiving mail servers on how to handle messages purporting to originate from their domain but lacking proper authentication. The primary purpose of DMARC is to protect domains from unauthorized use, particularly in preventing attacks, business email compromise (BEC), and impersonation by enabling domain owners to declare specific actions—such as monitoring, quarantining, or rejecting—unauthenticated messages. By requiring alignment between the domain in the message's "From" header and the authenticated domains from SPF or DKIM, DMARC ensures that only legitimate senders can successfully deliver on behalf of the domain, thereby reducing the risk of spoofing where attackers forge sender addresses to deceive recipients. DMARC provides key benefits including enhanced visibility into the ecosystem through aggregate and forensic reports that detail outcomes and potential abuse, which helps domain owners monitor and refine their practices. These reports support by allowing organizations to identify and address unauthorized usage promptly, ultimately improving deliverability and trust in legitimate communications. Historically, DMARC emerged in 2011 from collaborative efforts among major senders and receivers to address the limitations of SPF and DKIM alone, such as the lack of unified and reporting at scale, leading to its initial specification in 2012.

Relationship to SPF and DKIM

The Sender Policy Framework (SPF) is an email authentication protocol that allows domain owners to specify, via DNS TXT records, which mail servers are authorized to send on behalf of their domain. It verifies the sending against these authorized hosts during SMTP transactions, returning results such as "pass" or "fail" to indicate whether the sender is legitimate. DomainKeys Identified Mail (DKIM) provides a mechanism for through cryptographic signatures that assert responsibility for a by its originating domain. Senders apply a private key to sign selected headers and the message body, producing a hash that receivers verify using the corresponding public key published in the signer's DNS records, thereby confirming message integrity and origin without relying on envelope information. DMARC builds upon SPF and DKIM by requiring that at least one of these mechanisms produces a "pass" result, with the authenticated identifier aligned to the domain in the RFC 5322 From header at either the organizational or domain level, to consider a message authenticated. This dependency ensures DMARC cannot authenticate messages in isolation but leverages the strengths of SPF (envelope sender validation) and DKIM (content integrity) to provide a more robust framework. SPF alone is limited in scenarios like , where the envelope sender (MAIL FROM) is rewritten, potentially causing failures even for legitimate messages, while DKIM alone verifies signatures but does not enforce domain-level policies for handling failures. DMARC addresses these gaps by combining the results of SPF and/or DKIM, applying alignment checks, and introducing explicit policy instructions to guide receiver actions on unauthenticated mail.

Core Mechanisms

Alignment Models

In DMARC, alignment models determine whether the domains identified by SPF or DKIM authentication mechanisms correspond sufficiently to the domain in the message's From header, ensuring that the authenticating entity is authorized to send on behalf of the claimed domain. This alignment check is a prerequisite for a DMARC authentication pass, preventing unauthorized senders from leveraging passing SPF or DKIM results. DMARC supports two alignment modes: strict and relaxed, specified via the "aspf" and "adkim" tags in the DMARC record, defaulting to relaxed if unspecified. In strict alignment, the domain from the SPF "HELO" or "MAIL FROM" identifier or the DKIM "d=" tag must exactly match the From header's organizational domain, allowing no subdomain variations. Conversely, relaxed alignment permits a broader match, where the SPF or DKIM domain can be a subdomain of the From header's organizational domain (or vice versa), accommodating common email infrastructure like subdomains for mailing services. For instance, if the From header is "[email protected]" and SPF authenticates from "mail.example.com", this passes relaxed alignment but fails strict alignment, as "mail.example.com" is a subdomain of "example.com". The concept of the organizational domain is central to alignment, representing the base domain (e.g., "" for subdomains like "mail.example.com") that defines the scope for matching. Organizational domain discovery in the current specification (RFC 7489) relies on the (PSL) to identify registrable domains, with the DMARCbis specification (internet-draft as of 2025) introducing the Tree Walk algorithm as a replacement. The Tree Walk iteratively checks DNS records up the domain tree until a DMARC policy is found, eliminating PSL dependencies and improving reliability across top-level domains. The Tree Walk starts at the full domain and ascends parentward, stopping at the first domain with a valid DMARC record, which becomes the organizational domain for alignment purposes. Alignment failure occurs if neither a passing SPF result nor a passing DKIM result aligns with the From header domain under the specified mode, resulting in an overall DMARC failure regardless of individual authentication outcomes. This ensures that even if SPF or DKIM passes technically, the message cannot be trusted for the claimed domain without proper alignment, prompting enforcement actions based on the DMARC configuration.

Authentication Checks

DMARC begins by identifying the Organizational Domain of the RFC 5322.From header field, which is determined by applying the rules for domain ownership as outlined in the DMARC specification (RFC 7489), using the to find the base domain that the sender controls, with the DMARCbis draft proposing the Tree Walk algorithm as an alternative. This domain serves as the reference for subsequent alignment checks. The receiver then performs SPF and DKIM authentications independently, evaluating whether each mechanism authenticates an identifier that aligns with the From domain under either strict (exact domain match) or relaxed (matching Organizational Domain) alignment modes, as specified in the DMARC . For SPF, the check verifies if the sending is authorized by the SPF policy of the domain in the RFC 5321.MailFrom (envelope sender) field, resulting in a "pass" only if this domain aligns with the From header domain. Alignment occurs in relaxed mode if the Organizational Domains match (e.g., "child.example.com" aligns with "example.com") or in strict mode if the domains are identical; the domain from the HELO or EHLO command is used as the SPF identifier for alignment only if the RFC 5321.MailFrom has a null domain (i.e., <>); otherwise, the MailFrom domain is used. Similarly, for DKIM, the receiver verifies the cryptographic signature(s) on the message, checking the "d=" (signing domain) tag in each signature; a "pass" requires at least one valid signature where the signing domain aligns with the From domain using the same strict or relaxed rules. A passes DMARC if at least one of SPF or DKIM produces a passing result with proper identifier alignment; failure occurs if neither mechanism passes or if alignment is absent for both. In cases of multiple DKIM signatures, the evaluation considers all present signatures, succeeding if any one is valid and aligns appropriately, while messages lacking a valid RFC 5322.From header or with malformed identifiers fall outside DMARC's scope and cannot align. Upon completion, the receiving system adds a DMARC-Authentication-Results header field to the message, recording the outcome (such as "pass", "fail", or error codes like "temperror") for use in policy enforcement and reporting.

Policy Enforcement

DMARC policy enforcement occurs after email authentication checks, where receiving servers evaluate whether a message passes or fails the DMARC mechanism based on SPF and DKIM alignment. If a message fails these checks, the receiving server applies the domain owner's specified to determine its disposition, such as delivery, , or rejection. The DMARC is defined by the "p=" tag in the domain's DMARC record, which specifies one of three options: "none", indicating monitoring only with no alteration to message delivery; "", instructing receivers to treat failing messages as suspicious, often by routing them to spam folders or applying other scrutiny; or "reject", requiring receivers to block delivery of failing messages. The "none" allows domain owners to observe authentication patterns without impacting legitimate mail, while "" and "reject" progressively strengthen protection against spoofing. Enforcement typically happens during the SMTP transaction for "reject" policies, where the receiving server issues a 5xx permanent failure code, such as "550 5.7.1 Email rejected per DMARC policy", to prevent message acceptance. For "", enforcement is post-acceptance, with messages flagged or isolated rather than outright rejected, allowing flexibility for user review. Receivers may also silently discard messages under "reject" by returning a success code while dropping the , though explicit rejection during SMTP is recommended. Subdomains can have their own policy via the "sp=" tag, which overrides the organizational domain's "p=" policy if set; for example, "sp=quarantine" applies specifically to messages purporting to originate from subdomains. If "sp=" is absent, the subdomain inherits the parent domain's policy. The "pct=" tag enables gradual policy rollout by applying the specified action to only a percentage of failing messages (ranging from 0 to 100, defaulting to 100), such as "pct=50" to enforce on half of failures while monitoring the rest. This allows domain owners to test enforcement without immediate widespread disruption. The "fo=" tag provides temporary overrides for triggering failure reports, specifying conditions like "fo=1" for reports on any authentication failure or "fo=d" for DKIM-specific failures, ensuring detailed visibility during enforcement transitions.

Configuration

DNS TXT Record Syntax

DMARC policies are published in the Domain Name System (DNS) as TXT records located at the subdomain _dmarc followed by the , such as _dmarc.example.com. This placement allows email receivers to query the record during the Simple Mail Transfer Protocol (SMTP) session to retrieve the domain's and disposition instructions. The syntax of a DMARC TXT record follows a tag-value format, where tags are separated by semicolons and values are assigned using equals signs. The Augmented Backus-Naur Form (ABNF) for the record is defined as dmarc-record = dmarc-version dmarc-sep [dmarc-request] *( ";" dmarc-request ), ensuring structured parsing of the content. Multiple TXT strings may be concatenated if the record exceeds DNS limits, and unknown tags are ignored during validation. Two tags are mandatory for a valid DMARC record: the version tag v, which must be set to DMARC1 and appear as the first tag, and the policy tag p, which specifies the requested disposition for failing messages and accepts values of none (monitor only), quarantine (treat as suspicious), or reject (block delivery). Domain owners typically begin with p=none to enable monitoring via reports without impacting message delivery, upgrading to p=quarantine or p=reject after reviewing aggregate reports for at least one week to confirm consistent authentication success. Common optional tags include rua for designating URIs (typically mailto: addresses) where aggregate reports are sent, ruf for failure reports, fo for failure reporting options (e.g., 1 to generate reports on any authentication failure), adkim for DKIM identifier alignment mode (with values r for relaxed or s for strict; defaults to r), and aspf for SPF domain alignment mode (also r or s; defaults to r). The pct tag allows specifying a percentage of messages (0-100; defaults to 100) to which the policy applies, enabling gradual rollout. A representative example of a complete DMARC TXT record is:

v=DMARC1; p=reject; rua=mailto:reports@[example.com](/page/Example.com); ruf=mailto:failures@[example.com](/page/Example.com); adkim=s; aspf=r; pct=100

v=DMARC1; p=reject; rua=mailto:reports@[example.com](/page/Example.com); ruf=mailto:failures@[example.com](/page/Example.com); adkim=s; aspf=r; pct=100

This record sets a reject policy with strict DKIM alignment, relaxed SPF alignment, and full policy application, directing reports to the specified addresses. An example of a basic monitoring record is:

v=DMARC1; p=none; rua=mailto:[email protected]; ruf=mailto:[email protected]; fo=1

v=DMARC1; p=none; rua=mailto:[email protected]; ruf=mailto:[email protected]; fo=1

receivers fetch the DMARC record by querying the DNS for the TXT resource record at the _dmarc of the message's RFC 5322 From domain; if absent, they query the organizational domain's . The record is parsed into tag-value pairs, and the resulting policy is enforced based on SPF and DKIM authentication outcomes, with external report URIs verified if they differ from the domain. It is recommended to ensure that SPF and DKIM records have been set up and are authenticating messages successfully for at least 48 hours before publishing the DMARC record. Adding a DMARC TXT record to DNS typically takes minutes, while propagation across the global DNS network can take up to 48 hours, though often faster. Domain owners can verify the record's visibility and correctness using tools such as MX Toolbox's DMARC Check or dmarcian's DMARC Inspector.

Policy Options

DMARC policy options are specified through tags in the DNS , allowing domain owners to define how receivers should handle messages that fail checks. The primary tag is p, which dictates the requested action for the domain: "none" instructs receivers to take no action beyond monitoring, enabling domain owners to observe traffic without disrupting delivery; "" treats failing messages as suspicious, typically routing them to the spam folder; and "reject" requires receivers to refuse delivery of failing messages during the SMTP transaction. This tag is mandatory for a valid DMARC record and applies to the organizational domain unless overridden. For subdomains, the sp tag sets an independent policy, using the same values as p ("none", "quarantine", or "reject"), which allows granular control over subdomain-specific handling without affecting the parent domain. If sp is absent, it defaults to the value of p, ensuring consistent policy inheritance unless explicitly customized. This separation supports scenarios where subdomains, such as those used for specific services, require different enforcement levels. Alignment strictness is controlled by adkim for DKIM and aspf for SPF, each accepting "r" (relaxed) or "s" (strict) modes to determine how closely the authenticating domains must match the message's domain. In relaxed mode (the default for both), alignment succeeds if the domains share the same organizational domain or parent; strict mode requires an exact match, offering tighter security at the potential cost of flexibility. These tags interact with the policy by influencing whether a message passes DMARC authentication, thereby triggering the p or sp action only if alignment fails alongside SPF or DKIM checks. The pct tag limits the enforcement scope by specifying the percentage (0-100, default 100) of failing messages to which the policy applies, facilitating gradual rollout without immediate full enforcement. For example, setting pct=50 means the policy action (e.g., reject) is applied to half of the failing messages selected randomly by the receiver, while all messages continue to generate reports regardless of this tag. This interaction allows domain owners to monitor impact before increasing the percentage, reducing risks during implementation. Reporting frequency is adjusted via the ri tag, a 32-bit unsigned in seconds indicating the desired interval between aggregate reports (default 86400, or daily). Receivers aim to comply on a best-effort basis, often sending reports daily or more frequently if feasible, ensuring domain owners receive timely visibility into authentication outcomes. For public suffix domains, the np tag, introduced experimentally, defines the policy for non-existent subdomains (DNS NXDOMAIN responses), using values "none", "", or "reject" to mitigate from unregistered subdomains. If absent, it defaults to the p value, which is typically "none" for public suffixes to avoid overly restrictive enforcement on registrars. This tag enhances protection for top-level domains by allowing policies tailored to hypothetical subdomains that do not exist, as outlined in RFC 9091.

Reporting Directives

DMARC reporting directives enable domain owners to specify destinations for receiving feedback on outcomes, facilitating monitoring and analysis without delving into report structures. These directives are optional tags within the DMARC DNS , allowing receivers to send aggregate summaries and failure notifications to designated URIs. The rua tag designates one or more URIs where aggregate reports—summarizing DMARC validation results over a 24-hour period—are to be delivered. Supported URI schemes include mailto: for transmission and for secure web posting, with multiple destinations specified as a comma-separated list. Aggregate reports from a given reporting source are generated daily in XML format, compressed with , and sent only once per unique source to avoid redundancy. The ruf tag similarly specifies URIs for forensic reports, which provide message-specific details on authentication failures, using the same mailto: and https:// schemes in a comma-separated list. These reports are generated and sent in near real-time upon detection of a failure, aiding in rapid investigation of potential abuse. The ruf tag is particularly useful when paired with failure reporting options to control the scope of notifications. The fo (failure options) tag controls the conditions under which forensic reports are triggered, requiring the presence of the ruf tag to be effective. Its value is a colon-separated list of characters, with the following options:
  • 0: Generate a report if all underlying authentication mechanisms (SPF and DKIM) fail (default behavior).
  • 1: Generate a report if any underlying authentication mechanism fails.
  • d: Include a report for DKIM failures, regardless of SPF results.
  • s: Include a report for SPF failures, regardless of DKIM results.
This tag allows domain owners to fine-tune reporting granularity based on their monitoring needs. DMARC reports are aggregated daily from distinct reporting sources to provide a consolidated view of email volume and trends, ensuring efficiency in data collection. is a core consideration, with reports designed to include only limited personally identifiable (PII), such as partial IP addresses or redacted headers, to protect recipient privacy. External report destinations beyond the domain's control are optional and must be explicitly authorized through the URI specifications.

Reporting and Monitoring

As of November 2025, DMARC reporting mechanisms are defined in RFC 7489 (2015), with proposed updates in the advanced DMARCbis draft (draft-ietf-dmarc-dmarcbis-41, last updated July 2025). Key changes in the draft include stricter XML schemas for aggregate reports with new tags (e.g., for generator and human-readable results), removal of the 'ri' tag to enforce daily or more frequent reporting, mandatory external destination validation, limits on DKIM signatures per row, and separation of aggregate and failure reporting into dedicated specifications. Failure reporting remains unchanged.

Aggregate Reports

Aggregate reports in DMARC, also known as RUA reports, provide domain owners with periodic summaries of outcomes for messages claiming their domain in the From header. These reports enable monitoring of sending sources, identification of patterns, and assessment of overall compliance rates with DMARC . The reports follow an XML format specified in RFC 7489, with a root element of <feedback> that encapsulates metadata, details, and aggregated data records. The structure includes a <report_metadata> element for report identification (such as name, reporting , report ID, and date range via <begin> and <end> timestamps in Unix epoch seconds), a <policy_published> element detailing the DMARC applied during the period (including domain, alignment modes like adkim and aspf, p and sp, pct, and reporting options fo), and one or more <record> elements containing the aggregated data. Each <record> includes a <row> for summary metrics, <identifiers> for evaluated domains (such as envelope_from, envelope_to, and header_from), and <auth_results> for detailed SPF and DKIM outcomes. Within each <row>, key data encompasses the source IP address of the connecting MTA (<source_ip>), the number of messages summarized (<count>), and authentication results under <policy_evaluated>, including the disposition applied (none, quarantine, or reject), SPF result (none, neutral, pass, fail, softfail, temperror, or permerror), and DKIM result (none, pass, fail, policy, neutral, temperror, or permerror). DMARC alignment and overall pass/fail status are derived from these SPF and DKIM outcomes combined with header alignment. The <identifiers> and <auth_results> provide context on domains and specific details, such as the DKIM signing domain or SPF scope. For delivery, aggregate reports are generated and sent at least daily (default interval of 86400 seconds) or more frequently if specified via the ri= reporting interval directive in the DMARC record, typically to URIs designated in the rua= tag (such as mailto: addresses). To authorize a specific external domain (e.g., externaldomain.com) to receive reports for the receiving domain (e.g., receivingdomain.com), publish a TXT DNS record at externaldomain.com._report._dmarc.receivingdomain.com with value "v=DMARC1;" (semicolon optional but recommended for compliance). A wildcard record *._report._dmarc.receivingdomain.com with value "v=DMARC1;" authorizes reports from any domain, though this is not recommended for security reasons as it may allow unauthorized submissions, but it is common in shared reporting setups. The XML content is compressed using GZIP, with a media type of application/gzip, and attached to email messages using a standardized filename format: {reporting-URI}!{policy-domain}!{begin-timestamp}!{end-timestamp}.xml.gz. This ensures efficient transmission and storage for ongoing analysis. A representative example of a <row> element within a <record> might appear as follows, summarizing messages from a specific IP:

xml

<row> <source_ip>192.0.2.1</source_ip> <count>5</count> <policy_evaluated> <disposition>none</disposition> <dkim>pass</dkim> <spf>pass</spf> </policy_evaluated> </row>

<row> <source_ip>192.0.2.1</source_ip> <count>5</count> <policy_evaluated> <disposition>none</disposition> <dkim>pass</dkim> <spf>pass</spf> </policy_evaluated> </row>

This structure aggregates data without revealing individual message details, prioritizing while offering actionable insights into ecosystem health.

Failure Reports

Failure reports, also known as forensic or RUF reports, provide detailed, per-message information about emails that fail DMARC checks, enabling domain owners to perform targeted investigations. These reports are triggered based on the "fo" (failure options) tag specified in the DMARC , which determines the conditions for generating a . For instance, "fo=0" (the default) triggers a report only if both SPF and DKIM fail to produce an aligned pass result, while "fo=1" triggers on any failure, and options like "fo=d" or "fo=s" limit reports to DKIM or SPF failures, respectively. The "ruf" tag must also be present in the record, specifying the URI (typically an ) where reports are sent. The format follows the Authentication Failure Reporting Format (AFRF), a structured subset of the Abuse Reporting Format (ARF) defined in RFC 6591, sent as a multipart and differing from the XML-based aggregate reports by focusing on individual incidents rather than summaries. Key elements include a human-readable text part, a machine-readable feedback report with details, and an attachment containing the original headers or full body. Within the feedback report, the content is organized into fields such as "auth_results" detailing SPF and DKIM outcomes (e.g., SPF-DNS record, DKIM-Domain, DKIM-Selector, and evaluation results like pass or fail), a "received" chain tracing the path via header fields, and details like the evaluated DMARC and alignment mode. The attachment typically includes the raw , including full headers and a body snippet, to facilitate forensic . The primary purpose of failure reports is to aid in specific authentication failures, such as misconfigurations in sending , and investigating potential like spoofing attempts by examining the exact message and authentication artifacts. However, these reports are optional for receiving servers, which may decline to send them due to concerns, as they often contain sensitive information like full headers, recipient addresses, and message bodies. Additionally, receivers are encouraged to rate-limit or aggregate reports (e.g., by recipient domain or time window) to prevent denial-of-service risks from high-volume senders.

Report Interpretation and Tools

Interpreting DMARC reports involves examining key metrics to assess efficacy and identify potential issues. Pass rates for SPF and DKIM indicate the proportion of messages that successfully authenticate via these mechanisms, typically expressed as percentages within the report's record counts; for instance, a high SPF pass rate above 90% suggests robust sender authorization, while lower rates may signal misconfigurations. Top failing IPs highlight source addresses responsible for the majority of failures, allowing domain owners to prioritize investigations into unauthorized senders. Alignment issues, derived from the row-level policy_evaluated elements, reveal mismatches between the From domain and SPF/DKIM identifiers, often due to subdomain usage or forwarding, with common failure modes including "spf=permerror" or "dkim=fail" paired with non-aligned headers. Analysis of DMARC reports begins with the XML to extract structured from aggregate or reports. Tools convert raw XML into tabular formats, aggregating volumes of passes, fails, and policy outcomes across reporting periods. Visualization techniques, such as charts for trends over time or heatmaps of IP distributions, help quantify volumes and spot anomalies like sudden spikes in fails from new IPs. Identifying legitimate versus malicious sources requires cross-referencing report against known authorized senders; for example, legitimate traffic from marketing platforms may show consistent passes, while sporadic fails from residential IPs could indicate spoofing attempts. Several open-source tools facilitate DMARC report interpretation by automating parsing and visualization. Dmarcian's free XML-to-human converter processes aggregate reports into readable summaries, highlighting key metrics like pass rates and failing sources without requiring a paid account. Postmark's DMARC Weekly Digests service ingests reports from major providers and delivers human-readable email summaries, focusing on alignment issues and top IPs for quick insights. The Python-based parsedmarc library serves as a CLI and module for parsing reports, integrating with and for advanced visualization of failure volumes and policy evaluations. Best practices for report interpretation emphasize aggregating data over extended periods, such as weekly or monthly summaries, to discern trends beyond daily fluctuations and establish baselines for pass rates. Correlating report findings with internal logs enables validation of legitimate sends against reported authentications, resolving discrepancies like unreported forwards. Monitoring during pct rollouts—gradually increasing the percentage of emails subject to enforcement from 10% to 100%—involves tracking failure rates at each increment to avoid deliverability disruptions, with adjustments based on observed alignment issues. Handling privacy in DMARC reports is crucial, as they contain sensitive metadata like source IP addresses that could reveal user or organizational details if exposed. Best practices include anonymizing such data, such as hashing or truncating IPs, before storage or sharing to mitigate risks from report floods or unauthorized access, while implementing External Destination Verification to control report recipients.

Implementation Guide

Step-by-Step Adoption Process

Before implementing DMARC, organizations must establish valid SPF and DKIM records for their domain and ensure they have been properly authenticating messages for at least 48 hours to allow full DNS propagation and reliable authentication signals. These prerequisites ensure that signals are in place, allowing DMARC to evaluate alignment between the sending domain and message headers without immediate disruptions. The adoption process begins with publishing an initial DMARC DNS TXT record at the subdomain _dmarc.example.com (where "example.com" is the organizational domain) using the policy tag p=none, which instructs receivers to take no action on failing messages but to continue monitoring. Adding the DNS TXT record typically takes minutes, with propagation typically up to 48 hours (often faster). This record must include the rua= tag specifying one or more URIs (typically mailto: addresses) where aggregate reports will be sent, enabling the organization to collect visibility into email traffic without enforcing policies. For example, a basic record might read: v=DMARC1; p=none; rua=mailto:[email protected]. Next, organizations analyze the incoming aggregate reports from the rua= URI to identify authorized senders and detect unauthorized or misaligned traffic. These XML-formatted reports, generated daily by participating receivers, detail authentication outcomes, volume statistics, and sources of for the domain, helping to map legitimate senders and pinpoint issues such as unsigned bulk or spoofing attempts. This step requires reviewing aggregate reports for at least one week to establish a baseline, though several weeks of data collection is typically needed to build a comprehensive view of the sending . Once legitimate senders are identified, adjustments are made to SPF and DKIM configurations to ensure proper alignment with the From: header domain, using the aspf= and adkim= tags in the DMARC record (set to r for relaxed or s for strict mode) to define how closely identifiers must match. To introduce enforcement gradually and avoid widespread delivery issues, the pct= tag is set to a low percentage (e.g., pct=10 to apply the policy to only 10% of failing messages), allowing a transition to p=quarantine while monitoring impacts. As confidence in the setup grows, the policy is escalated to p=quarantine for broader application (e.g., marking failing messages as spam), followed by p=reject to instruct receivers to refuse delivery of non-compliant emails entirely. For subdomains, a separate sp= tag is configured (e.g., sp=reject) to apply tailored policies, preventing inheritance issues from the parent domain's record. Policy options like p=reject ensure strong protection once alignment is verified across all senders. Finally, ongoing monitoring involves reviewing failure reports via the optional ruf= tag (e.g., ruf=mailto:[email protected]), which provides detailed forensic data on individual failing messages, including headers and results, to identify and resolve breakages such as third-party service misconfigurations. The fo= tag can be used to control generation (e.g., fo=1 for all failures), facilitating rapid handling of delivery disruptions during enforcement. This iterative monitoring ensures sustained efficacy as practices evolve.

Best Practices and Common Pitfalls

Organizations implementing DMARC should begin with a monitoring-only of p=none to observe results without affecting message delivery, for an extended period sufficient to gather sufficient data on legitimate flows and establish a baseline. This approach allows domain owners to identify and resolve issues in SPF and DKIM configurations before enforcing stricter policies. Prior to deploying DMARC, it is essential to achieve 100% coverage of SPF and DKIM across all outbound sources, ensuring that legitimate messages pass at least one mechanism with proper alignment. For redundancy in report reception, domain owners are advised to specify an external rua= URI in the DMARC record, such as a third-party service, but this requires verification via a DNS at the external domain to authorize report delivery and prevent abuse. A common pitfall in DMARC deployment is adopting overly strict alignment modes (adkim=s and aspf=s), which can cause failures for legitimate emails where domain mismatches occur, leading to unnecessary rejections or quarantines. Another frequent error is ignoring subdomains, as a base domain does not automatically apply to subdomains unless explicitly set via the sp= tag, potentially leaving them vulnerable to spoofing. Misconfiguring the pct= tag can also result in uneven enforcement; for instance, setting a low percentage too hastily may fail to protect the majority of traffic, while abrupt increases can disrupt delivery. Rushing to enforcement policies without adequate time to review aggregate reports and establish a baseline of legitimate traffic is another common pitfall, which can lead to delivery issues for authorized emails. To enhance security, domain owners should rotate DKIM keys used for DMARC-aligned signing at regular intervals, such as every 6 to 24 months, to mitigate risks from key compromise. Reporting URIs in rua= and ruf= tags must be validated, especially for external destinations, to ensure only authorized recipients receive sensitive data. Compliance with RFC 9091 is recommended for handling public suffix domains (PSDs), allowing operators of PSDs like certain top-level domains to publish policies via the np= tag and register in the PSD DMARC registry to protect non-existent subdomains. Implementers should monitor IETF developments, such as DMARCbis drafts for updates to reporting and policy mechanisms, as of 2025. For a smooth rollout, organizations should employ a phased by incrementally increasing the pct= value—starting at 10-25% after initial monitoring and gradually advancing to 100%—while continuously analyzing aggregate reports to avoid widespread delivery disruptions. This methodical progression helps maintain email deliverability during the transition to enforcement policies like p=[quarantine](/page/Quarantine) or p=reject.

Compatibility Considerations

Email Forwarding Challenges

Email forwarding presents significant challenges to DMARC authentication because it typically modifies the envelope sender address, causing SPF checks to fail at subsequent receiving servers. When an email is forwarded, the intermediate server often rewrites the MAIL FROM (envelope sender) to its own domain to prevent delivery loops, which misaligns the SPF record of the original sender's domain with the forwarding server's IP address. Additionally, DKIM signatures can become invalid if the forwarding process alters the message body or certain headers, such as by adding disclaimers or modifying the To field, thereby breaking the cryptographic validation. These authentication failures directly impact DMARC by causing legitimate forwarded emails to fail alignment requirements, resulting in false positives where valid messages are treated as suspicious or spoofed. In strict DMARC policies (p=quarantine or p=reject), this can lead to quarantining or rejection of forwarded emails, disrupting user workflows and reducing deliverability for intended recipients. For instance, newsletters from a corporate domain forwarded by recipients via personal services may fail strict alignment, appearing to originate from the forwarder's infrastructure (e.g., ), prompting receivers to apply the sender's DMARC policy and potentially block delivery. To mitigate these issues, the (ARC) protocol, defined in RFC 8617, enables intermediate handlers to preserve and attest to the original authentication results across forwarding hops. ARC works by adding a chain of signed headers (AMS, AAR, AS) that record prior DKIM and SPF validations, allowing final receivers to validate the message's provenance even after modifications, thus restoring DMARC alignment for legitimate forwards. Developed by the IETF DMARC Working Group, ARC has been adopted by major providers like and to support reliable forwarding without authentication loss. Receiver behavior varies, with some providers applying relaxed DMARC alignment (ada=relaxed) to accommodate forwarding by matching organizational domains rather than exact ones, reducing false failures. Others, such as , may override strict sender policies if forwarding is detected through internal signals, delivering messages to spam or instead of outright rejection, though this is not standardized. The pct tag in DMARC records can also indirectly aid by limiting policy enforcement to a subset of messages during testing, allowing organizations to monitor forwarding impacts without widespread disruption.

Mailing List Handling

Mailing lists pose significant compatibility challenges for DMARC because they frequently modify incoming messages, such as rewriting the From: header to reflect the list's domain or appending footers, disclaimers, or subject tags. These alterations typically invalidate existing DKIM signatures by changing the message body or headers, leading to DMARC alignment failures where the From: domain no longer matches the domains authenticated via SPF or DKIM. As a result, messages from mailing lists risk being quarantined, rejected, or filtered into spam by receiving servers enforcing strict DMARC policies. To mitigate these issues without relying on advanced protocols, mailing list operators can disable unnecessary modifications, such as turning off From: header rewrites, footer additions, and subject line alterations, thereby preserving the original message integrity and allowing the original DKIM signature and DMARC alignment to remain intact. Another approach involves implementing the Sender Rewriting Scheme (SRS) for the envelope sender (MAIL FROM), which rewrites the envelope address to a domain controlled by the list operator—such as SRS0=HHH=TT=originaldomain.com=listdomain.com—while encoding the original sender details, ensuring SPF passes during forwarding without affecting the visible From: header. For handling the From: header specifically, some mailing list software configurations preserve the original sender's From: to maintain , while adding a Reply-To header directed to the original sender or the list management to facilitate replies and subscriptions without disrupting list functionality. Additionally, list operators can post messages using an authenticated from their own DMARC-compliant domain, ensuring the outbound message aligns properly from the start. Senders may also employ the DKIM l= tag to specify a maximum body length for signing (e.g., l=), permitting to append non-malicious content like footers beyond that limit without breaking the signature, though this method reduces security by allowing unsigned modifications. Standards such as RFC 8617 recommend that mailing list operators support DMARC compatibility by implementing mechanisms like the (ARC) to convey original authentication results across intermediaries.

Sender Field and Other Issues

The header field, defined in RFC 5322, indicates the actual transmitter of a message when it differs from the author specified in the From header, such as in scenarios involving resending or . In DMARC, enforcement and domain alignment are based exclusively on the organizational domain derived from the RFC 5322.From header, as this field represents the user-visible identity of the . The presence of a differing header does not alter DMARC evaluation; authentication results from SPF and DKIM are aligned solely against the From domain, and reports are generated accordingly. However, inconsistencies between and From can complicate troubleshooting, as some receiving systems may log or reference the for additional context without impacting DMARC compliance. Other interoperability issues arise in multi-recipient emails, where a single message sent to multiple addresses may encounter varying DMARC handling by different receiving mail transfer agents (MTAs). For instance, (BCC) recipients might receive messages with altered envelope details, potentially leading to SPF misalignment if the sending MTA does not properly authenticate the shared From domain across all paths. While DMARC policy applies uniformly per message, discrepancies in receiver implementations can result in inconsistent reporting or delivery outcomes. Internationalized domain names (IDNs) present challenges in DMARC due to the need for consistent handling of characters in headers and DNS records. DMARC specifications require the use of A-labels (Punycode-encoded forms) for domain comparisons in authentication checks, but mismatches between U-labels (native ) in the From header and A-labels in SPF/DKIM can cause alignment failures. RFC 8616 updates SPF, DKIM, and DMARC to clarify IDN usage, mandating A-labels for lookups while permitting U-labels in visible headers, to mitigate spoofing risks in global flows. Legacy MTAs, particularly those predating DMARC's , often lack support for its validation mechanisms, leading to ignored policies or bypassed checks. These systems may not query DMARC DNS records or enforce reported dispositions like , allowing potentially unauthenticated messages to pass through. Compatibility is improved in modern MTAs via backward-compatible implementations, but organizations using legacy must audit sending paths to ensure DMARC signals are not silently dropped. Edge cases include messages with an empty From header, which violate RFC 5322 requirements and fall outside DMARC scope, as no organizational domain can be identified for policy application. Role-based addresses, such as [email protected], pose no inherent DMARC issues if the domain aligns with authenticated SPF or DKIM results; however, they increase spoofing if not properly secured, as attackers may exploit the non-interactive nature to mimic legitimate notifications. To resolve these issues, domain owners should ensure header consistency by aligning Sender and From domains where possible and validating configurations against edge cases. Testing tools like dmarctester.com simulate DMARC evaluation across various scenarios, helping identify misalignments before deployment.

History and Evolution

Development Milestones

The development of DMARC originated from collaborative efforts initiated in 2010 among major email providers to address limitations in existing authentication protocols like SPF and DKIM, particularly in preventing domain spoofing. In spring 2011, organizations including AOL, FastMail, Google, Microsoft, and Yahoo formed a working group to draft the initial specification, which was first released on January 30, 2012, as an independent proposal for domain-level policy enforcement and reporting. The initial specification was first released on January 30, 2012, as an independent proposal. It was submitted to the IETF as the individual-submitted Internet-Draft draft-kucherawy-dmarc-base-00 on March 31, 2013, and underwent several revisions, including draft-kucherawy-dmarc-base-05 on October 29, 2014, introducing core elements like policy tags (p=) and alignment modes. The protocol achieved formal standardization with the publication of RFC 7489 in March 2015 as an Informational RFC on the Independent Submission stream, defining essential mechanisms such as identifier alignment between the RFC 5322 From header and authentication results from SPF or DKIM, domain policies (none, quarantine, reject), aggregate reporting via URI tags (rua=), and forensic failure reports (ruf=). This document established DMARC as a scalable framework for domain owners to request message disposition and feedback from receivers, building directly on prior drafts while clarifying operational requirements. Post-2015 advancements focused on refining supporting protocols and addressing edge cases. The SPF specification was updated in RFC 7208 (April 2014, just prior but integral to DMARC deployment), which obsoleted RFC 4408 and incorporated guidance on evaluating SPF results in the context of DMARC alignment, emphasizing the "best-guess" record lookup and soft-fail mechanisms (?-all). For DKIM, while the base protocol in RFC 6376 (September 2011) persisted, RFC 8301 (January 2018) updated cryptographic requirements to enhance for DMARC-signed messages, mandating stronger hashes like SHA-256. Between 2020 and 2021, refinements targeted organizational domain handling and policy inheritance. Experimental updates in RFC 9091 (July 2021) extended DMARC to better support public suffix domains (e.g., .com or co.uk), introducing the 'np' tag for specifying subdomain policies independent of the parent domain and mitigating abuse risks from misaligned subdomains. Concurrently, early drafts for DMARC enhancements, such as draft-ietf-dmarc-dmarcbis-00 (March 2020), proposed shifting from reliance to a DNS Tree Walk for dynamic organizational domain discovery, improving accuracy in hierarchical policy lookups without external list dependencies. No major RFCs have been issued since , with development shifting to the IETF DMARC (initially chartered in and rechartered in June 2025 for final work) on the DMARCbis revision. This ongoing work, reflected in drafts like draft-ietf-dmarc-dmarcbis-41 (April 2025), formalizes the DNS Tree Walk for policy discovery and alignment, adds tags like 'psd' for subdomain discovery, removes obsolete elements (e.g., 'pct' and 'ri'), and elevates the specification to Standards Track for broader and clarity. As of November 2025, the core DMARCbis specification has been approved by the IESG and is expected to be published as an RFC on the Standards Track imminently, obsoleting RFC 7489 and RFC 9091.

Key Contributors and Organizations

The development of DMARC was driven by key individuals who contributed to its foundational specifications and protocols. Tim Draegen, a primary author and advocate for DMARC, played a central role in its creation, drawing from his expertise in to address domain spoofing challenges. while John Levine from the IETF provided critical input on integration with existing standards. These efforts were acknowledged in the core DMARC specification for their instrumental roles in shaping the protocol's design. Organizations such as the Messaging Anti-Abuse Working Group (MAAWG, now M3AAWG) led the initial drafting process in 2011, fostering collaboration among senders and receivers to produce the first prototypes and specification drafts released in early 2012. The IETF's subsequently formalized the protocol through its progression to RFC status, ensuring interoperability and standardization. Additional support came from major entities including and , which participated as founding receivers to refine authentication mechanisms like identifier alignment. Further contributions included Murray Kucherawy, who served as editor for RFC 7489, the primary DMARC specification published in 2015, overseeing its technical accuracy and structure. Dave Crocker advanced the concept of identifier alignment, clarifying how DMARC evaluates domain matches between authentication results and message headers. For ongoing maintenance, the DMARC.org consortium manages resources such as the and to support implementation guidance. Meanwhile, the IETF continues updates through the DMARCbis effort, addressing interoperability issues in drafts like RFC 7960. DMARC adoption has grown significantly since its early years, when implementation rates were below 10% among surveyed domains in 2015. A 2016 analysis of major organizations indicated that only about 22% had adopted DMARC by the end of that year, reflecting limited awareness and technical challenges in the protocol's initial phase. By 2017, a study of 489 popular domains with SPF records found that just 34% had implemented DMARC, with only 9% (or roughly 0.1% when extrapolated to broader domains) enforcing the strictest "p=reject" to block unauthenticated emails. Recent data shows accelerated global uptake, with EasyDMARC's 2025 report analyzing over 1.8 million domains revealing a rise in adoption from 27.2% in 2023 to 47.7% in 2025 among top domains. Enforcement policies, which instruct receivers to quarantine or reject failing emails, surged by 50% over the same period, driven by heightened cybersecurity priorities. Fortra's Q2 2025 analysis of the top 10 million domains reported that 18.2% now publish valid DMARC records, with 72.8% of monitored domains using Fortra services enforcing "p=reject" policies, indicating stronger protection among active implementers. Among top-tier sectors, compliance exceeds 80%, as seen in 74% of the top 500 U.S. retail domains aligning with best-practice DMARC records. Regionally, adoption varies but shows consistent growth. In the United States, mandatory DMARC requirements for bulk senders by providers like , Yahoo, and contributed to a substantial phishing reduction, with successful email delivery dropping from 69% to 14% between 2023 and 2025. For France's .fr , Afnic reported DMARC adoption increasing from 7.3% in 2023 to 15.1% in 2024 and 19.5% in 2025, more than doubling in two years amid rising . Key drivers include regulatory pressures and evolving threats. The U.S. Cybersecurity and Infrastructure Security Agency's (CISA) 2022 Cross-Sector Cybersecurity Performance Goals (CPGs) mandate DMARC implementation for domains to enhance resilience against spoofing. Rising business compromise (BEC) attacks, which caused over $2.9 billion in U.S. losses in 2023 alone, have further propelled adoption by highlighting DMARC's role in verifying sender authenticity. Ongoing drafts of DMARCbis, the updated specification progressing toward RFC publication in 2025, are boosting interest through proposed improvements like enhanced reporting and subdomain handling.

Tools and Services

Open-Source Implementations

OpenDMARC is a prominent open-source C library that implements DMARC policy enforcement and aggregate report generation, designed for integration with mail transfer agents (MTAs) such as Postfix. It provides milter-based filtering to validate incoming emails against DMARC records, enabling actions like quarantine or rejection based on policy outcomes, and supports the generation of DMARC feedback reports to designated recipients. For DMARC report processing, parsedmarc serves as an open-source Python module and command-line utility that parses both aggregate (RUA) and forensic (RUF) reports, extracting key metrics such as authentication results, source IP addresses, and policy dispositions for further analysis or storage in databases like Elasticsearch. This tool facilitates the interpretation of XML-formatted reports from providers like Google and Yahoo, aiding domain owners in identifying spoofing attempts without proprietary dependencies. In the realm of report aggregation, rddmarc is an open-source script that processes incoming DMARC aggregate report emails by extracting, decompressing, and parsing the embedded XML data, then inserting summarized statistics into a database for querying and visualization. It handles reports from multiple providers, including support for addresses via an accompanying MySQL plugin, making it suitable for long-term monitoring of trends. For email signing components integral to DMARC compliance, dkimpy is an open-source Python library that handles (DKIM) signing and verification as per RFC 6376, which underpins DMARC's alignment checks. Often paired with milter implementations like those in OpenDKIM, it enables automated signing of outbound messages to ensure proper signatures are applied before DMARC evaluation. Testing tools and services include dmarctester.com, an online service that allows users to send test emails to validate their DMARC configuration by simulating server-side SPF, DKIM, and DMARC checks, providing visual feedback on alignment and application. Similarly, mail-tester.com incorporates DMARC validation within its broader deliverability assessment, scoring messages based on headers and DNS records to help diagnose setup issues. These implementations often integrate with anti-spam frameworks for enhanced enforcement; for instance, OpenDMARC can be configured within Amavis (amavisd-new) to apply DMARC results as content filters, rejecting or tagging messages that fail policy checks during the mail processing pipeline. SpamAssassin plugins, such as those leveraging OpenDMARC outputs, incorporate DMARC failure scores into spam detection rules, adjusting message reputations accordingly. Maintenance of these tools is community-driven, with contributions from projects like the Trusted Domain Project and individual developers ensuring alignment with the core DMARC specification in RFC 7489 and its experimental extension for public suffix domains in RFC 9091. Regular updates address evolving threats and standard revisions, with repositories hosted on platforms like for collaborative development and issue tracking.

Commercial Solutions

Valimail provides an platform for DMARC that automates the deployment and management of protocols, including SPF, DKIM, and DMARC, to protect domains from and spoofing attacks. The platform offers global visibility into email senders, continuous monitoring of enforcement readiness, and automated remediation features to align unauthorized senders without manual intervention. It includes dashboard visualizations for tracking DMARC compliance and integrates with BIMI as defined in RFC 9376 to enable brand logo display in authenticated s. dmarcian specializes in DMARC report analytics through its management platform, which processes aggregate and forensic reports to provide actionable insights into failures and successes. The service features tools like the XML to Converter and Viewer for parsing complex reports into readable formats, along with visualizations for domain status and issue tracking. It supports BIMI integration per RFC 9376 for enhanced brand verification and offers auto-remediation guidance to resolve gaps. EasyDMARC delivers an automation platform for DMARC implementation, focusing on streamlined setup and ongoing for organizations and managed service providers. Key features include automated SPF, DKIM, and DMARC record generation, dashboard visualizations for monitoring email volume and compliance, and auto-remediation workflows to fix misconfigurations. The platform integrates BIMI support as outlined in RFC 9376, allowing users to configure logo selectors alongside DMARC enforcement. Enterprise providers like Proofpoint and incorporate DMARC into their broader email security suites, offering advanced protection against spoofing and business email compromise. Proofpoint's solution provides DMARC monitoring and enforcement within its adaptive email security framework, ensuring high deliverability and threat detection. Mimecast emphasizes granular DMARC controls and routing capabilities, supporting quarantine or reject policies for large-scale deployments. Most commercial DMARC solutions operate on subscription-based models, typically tiered by the number of domains, , or feature sets to accommodate varying organizational needs. For instance, dmarcian's plans range from a free personal tier to paid basic and advanced options starting at $24 per month, scaled by domain count and reporting depth. EasyDMARC offers business packages tailored for small to large enterprises, with costs increasing based on domain and extent. These commercial solutions offer distinct advantages over open-source alternatives, including dedicated support, enhanced scalability for large organizations, and seamless integration with enterprise systems. In 2025, trends indicate growing incorporation of AI for threat detection, such as automated anomaly identification in DMARC reports to preempt spoofing attempts.

References

  1. https://dmarc.org/
  2. https://datatracker.ietf.org/doc/html/rfc7489
  3. https://datatracker.ietf.org/doc/draft-ietf-dmarc-dmarcbis/
  4. https://emailsecurity.fortra.com/blog/dmarc-adoption-trends-q2-2025
  5. https://mspaa.net/easydmarc-2025-dmarc-adoption-report/
  6. https://www.valimail.com/resources/reports/2025-disinformation-and-malicious-email-report-why-dmarc-remains-pivotal/
  7. https://www.duocircle.com/dmarc/the-early-2025-global-posture-of-dmarc
  8. https://www.nist.gov/publications/email-authentication-mechanisms-dmarc-spf-and-dkim
  9. https://dmarc.org/about/history/
  10. https://datatracker.ietf.org/doc/html/rfc7208
  11. https://datatracker.ietf.org/doc/html/rfc6376
  12. https://datatracker.ietf.org/doc/html/draft-ietf-dmarc-dmarcbis
  13. https://datatracker.ietf.org/doc/html/rfc7489#section-3.2
  14. https://datatracker.ietf.org/doc/html/rfc7489#section-3.1
  15. https://datatracker.ietf.org/doc/html/rfc7489#section-3.1.2
  16. https://datatracker.ietf.org/doc/html/rfc7489#section-3.1.1
  17. https://datatracker.ietf.org/doc/html/rfc7489#section-6.3
  18. https://datatracker.ietf.org/doc/html/rfc7489#section-6.7
  19. https://datatracker.ietf.org/doc/html/rfc7489#section-6.6
  20. https://datatracker.ietf.org/doc/html/rfc7489#section-10.3
  21. https://datatracker.ietf.org/doc/html/rfc7489#section-6.1
  22. https://datatracker.ietf.org/doc/html/rfc7489#section-6.4
  23. https://datatracker.ietf.org/doc/html/rfc7489#appendix-b.2
  24. https://support.google.com/a/answer/2466580?hl=en
  25. https://datatracker.ietf.org/doc/html/rfc7489#section-6.2
  26. https://datatracker.ietf.org/doc/html/rfc7489#section-7.1
  27. https://powerdmarc.com/spf-dmarc-propagation-time/
  28. https://mxtoolbox.com/dmarc.aspx
  29. https://dmarcian.com/dmarc-inspector/
  30. https://datatracker.ietf.org/doc/html/rfc7489#section-7.2
  31. https://datatracker.ietf.org/doc/html/rfc7489#section-6.4.2
  32. https://datatracker.ietf.org/doc/html/rfc9091#section-3.3
  33. https://datatracker.ietf.org/doc/html/rfc9091#section-3.2
  34. https://datatracker.ietf.org/doc/html/rfc9091
  35. https://datatracker.ietf.org/doc/html/rfc7489#section-7.3
  36. https://datatracker.ietf.org/doc/html/rfc7489#section-9.1
  37. https://datatracker.ietf.org/doc/html/rfc7489#appendix-C
  38. https://datatracker.ietf.org/doc/html/rfc7489#section-7.2.1
  39. https://powerdmarc.com/dmarc-external-destination-verification/
  40. https://mxtoolbox.com/problem/dmarc/dmarc-external-validation
  41. https://datatracker.ietf.org/doc/html/rfc7489#section-7.2.1.1
  42. https://datatracker.ietf.org/doc/html/rfc7489#appendix-B.5
  43. https://datatracker.ietf.org/doc/html/rfc6591
  44. https://datatracker.ietf.org/doc/html/rfc6591#section-3.1
  45. https://datatracker.ietf.org/doc/html/rfc6591#section-3.2
  46. https://datatracker.ietf.org/doc/html/rfc7489#section-7.3.1
  47. https://support.easydmarc.com/knowledge-base/analyzing-dmarc-aggregate-reports
  48. https://dmarcreport.com/blog/how-to-read-dmarc-reports-essential-guidelines-for-accurate-analysis/
  49. https://www.duocircle.com/email-security/how-to-easily-analyze-dmarc-xml-reports-with-free-online-tools
  50. https://mxtoolbox.com/DmarcReportAnalyzer.aspx
  51. https://domainaware.github.io/parsedmarc/
  52. https://medium.com/debricked/analyse-and-visualize-dmarc-results-using-open-source-tools-b9df4e3d0aef
  53. https://dmarcian.com/dmarc-tools/
  54. https://dmarc.postmarkapp.com/
  55. https://github.com/domainaware/parsedmarc
  56. https://glockapps.com/tutorials/dmarc-monitoring-reporting/
  57. https://www.mailercheck.com/articles/how-to-read-a-dmarc-report-and-actually-understand-it
  58. https://dmarcian.com/advancing-dmarc-policy/
  59. https://taejoong.github.io/files/publications/ashiq-2023-dmarc.pdf
  60. https://www.duocircle.com/dmarc/dmarc-reporting-when-to-enable-and-handle-privacy-concerns
  61. https://datatracker.ietf.org/doc/html/rfc7489#section-5
  62. https://dmarc.org/overview/
  63. https://datatracker.ietf.org/doc/html/rfc7489#section-11.3
  64. https://datatracker.ietf.org/doc/html/rfc7489#section-7.3.3
  65. https://datatracker.ietf.org/doc/html/rfc7489#section-b.2.1
  66. https://learn.microsoft.com/en-us/defender-office-365/email-authentication-dmarc-configure
  67. https://www.m3aawg.org/sites/default/files/m3aawg-email-authentication-recommended-best-practices-09-2020.pdf
  68. https://datatracker.ietf.org/doc/html/rfc7489#section-5.2
  69. https://datatracker.ietf.org/doc/html/rfc7489#section-5.6
  70. https://www.m3aawg.org/sites/default/files/m3aawg-dkim-key-rotation-bp-2019-03.pdf
  71. https://datatracker.ietf.org/doc/html/rfc7489#section-12.2
  72. https://datatracker.ietf.org/wg/dmarc/
  73. https://datatracker.ietf.org/doc/html/rfc7489#appendix-b.2.4
  74. https://dmarcian.com/forwarding-and-dmarc/
  75. https://postmarkapp.com/blog/forwarding-emails-dmarc-failure
  76. https://www.valimail.com/blog/dmarc-fail/
  77. https://datatracker.ietf.org/doc/html/rfc8617
  78. https://dmarc.org/2019/07/arc-protocol-published-as-rfc-8617/
  79. https://www.duocircle.com/dmarc/dmarc-relaxed-vs-strict-alignment
  80. https://dmarcian.com/pct-tag/
  81. https://dmarcian.com/mailing-lists-dmarc/
  82. https://www.ietf.org/archive/id/draft-levine-dmarc-listugh-01.html
  83. https://wiki.list.org/DEV/DMARC
  84. https://dmarcreport.com/blog/solving-dmarcs-failures-with-mailing-lists/
  85. https://datatracker.ietf.org/doc/html/rfc8617#section-7.1.3
  86. https://dmarcly.com/blog/how-to-add-multiple-reporting-email-addresses-to-dmarc-record
  87. https://datatracker.ietf.org/doc/rfc8616/
  88. https://www.duocircle.com/dmarc/dmarc-limitations-for-fortifying-email-phishing-in-2024
  89. https://datatracker.ietf.org/doc/html/rfc7489#section-6.6.1
  90. https://www.dmarctester.com/
  91. https://datatracker.ietf.org/doc/html/draft-ietf-dmarc-dmarcbis-41
  92. https://datatracker.ietf.org/wg/dmarc/about/
  93. https://datatracker.ietf.org/doc/draft-ietf-dmarc-dmarcbis/history/
  94. https://dmarcian.com/about-dmarcian/
  95. https://datatracker.ietf.org/doc/html/rfc7489#section-13
  96. https://www.rfc-editor.org/rfc/rfc7489.html
  97. https://www.m3aawg.org/system/files/M3AAWG_DMARC_Training_2012-10-Segment1.pdf
  98. https://www.rfc-editor.org/info/rfc7489
  99. https://dmarc.org/wiki/FAQ
  100. https://www.mediapost.com/publications/article/272074/dmarc-adoption-is-critical-for-email-deliverabilit.html
  101. https://www.ftc.gov/system/files/documents/reports/businesses-can-help-stop-phishing-protect-their-brands-using-email-authentication-ftc-staff/email_authentication_staff_perspective.pdf
  102. https://dmarcian.com/dmarc-adoption-among-us-and-canada-retailers/
  103. https://easydmarc.com/blog/ebook/easydmarc-dmarc-adoption-report-2025/
  104. https://www.afnic.fr/en/observatory-and-resources/expert-papers/spf-dkim-dmarc-and-bimi-on-fr-still-on-the-rise-in-2025/
  105. https://www.cisa.gov/sites/default/files/publications/2022_00092_CISA_CPG_Report_508c.pdf
  106. https://www.proofpoint.com/us/threat-reference/business-email-compromise
  107. https://github.com/trusteddomainproject/OpenDMARC
  108. https://sourceforge.net/projects/opendmarc/
  109. https://pypi.org/project/parsedmarc/
  110. https://github.com/m8e/rddmark
  111. https://pypi.org/project/dkimpy/
  112. https://www.mail-tester.com/
  113. https://www.linuxbabe.com/mail-server/opendmarc-postfix-ubuntu
  114. https://www.valimail.com/
  115. https://www.valimail.com/blog/using-dmarc-to-do-dmarc/
  116. https://www.valimail.com/products/
  117. https://dmarcian.com/
  118. https://dmarcian.com/xml-to-human-converter/
  119. https://dmarcian.com/introduction-to-bimi/
  120. https://easydmarc.com/
  121. https://easydmarc.com/blog/best-tools-to-automate-dmarc-setup/
  122. https://easydmarc.com/tools
  123. https://www.proofpoint.com/us/solutions/email-authentication-with-dmarc
  124. https://www.proofpoint.com/us/threat-reference/dmarc
  125. https://www.mimecast.com/content/switching-from-proofpoint-enterprise-email-protection/
  126. https://www.g2.com/categories/dmarc
  127. https://dmarcian.com/pricing/
  128. https://easydmarc.com/pricing/easydmarc/businesses
  129. https://powerdmarc.com/top-dmarc-enterprise-solutions/
Add your contribution
Related Hubs
Contribute something
User Avatar
No comments yet.