DMARC stands for Domain-Based Message Authentication, Reporting, and Conformance. It is a type of DNS record that tells other email servers that your domain is using DKIM and SPF records to prevent email spoofing. When you send email, receiving email servers inspect the DKIM and SPF records and compare them to the information in the email. DMARC records go one step further and tell receiving email servers what to do if an email fails the DKIM and SPF checks.

Email can fail these checks for various reasons. Where spam-fighting efforts are concerned, email can fail authentication because it’s not actually coming from your server. Instead, its coming from a spammer who’s spoofing your email address. Emails can also become corrupted accidentally when they are being sent between servers: much like packages can get battered in the mail.

DMARC can help with your email reputation, but it is not widely used. SPF and DKIM records alone have a much bigger impact on email reputation. You usually do not need DMARC records unless an RBL says DMARC is the specific reason your mail is blocked. DMARC is also useful if you plan on taking a hands-on approach to managing the email you send. When you set up DMARC records, you can choose to receive reports showing the sent email that was rejected for authentication failures.

If you decide you’d like to add DMARC records to your domain’s DNS records, it’s exactly the same as adding other DNS records, including SPF and DKIM records. Make sure you have added DKIM records and SPF records before you start creating your DMARC record. DMARC records will do nothing if you don’t already have SPF and DKIM records.

Because you’ve already added multiple DNS records to your DNS, this article will focus on different DMARC record formats instead of step-by-step instructions for adding to your DNS. Remember that you need to add the records where your DNS is hosted.

DMARC Record Formatting

By now, you’re familiar with the standard format for DNS records: Name, Time to Live (TTL), Record Type, and Record Data.

mysite.com.    3600    IN    NS    ns.liquidweb.com

DMARC records follow the same format, but add “_dmarc.” before your domain and use different flags in the record data.

_dmarc.mysite.com.	300	IN	TXT	"v=DMARC1; p=none"

The above record is the simplest DMARC record you can have with only the two required flags, v= and p=. There are many different flags you can use. When using multiple flags, separate each flag with a semicolon and enclose the whole text string in quotation marks.

Required DMARC Record Flags

These required flags should always come first in your DMARC record.

v= is a required tag that marks this DNS record as a DMARC record. It should always be the first tag in your record. The default data is “v=DMARC1” and this is case-sensitive.
p= sets a rule for mail that fails the DMARC authentication process. There are three options for this:
- p=none means no special action will be taken.
- p=quarantine means email that fails DMARC authentication will be considered suspicious. Depending on the email client, this mail will be placed in the spam folder or marked as suspicious.
- p=reject means all email that fails DMARC checks will be rejected.

Common Optional DMARC Record Flags

If you need more involved DMARC records, there are many optional flags you can use after the v and p flags. These are the most useful optional tags. The DMARC website has a current list of every flag.

adkim= determines whether or not strict DKIM identifier alignment is required.
- adkim=s is strict mode
aspf= determines whether or not strict SPF identifier alignment is required.
- aspf=s is strict mode
pct= Percentage of messages that will be checked against DMARC. This flag allows you to slowly roll out enforcement of the DMARC mechanism. You can start with a low percentage of your mail being checked and slowly increase the percentage. You can enter any integer between 1 and 100.
ri= is the time, in seconds, between reports about email that failed DMARC checks. The default number is 86400, which is 24 hours.
rua= is the email address where reports are sent. Generally, it’s best that this is an email address on the same domain. The email address should be formatted as a URI: mailto:myname@mysite.com.

Example DMARC Records

You can put different flags together to create your own DMARC records. But, here are the most commonly used DMARC records so you can simply copy them into your DNS. Make sure to replace “mysite.com” with your own domain.

Non-Reporting DMARC

Most people don’t need DMARC records at all, but if you’ve been added to an RBL for not having a DMARC record, this is a good generic record to add. You won’t receive any reports, and you won’t require that mail that fails DKIM/SPF checks is rejected.

_dmarc.mysite.com.	300	IN	TXT	"v=DMARC1; p=none"

Monitoring DMARC

If you want to be more hands-on with your email management, you can start receiving reports about email that fails DMARC checks. But, if a message claims to be from your domain and fails DMARC checks, there will still be no action taken. In this record, replace both the domain name and email address with your own information.

_dmarc.mysite.com.	300	IN	TXT	"v=DMARC1; p=none; rua=mailto:postmaster@mysite.com"

Quarantining DMARC

In this example, if an email message is sent by a domain that fails SPF/DKIM record checks, then 5% of the emails should be quarantined by the mail server. You’ll also receive a daily report about what emails are failing these checks. You can continue increasing this percentage over time.

_dmarc.mysite.com.	300	IN	TXT	"v=DMARC1; p=quarantine; pct=5; rua=mailto:postmaster@mysite.com"

Rejecting DMARC

Once you’re familiar with how your mail is being sent and you are comfortable reading DMARC reports, you may want to start rejecting mail that fails DKIM/SPF checks. Remember: this means that every email you send will be checked against your DKIM and SPF records. If someone is trying to spoof your email address, the mail will be rejected. But this also means legitimate email could occasionally be rejected. In this example, if an email message is sent and fails SPF/DKIM record checks, then the message should be rejected by the mail server. The daily report of rejected mail is emailed to “postmaster@mysite.com.”

_dmarc.$domain.com.	300	IN	TXT	"v=DMARC1; p=reject; rua=mailto:postmaster@your_domain.com"

Testing Your DMARC Records

Once you’ve put a DMARC record in place, you want to monitor your email to make sure it’s working properly. This is why DMARC has such robust reporting capabilities. You can also use an online checker immediately after adding a DMARC record. An online checker will make sure your record has the information you need.

Was this article helpful?

Thank you for your input.

Thank you for your feedback.