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:[e-mail]; ruf=mailto:[e-mail]; 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:[e-mail]. 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:[e-mail]. 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