Implement DMARC

DMARC is built on top of two existing mechanisms, SPF and DKIM. It allows the administrative owner of a domain to publish a policy on which mechanism (DKIM, SPF or both) is employed when sending email from that domain and how the receiver should deal with failures.

At a high level, DMARC is designed to satisfy the following requirements:
  •     Minimize false positives.
  •     Provide robust authentication reporting.
  •     Assert sender policy at receivers.
  •     Reduce successful phishing delivery.
  •     Work at Internet scale.
  •     Minimize complexity.
Anatomy of a DMARC resource record in the DNS
DMARC policies are published in the DNS as text (TXT) resource records (RR) and announce what an email receiver should do with non-aligned mail it receives.

Implement a DMARC policy of 'none'

Steps to set up and implement a DMARC record

Contact your company's Domain Name System (DNS) administrator.
Ask your DNS administrator to create a TXT record in DNS for _dmarc.[your-domain] with your DMARC record.
Use the following syntax in the DMARC TXT record:
        v=DMARC1; p=none; fo=1; rua=mailto:enter your email address; ruf=enter your email address 
For example: 
Be sure to enter your email addresses after "mailto:". These addresses are where the reports are sent.
If you are working with an ESP or other third party who will receive the DMARC reports on your behalf, ask your account representative which email addresses you should use.
This is the suggested record for when you first implement DMARC.
        v=DMARC1 indicates the protocol version.
The suggested DMARC record above includes a monitor policy (p=none). This means that you are not instructing mailbox providers to take any action with your email that fails authentication. 
        fo lets mailbox providers know you want message samples of emails that failed either SPF and/or DKIM. For the value:
                Use 0 to receive a report if both SPF and DKIM fail. (default)
                Use 1 to receive a report if either SPF or DKIM fail. (recommended)
         rua contains the address where you want to receive aggregate reports.
         ruf contains the address where you want to receive forensic reports.
To begin receiving DMARC reports without impacting your current email program, we suggest publishing the record with p=none. 
Make sure you have at least an A record, Mail Exchange (MX) record, or AAAA record in the DNS for the domain if you plan on using it to send email.
After you implement DMARC, we recommend that you monitor your domains for at least 30 days. This can help you make sure that your own legitimate email is authenticating correctly before you decide to implement a reject (p=reject) or quarantine (p=quarantine) policy.
Reporting destination information
DMARC supports the ability to send reports to multiple destination addresses. However, you should avoid using more than two different destinations as many mailbox providers do not send reports to more than two. 
In the case that multiple email addresses are needed for DMARC reports, each destination must be outlined within the RUA and RUF statement blocks in the DMARC record. Additionally, each destination needs to be delineated with a comma within the RUA and RUF blocks. 
Note: Do not list multiple RUA and RUF statements otherwise your DMARC record will be considered incorrect and reports will not be generated.
Correct DMARC record example with multiple reporting destinations:
    v=DMARC1; p=none; fo=1;,;,
Incorrect DMARC record example with multiple reporting destinations:

Implement a DMARC policy of 'quarantine'

In quarantine mode users still receive the mails (as opposed to the 'reject' policy) but they are directly sent in the spam/junk mailbox.

Users need to manually recover a suspicious mail and can afterwards mark it as 'safe'. You should update your records accordingly.
More information about DMARC can be found here:


Implement a DMARC policy of 'reject'

Consider an example DMARC TXT RR for the domain “” that reads:

In this example, the sender requests that the receiver outright reject all non-aligned messages and send a report, in a specified aggregate format, about the rejections to a specified address.
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                                                        v=DMARC1
pct       Percentage of messages subjected to filtering        pct=20
ruf       Reporting URI for forensic reports                  
rua       Reporting URI of aggregate reports               
p          Policy for organizational domain                              p=quarantine
sp        Policy for subdomains of the OD                             sp=reject
adkim  Alignment mode for DKIM                                       adkim=s
aspf     Alignment mode for SPF                                          aspf=r