How to setup DMARC for your domain

To use DMARC you need to add DNS record with DMARC policy. Please find the example record below:

Host name Type TTL Value
_dmarc.example.com TXT 3600 "v=DMARC1; p=none; rua=mailto:yourname@example.com; ruf=mailto:yourname@example.com; fo=1"


For the specifics of building DMARC record that suits your needs please refer to the Microsoft provided table below:

Tag

Purpose

Options

v

Version – Required

DMARC1

p

Policy – Required

none: No specific action be taken regarding delivery of messages.

quarantine: E-mail that fails DMARC check should be considered suspicious.

reject: E-mail that fails DMARC check should be rejected.

sp

Policy for all the subdomains – Optional, defaults to the parent domain policy if omitted.

none: No specific action be taken regarding delivery of messages – useful for monitoring.

quarantine: E-mail that fails DMARC check should be considered suspicious.

reject: E-mail that fails DMARC check should be rejected.

adkim

Indicates whether strict or relaxed DKIM Identifier Alignment mode is required – Optional, defaults to r if omitted.

r: relaxed mode – Both the authenticated signing domain and the sender domain can be a subdomain of each other to be considered aligned.

s: strict mode – Only an exact match between both of the domains is considered to produce Identifier Alignment.

aspf

Indicates whether strict or relaxed SPF Identifier Alignment mode is required – Optional, defaults to r if omitted.

r: relaxed mode – Both the authenticated signing domain and the sender domain can be a subdomain of each other to be considered aligned.

s: strict mode – Only an exact match between both of the domains is considered to produce Identifier Alignment.

rua

Addresses to which aggregate feedback is to be sent – Optional

E-mail addresses in the format mailto:mbx@domain.com. Multiple addresses should be comma separated.

ruf

Addresses to which message-specific failure information is to be reported – Optional

E-mail addresses in the format mailto:mbx@domain.com. Multiple addresses should be comma separated.

rf

Format to be used for message-specific failure reports – Optional, defaults to afrf if omitted.

afrf: Authentication Failure Reporting Using the Abuse Reporting Format, as described in RFC 6591.

iodef: Incident Object Description Exchange Format, as described in RFC 5070

ri

Interval requested (in seconds) between aggregate reports – Optional, defaults to 86400 if omitted.

32-bit unsigned integer, from 0 to 4,294,967,295.

fo

Provides requested options for generation of failure reports – Optional, defaults to 0 if omitted.

0: Generate a DMARC failure report if all underlying mechanisms fail.

1: Generate a DMARC failure report if any underlying mechanism produced something other than an aligned "pass" result.

d: Generate a DKIM failure report if the message had a signature that failed evaluation.

s: Generate an SPF failure report if the message failed SPF evaluation.

pct

Percentage of messages to which the DMARC policy is to be applied. It allows to enact a slow rollout enforcement of the DMARC mechanism. – Optional, defaults to 100 if omitted.

Integer between 0 and 100, inclusive

Was this article helpful?
0 out of 0 found this helpful

Comments

0 comments

Article is closed for comments.