DMARC RFC Explained: The Foundation Of Email Authentication

Key Takeaways

DMARC is described in RFC 7489 (an Informational RFC), with the IETF DMARCbis draft intended to obsolete and replace it as a formal Standards Track RFC.
It uses the results of SPF and DKIM to verify message authenticity.
Domain owners publish DMARC policies in DNS to control handling of failed authentication.
DMARC supports reporting, giving domain owners visibility into email traffic.
DMARC mitigates direct domain spoofing and many phishing attempts that rely on it, but does not stop look-alike domains or display-name abuse.
Adoption of DMARC strengthens brand reputation and email deliverability.

DMARC (Domain-based Message Authentication Reporting and Conformance) is an email authentication protocol that is specified in RFC 7489 (Informational); its successor, the IETF DMARCbis draft, updates and clarifies the protocol and is intended to obsolete RFC 7489.

DMARC builds on SPF (Sender Policy Framework) and DKIM (DomainKeys Identified Mail) to protect email domains from spoofing, phishing, and unauthorized use. By publishing a DMARC policy in DNS, domain owners instruct receiving mail servers on how to handle messages that fail authentication checks. This technical foundation makes DMARC a cornerstone of modern email security and trust.

What is the DMARC RFC?

IETF published DMARC as RFC 7489 (Informational) in March 2015. It defines how domain owners can publish DNS policies telling receivers what to do when a message fails DMARC evaluation.

The protocol was originally developed by an industry consortium that included Google, Microsoft, Yahoo, PayPal, and others, working under the banner of DMARC.org. Their goal was to reduce email fraud by creating a common way to signal and enforce domain-level authentication; this work was later submitted to the IETF, which published it as RFC 7489. While RFC 7489 is an Informational RFC rather than a Standards Track document, it has become the de facto reference for implementing DMARC.

What Does RFC 7489 Entail?

RFC 7489 defines the complete framework for DMARC. While the document itself is technical, its primary goals are straightforward:

Provide a Policy Mechanism

With DMARC, domain owners can publish clear policies that tell receivers what to do with emails that do not pass authentication checks.

Benefit from Comprehensive Reporting

DMARC is also a reporting protocol. This means domain owners can get data on which emails are passing authentication and which are not. This helps them distinguish between legitimate emails and malicious ones.

Reduce Email Fraud

DMARC checks whether the RFC5322.From domain aligns with identifiers authenticated via SPF or DKIM. This mitigates direct domain spoofing; it doesn’t prevent look-alike domains or display-name deception and can be affected by indirect mail flows.

Build on Existing Standards

DMARC uses the results of SPF and/or DKIM and adds identifier alignment, policy (p=), and reporting (rua/ruf).

Technical Breakdown of Requirements

DMARC evaluates alignment and applies policy. Crucially, it adds an important new requirement: identifier alignment.

How DMARC Uses SPF and DKIM Results

DMARC doesn’t just check whether SPF or DKIM pass; it requires identifier alignment with the RFC5322.From domain.

SPF Alignment

DMARC uses the SPF-authenticated RFC5321.MailFrom (or HELO) domain and requires it to align with the RFC5322.From domain. It needs to be at least an organizational match in relaxed mode (aspf=r, default) or exact match in strict mode (aspf=s).

DKIM Alignment

DMARC uses the DKIM d= domain and requires it to align with the RFC5322.From domain. It must be at least an organizational in relaxed mode (adkim=r, default) or an exact match in strict mode (adkim=s).

This alignment requirement is DMARC’s superpower. It directly links the authentication results to the brand’s visible domain, which closes a loophole that attackers previously exploited.

Policy Modes (p=)

The DMARC record specifies one of three policies for receivers to follow when an email fails DMARC checks:

p=none: monitor only; request reports.
p=quarantine: signal that failing mail is suspicious (typical handling: spam/junk).
p=reject: a strong signal that failing mail should be rejected. While the RFC allows for local policy exceptions (e.g., for known good senders), major providers typically honor this policy strictly for unauthenticated spoof attempts.

Reporting Features (RUA & RUF)

DMARC provides useful feedback through two types of reports:

Aggregate Reports (RUA)

RUA reports are machine-readable XML summaries (typically daily) of DMARC results. They include data like the sending IP address, SPF/DKIM results, alignment details, and the number of messages. However, these raw XML files are not easily human-readable and are difficult to analyze manually without specialized tools. The PowerDMARC DMARC Report Analyzer tool automates this process and converts complex data into intuitive charts and graphs.

Message-Specific Failure Reports (RUF, Often Called “Forensic”)

These are optional and rarely sent due to privacy. Many receivers redact or disable them. DMARCbis documents these concerns and references a separate failure-reporting draft, increasingly deprecating RUF reports.

DMARCbis and Upcoming Changes

Technology standards change fast, and DMARC is no exception. DMARCbis is the upcoming updated specification for the DMARC protocol, formalized by the IETF. It’s inspired by the lessons learnt over the past few years and aims to advance DMARC from an “Informational” RFC to a formal “Proposed Standard.”

Think of it not as a revolution or abandonment of DMARC but as an evolution. Key changes and clarifications in DMARCbis include:

p=quarantine Behavior

DMARCbis clarifies quarantine semantics and receiver guidance but still allows receiver discretion.

New Terms and Restructuring

While based on the original RFC 7489, DMARCbis has been restructured and is now easier for the average user to read.

The specification is now split into three separate documents (RFCs). These include:

The main document
The aggregate reporting specification
The failure reporting specification

Some terms and phrases have also been changed for more clarity, for example:

“Report receiver” instead of “report consumer”
“Domain owner assessment policy” instead of “DMARC policy”
“Enforcement” for p=quarantine and p=reject
“Monitoring” mode for p=none

Reporting Issues

Forwarding can break SPF, while mailing lists often break DKIM. DMARCbis now discourages using a p=reject policy if mailing lists are common recipients.

Aggregate reporting rules are also being made stricter, and the XML report format has been updated to reflect the new tags.

Discouraging RUF

DMARCbis discourages the use of RUF reports due to privacy concerns and references failure-reporting in a separate draft.

DNS Tree Walk

The original method for determining the Organizational Domain relied heavily on the Public Suffix List (PSL), which could be incomplete. DMARCbis formally specifies a more flexible and reliable “DNS Tree Walk” algorithm for discovering the applicable DMARC policy.

New vs. Removed DMARC Record Tags

Some DMARC tags like “pct,” “rf,” and “ri” are being completely removed. Instead, new DMARC record tags are being added, like “np,” “psd, and “t.”

Importance for Organizations

Understanding the DMARC RFC can help organizations in several ways, including:

Boosted Compliance

Google, Yahoo, Microsoft, and Apple Mail now require bulk senders to publish a DMARC record along with other controls (SPF/DKIM, alignment, low spam rates, etc). Non-compliance can severely impact email deliverability.

Avoiding Misconfigurations

A misunderstanding of core RFC concepts, especially alignment, can lead to blocking legitimate emails. Knowing the RFC 7489 can help you troubleshoot issues and configure your policies correctly from the start.

To prevent errors, you can also use a DMARC Record Generator tool to create a valid policy. If you already have a record and just need to check it, you can use PowerDMARC’s DMARC Record Checker to ensure it’s published correctly before you move to an enforcement policy.

Many Security Benefits

A properly enforced DMARC policy at p=reject is one of the most effective defenses against direct domain spoofing, which is a leading driver of Business Email Compromise and many phishing attacks. By implementing DMARC, you can safeguard your employees, customers, and brand reputation from a wide range of email-based fraud.

Summing Up

DMARC RFC provides a strong fundamental framework for protecting domains against email fraud. It outlines straightforward, clear-cut standards and guidelines for DMARC setup and enforcement. If you closely follow the rules in the DMARC RFC, it can improve email security, protect brand reputation, and enhance deliverability.

What’s even better is that implementing and managing DMARC effectively doesn’t have to be a manual process. The PowerDMARC platform simplifies the entire journey, from quick setup to thorough monitoring and enforcement.

Get in touch with the PowerDMARC team today and let the experts take care of your email security expertly!

Frequently Asked Questions

When was RFC 7489 published?

RFC 7489 was published in March 2015.

Who can use DMARC?

Any organization or individual that sends email from a domain can and should use DMARC. There are no licensing fees or restrictions, making it an accessible standard for everyone to protect their domain from spoofing.

Why do major email providers require DMARC for bulk senders?

The average user usually can’t understand if a message or email is real or fake. So, mailbox providers have to be careful about which emails they let reach the primary inbox. DMARC helps address this problem. It enables both senders, recipients, and mailbox providers to work together against email fraud. As of Feb 2024, Google/Yahoo require SPF or DKIM authentication, DMARC with p=none or stronger, low spam complaint rates, and RFC5322.From alignment.

Are there any tools that facilitate DMARC setup and enforcement?

PowerDMARC offers many such tools and services, including DMARC generator, checker, hosted services, and more!

About
Latest Posts

Ayan Bhuiya

Shift Lead, Infrastructure & Email Security Expert at PowerDMARC

With over 13 years of experience in Cyber Security, Ayan Bhuiya specializes in Infrastructure, Business Continuity, Risk Management, and Email Security. Currently acting as Shift Lead at PowerDMARC. He holds a Postgraduate Diploma in Networking and Security and has a proven track record of leading strategic security initiatives to mitigate threats and ensure business resilience.

DMARC RFC Explained: A Core Standard for Modern Email Authentication