DMARC, which stands for “Domain-based Message Authentication, Reporting & Conformance”, is an email authentication protocol. It builds on the widely deployed SPF and DKIM protocols, adding a reporting function that allows senders and receivers to improve and monitor protection of the domain from fraudulent email.

Email authentication technologies SPF and DKIM were developed over a decade ago in order to provide greater assurance on the identity of the sender of a message. Adoption of these technologies has steadily increased but the problem of fraudulent and deceptive emails has not abated. It would seem that if senders used these technologies, then email receivers would easily be able to differentiate the fraudulent messages from the ones that properly authenticated to the domain. Unfortunately, it has not worked out that way for a number of reasons:

  • Many senders have a complex email environment with many systems sending email, often including 3rd party service providers. Ensuring that every message can be authenticated using SPF or DKIM is a complex task, particularly given that these environments are in a perpetual state of flux.
  • If a domain owner sends a mix of messages, some of which can be authenticated and others that can’t, then email receivers are forced to discern between the legitimate messages that don’t authenticate and the fraudulent messages that also don’t authenticate. By nature, spam algorithms are error prone and need to constantly evolve to respond to the changing tactics of spammers. The result is that some fraudulent messages will inevitably make their way to the end user’s inbox.
  • Senders get very poor feedback on their mail authentication deployments. Unless messages bounce back to the sender, there is no way to determine how many legitimate messages are being sent that can’t be authenticated or even the scope of the fraudulent emails that are spoofing the sender’s domain. This makes troubleshooting mail authentication issues very hard, particularly in complex mail environments.
  • Even if a sender has buttoned down their mail authentication infrastructure and all of their legitimate messages can be authenticated, email receivers are wary to reject unauthenticated messages because they cannot be sure that there is not some stream of legitimate messages that are going unsigned.

The only way these problems can be addressed is when senders and receivers share information with each other. Receivers supply senders with information about their mail authentication infrastructure while senders tell receivers what to do when a message is received that does not authenticate.

For a complete description, please see DMARC.ORG

DMARC Record Syntax

DMARC records follow the extensible “tag-value” syntax for DNS-based key records defined in DKIM.
The following chart illustrates some of the available tags:

  • v=
    Protocol version. Current value should be v=DMARC1

  • pct=
    Percentage of messages subjected to filtering.

  • ruf=
    Reporting URI for forensic reports.

  • rua=
    Reporting URI of aggregate reports.

  • p=
    Policy for organizational domain.
    Can be "none", "quarantine", or "reject". "none" is used to collect feedback and gain visibility into email streams without impacting existing flows.

  • sp=
    Policy for subdomains of the OD.

  • rf=
    The reporting format for individual Forensic reports. Can be either "afrf" or "iodef".

  • ri=
    The reporting interval for how often you'd like to receive aggregate XML reports. You'll likely receive reports once a day regardless of this setting.

  • adkim=
    Alignment mode for DKIM.
    "r" is for Relaxed, "s" is for Strict. Relaxed mode allows Authenticated DKIM d= domains that share a common Organizational Domain with an email's header-From: domain to pass the DMARC check. Strict mode requires exact matching between the DKIM d= domain and an email's header-From: domain.

  • aspf=
    Alignment mode for SPF.
    "r" is for Relaxed, "s" is for Strict. Relaxed mode allows SPF Authenticated domains that share a common Organizational Domain with an email's header-From: domain to pass the DMARC check. Strict mode requires exact matching between the SPF domain and an email's header-From: domain.

Example DMARC TXT Record

Snippets from a fictitious forward lookup '' zone file

;   Zone records
; IN TXT "v=DMARC1; pct=100;;; p=quarantine; sp=quarantine; rf=afrf; adkim=r; aspf=r;"

See Also

External References

This content was last updated on December 11, 2020
An error has occurred. This application may no longer respond until reloaded. Reload 🗙