Information about DMARC (Domain-based Message Authentication, Reporting and Conformance)
Published Date : 24 May 2022
Last Updated : 03 Oct 2024
Content Ref: TEC8570415
Operating System
Microsoft Office 365
Part No
(none)
Summary
Provides information about DMARC (Domain-based Message Authentication, Reporting and Conformance).
Requirements
What is DMARC and why do we need it?
DMARC (Domain-based Message Authentication, Reporting and Conformance) is a widely accepted email authentication policy and reporting standard. DMARC works with SPF (Sender Policy Framework) and DKIM (DomainKeys Identified Mail) to authenticate email senders and ensure that the destination email systems trust messages that are sent from your domain. By implementing DMARC, SPF and DKIM, you add additional protection against spoofing and phishing email sent from your domain. DMARC helps receiving email systems to determine what to do with messages sent from your domain that fail SPF or DKIM checks.
What are the steps involved in implementing DMARC for your email domain?
You need to identify valid sources of email senders for your domain. For example, if there is a third party who sends emails on your behalf, you need to know their domain and public IP from which the emails are sent.
Set up an SPF record for your domain. Ensure that you include valid sources of email senders of your domain identified from step 1 above in your SPF record.
Set up DKIM for your domain.
Set up a DMARC TXT record for your domain.
Analysis of DMARC reports.
Note: The configuration requirements are likely to be different if you are using some form of email checking/ security service, such as Trend Micro Email Security, Mimecast and Titan.
What DMARC record tags do you need for your domain?
A DMARC record is typically inserted as a TXT record alongside your other public DNS records. Given below is an example of a DMARC record for the domain 'myschool.com'.
Name
_dmarc.myschool.com
Value
v=DMARC1; p=none; rua=mailto:address@myschool.com
Type
TXT
TTL
3600
Overview of mandatory and recommended DMARC tags that are available for use in a DMARC record:
v=DMARC1: DMARC version identifier.
p=: The policy tag that tells the receiving server what to do with a message that fails DMARC authentication. There are three values:
p=none: Receiver takes no action.
p=quarantine - Receiver will treat the email as suspicious and send it to spam/junk folder.
p=reject- Receiver rejects the email (does not deliver it).
rua=mailto: Tells the receiver where to send the DMARC aggregate reports. Aggregate reports provide the most valuable information provided by DMARC.
Overview of optional DMARC tags:
sp=: Defines the policy for subdomains. Subdomains will inherit the parent policy by default. This tag is not needed unless you have subdomains that need different policies than the parent domain.
adkim=: Indicates strict or relaxed DKIM identifier alignment. The default is relaxed.
aspf=: Indicates strict or relaxed SPF identifier alignment. The default is relaxed.
pct=: Indicates the percentage of messages to which the DMARC policy is to be applied. The default value is 100, so all the messages are subject to the policy.
ruf=mailto: Tells the receivers where to send DMARC failure reports. Failure reports are detailed reports generated each time a message fails authentication. As this may include personal identifiable information (PII), none of the major mailbox providers (e.g. Google, Microsoft, etc.) generate these reports anymore.
For more information about DMARC reports, please refer to TEC8571263 in the Other Useful Articles section below.