• v: This is the version tag that identifies the record retrieved as a DMARC record. It's value must be DMARC1 and be listed first in the DMARC record.
  • p: This is the tag that indicates the requested Policy you wish mailbox providers to apply when your email fails DMARC authentication and alignment checks. The policy is applied to a primary domain (example.com) and all of its subdomains (m.example.com, b.example.com, etc), unless the sp tag is used (see below) with a different policy value. The different policy values are:
    • none - This policy, which is referred to as monitor, means that the mailbox provider won't take any actions with your emails that fail DMARC
    • quarantine - This policy means that you want to have all emails that fail DMARC to be treated by mailbox providers as suspicious. Quarantining an email can mean that the email is delivered into an area outside of the inbox, such as the spam or junk folder.
    • reject - This policy indicates you want mailbox providers to reject all emails that fail DMARC

Optional but recommended tags

  • rua: mailto:address@company.com: This is a tag that lets mailbox providers know where you want aggregate reports to be sent. Aggregate reports provide visibility into the health of your email program by helping to identify potential authentication issues or malicious activity. These reports contain higher level information and are sent by participating mailbox providers daily.
  • fo: This is a tag that lets mailbox providers know you want message samples of emails that failed either SPF and/or DKIM. There are four value options available: 
    Note: Requires the ruf tag to be set up
    • 0: Generate a DMARC failure report if all underlying authentication mechanisms (SPF and DKIM) fail to produce an aligned “pass” result. (default)
    • 1: Generate a DMARC failure report if any underlying authentication mechanism (SPF or DKIM) produced something other than an aligned “pass” result. (recommended)
    • d: Generate a DKIM failure report if the message had a signature that failed evaluation, regardless of its alignment.
    • s: Generate an SPF failure report if the message failed SPF evaluation, regardless of its alignment.

Optional tags

  • sp: This tag is used to indicate a requested policy for all subdomains where mail is failing the DMARC authentication and alignment checks. It is most effective when a domain owner wants to specify different policies for the primary domain and all subdomains. The policy options are the same as the "p" tag listed above. If this tag is not used for subdomains, the policy set using the p tag will apply to the primary domain and all of its subdomains.
  • adkim: Indicates strict or relaxed DKIM identifier alignment. The default is relaxed.
  • aspf: Indicates strict or relaxed SPF identifier alignment. The default is relaxed.
  • pct: The percentage of messages to which the DMARC policy is to be applied. This tag provides a way to gradually implement and test the impact of the policy.
    • Values are integers ranging from 1 - 100. The default value is 100.
  • ruf=mailto:address@company.com: This tag that lets mailbox providers know where you want your forensic (message-level) reports to be sent. Forensic reports are more detailed and are intended to be delivered by mailbox providers almost immediately after detecting a DMARC authentication failure. However, due to potential privacy and performance concerns, most mailbox providers do not send them.
  • rf: Format for message failure reports. The default is Authentication Failure Reporting Format, or “afrf.” Afrf is the only value supported at this time.
  • ri: The number of seconds elapsed between sending aggregate reports to the sender. The default value is 86400 seconds which is equivalent to one day. Participating mailbox providers that are able to accommodate sending more than one aggregate report per day will provide more frequent reports on a best-effort basis. 

More on the Policy tag

It is always advisable to use the none policy when first setting up DMARC. This policy will not impact delivery and will not protect you from others abusing your domain. The purpose of this policy is to gather information on the use or abuse of the From header domain. This is done through the automatic reports sent by providers. This policy is useful for making inventories of legitimate hosts and for checking the alignment and authentication results of these hosts.


Once this is done, the next logical step is to implement the quarantine policy. This policy will advise the provider to send the email directly to the junk folder should DMARC fail. Note that we write advise. People often assume that the policy is definitive. It isn’t. In most cases, the provider will follow the policy, but it can override the policy if it has reason to do so. One example of a provider overriding the policy is if Google detects a false-positive. A quarantine policy may protect you, but a phishing attack will reach the recipient’s junk folder. However, the quarantine policy should ensure that all legitimate emails reach their final destination.


The reject policy is the strictest of the three options. If an email does not pass the DMARC check, it will be rejected. The recipient will never see the email. In the case of a false-positive, the email will also be rejected. This means that senders will have a certain percentage of legitimate emails that never reach the intended recipient.


How can I be sure it's working?

You can easily test this on this page : https://mxtoolbox.com/dmarc.aspxby entering your domain, such as mycompany.com and you may get a result such as:


v=DMARC1; p=none; rua=mailto:email@domain.com


The test will also list any errors or warning and recommend how to resolve them.