Enabling DMARC (Domain-based Message Authentication, Reporting and Conformance)

Covering the basics of DMARC

The most important things to consider when enabling DMARC are 1 – to make sure you got SPF + DKIM right and 2 – wisely define your policy. If you get any of those two wrong, there can be a lot of noise.

 

For the first part, we recommend you to test your SPF and DKIM implementation before moving forward with DMARC. We will help you with the second part.

 

The table below summarizes the options you have when configuring your DMARC policy:
 
 
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

 

You can use one of the DMARC record assistant listed at DMARC Deployment Tools. They can greatly reduce the chances of misspelling. However, you have to understand the options you have on the table above.

 

DMARC implementation best practices

We recommend you to follow the best practices below when implementing DMARC:

  1. Form the DMARC TXT record using one of the DMARC record assistant listed at DMARC Deployment Tools
  2. Start monitoring the impact of DMARC applying a monitoring-only policy (p=none). You can do this even before implementing SPF and DKIM, as it can give an insight of what is going to happen when you implement those mechanisms.
  3. Move to quarantine policy after the testing phase (p=quarantine).
  4. Only request that external mail systems not accept messages that fail DMARC (p=reject) if it makes sense for you and after extensive testing.

 

Form and deploy the DMARC TXT record

  1. Define the DMARC policy you want to apply.
  2. Use one of the record assistant listed at DMARC Deployment Tools to build the DMARC TXT record.
  3. Select the options according to the policy you defined.
  4. Publish the DMARC TXT record in your external DNS zone
    For example, we can use the DMARC TXT record below for contoso.com:

     

     TXT Name: _dmarc.contoso.com
    
     Value: "v=DMARC1; p=none; rua=mailto:rua@contoso.com; ruf=mailto:ruf@contoso.com; fo=1"
  • Office 365, DMARC, DKIM, SPF, Outlook
  • 0 Users Found This Useful
Was this answer helpful?

Related Articles

Downloading and Installing the Office Suite

This article is for all active Office365 Users who have purchased a Premium Plan with BaseHost....

Accessing a Shared Mailbox using the Office 365 Portal

Members of a Shared Mailbox's permissions group have the ability to access a Shared Mailbox using...

OneDrive for Business

OneDrive for Business offers BaseHost Office 365 customer access to cloud storage using your...

Set the password expiration policy for your organisation

As an admin, you can make user passwords expire after a certain number of days, or set passwords...

Set up email in Android email app

Android mail apps may look different across different devices, and these directions may not...