Creating a DMARC policy



Domain-based Message Authentication, Reporting, and Conformance (DMARC) is an inbound email policy built on top of DKIM and SPF records, designed to detect and prevent fraudulent emails.

When you add a DMARC policy to your domain, you choose to inform the recipient that your emails are protected by DKIM and/or SPF records and what to do if your DMARC policy fails alignment with those records.

Example of the DMARC validation process

  1. The sender adds a DMARC policy to their domain.
  2. The sender sends an email.
  3. The recipient checks if the email contains a DMARC policy.
  4. The recipient checks if the DKIM/SPF records mentioned in the sender's DMARC policy are valid.
  5. The recipient checks if the valid DKIM/SPF records also pass something called 'alignment'.
    • If 'alignment' is passed, the email is received.
    • If 'alignment' is not passed (even if DKIM/SPF checks are passed), then the message fails.

This process of validation helps to ensure that fraudulent activity appearing to come from the domain is blocked.

Configuring a DMARC policy

The following steps explain how to configure a DMARC policy on your domain.


Step 1 — Create report emails

Create two separate email addresses to receive DMARC daily aggregate and forensic reports. It’s recommended you create two email addresses since you may receive a large number of reports. For example:


Step 2 — Create DKIM and SPF records

Configure a DKIM and/or SPF record on your domain. It's recommended that you enable both records to take full advantage of the DMARC policy. See the following articles for more information:

Step 3 — Add the DMARC record in the panel

  1. Navigate to the Manage Websites page.
  2. Click the Manage button to open the Domain Settings page, which allows you to adjust various settings for your site.
    • If in Grid view, click the Manage button at the bottom of the website box.
    • If in List view, click the Manage button at the far right of your domain name.
    DNS tab
  3. Click the DNS tab.
  4. Click the Add Record button.
  5. Hover over the TXT Record section and click the ADD link.
  6. Enter the following:
    • Host: _dmarc
    • TXT Value * — Below is a basic configuration that handles the majority of your DMARC needs. Just make sure to adjust the email addresses to the addresses you created above to receive incoming reports.
      v=DMARC1; p=quarantine; fo=1;;;pct=100
      View the 'DMARC Tags' section below for further details on the different options you can use.
  7. Click the Add Record button to save.

After clicking the Add Record button, the propagation for the new record begins. This can take up to 6 hours before the new record updates online.

What is alignment?

The DMARC policy checks the domain name listed in the message's From: field. It then compares that domain to other authenticated domain names listed in the email's header. If they are identical, your DMARC policy is aligned.

If not, you should contact your email host and ask for instructions on ensuring your records are aligned.

Strict and relaxed alignment

The alignment in your policy can be set as strict or relaxed:

  • Strict alignment — the domains must be identical
  • Relaxed alignment — the top-level 'Organizational Domain' must match

The 'Organizational Domain' is your domain name followed by its suffix. For example:


What if the message fails alignment?

The sender's DMARC policy contains report email addresses (set in the rua and ruf tags) to handle emails that fail authentication. Two types of reports can be created:

  • Aggregate reports — These reports are sent in XML format once a day, consisting of aggregate data of all DMARC failures. This email address is set with the rua tag.
  • Forensic reports (aka failure reports) — These reports are generated immediately and consist of individual emails that failed. This email address is set with the ruf tag.

Analyzing the reports

You can use a tool like the following to analyze your reports:

Testing received emails for alignment

The following steps check received email headers to confirm if they will pass alignment:

  1. Send an email to yourself (or another address you own).
  2. View the received email's headers.
  3. Verify domain alignment by identifying the domain listed as the sending address. It may be located in the following places:
    Field Example
    The Envelope From domain From:
    The Return-Path <>
    The d=domain in the DKIM-Signature DKIM-Signature: v=1; a=rsa-sha1; c=relaxed;;

    The domains mentioned in all of these areas must be identical, otherwise, DMARC will fail alignment.


DMARC records use tags to define how the DMARC record should be implemented. Of the 11 tags available, only 2 are required, but others are recommended. View the information below for further details.

Required tags

The v and p tags are required.

The v tag

Tag Description
v=DMARC1 The v tag identifies the text record as a DMARC record. This must be the first tag and have a value of DMARC1.


The p tag

The p tag identifies the action the domain owner requests the recipient to take for failed messages.

It's recommended to start out using p=none and for at least one week. This allows you to receive daily reports without messages being rejected or marked as Spam.

During this initial time period, you can review the reports to see if valid emails are being rejected or going to Spam, allowing you to resolve any issues in the DMARC policy.

When you're comfortable with the incoming reports and what email is getting flagged, you can then change this to p=quarantine.

Options are:

Tag Description
p=none No action should be taken for emails that fail DMARC authentication.
p=quarantine If an email fails DMARC authentication, it should be treated as suspicious. How this is handled is up to the recipient. For example, it may be placed in a SPAM folder.
p=reject If an email fails DMARC authentication, the recipient should reject the email during the SMTP transaction.


Email tags (Recommended)

These indicate where reports are sent.

Tag Description The address where aggregate DMARC reports should be sent to. The address where forensic DMARC reports should be sent to.


Optional tags

The following tags use a default value if the tag isn't set.


Sets a DKIM identifier alignment mode. This determines how strictly DKIM signatures ( must match the domain the email is sent from.

Tag Description

relaxed mode (default): This allows subdomains to send email. For example, it will validate if the email is sent from an address specified in the DKIM record ( or a from a subdomain (

adkim=s strict mode: This prohibits subdomains from sending email. It will only validate if the email is sent from an address specified in the DKIM record ( 



Sets a strict or relaxed SPF identifier alignment mode. This determines how strictly SPF signatures must match the domain the email is sent from. This can be seen in the email headers by comparing the Mail-From address (also known as the Return-Path) and the From address fields.

Tag Description
aspf=r relaxed mode (default): This allows subdomains to send email.
aspf=s strict mode: This prohibits subdomains from sending email. 


rf, ri, and pct

Tag Description
rf=afrf The Report Format for failure reports. The only current option is Authentication Failure Reporting Format, or afrf).
ri=86400 Sets the number of seconds between sending aggregate reports. (The default value is 86,400 seconds, or one day).

Sets the percentage of messages DMARC is applied to. View DMARC Percentage Tag for more information.



Failure Reporting Options (fo) controls when a failure report is created. The ruf tag must also be defined for this tag to function.

Tag Description
fo=0 Creates a report if DKIM and SPF authentication steps fail. (Default)
fo=1 Creates a report if either DKIM or SPF authentication steps fail.
fo=d Creates a DKIM failure report if the message fails DKIM validation.
fo=s Creates an SPF failure report if the message fails SPF validation.

A setting of fo=1 is recommended as it provides the most amount of data about any failures.



The Subdomain Policy (sp) tag is used to set a different reporting policy for a subdomain. If not set, the p tag will be applied to all subdomains.

For example, you could set the primary domain to use p=reject while setting all subdomains under this domain to use sp=quarantine.

Tag Description

Deliver messages that fail authentication from this subdomain.

sp=quarantine Mark messages as SPAM that fail authentication from this subdomain.
sp=reject Reject messages that fail authentication from this subdomain.

See also

Did this article answer your questions?

Article last updated PST.

Still not finding what you're looking for?