DMARC (Domain-based Message Authentication, Reporting and Conformance) is a protocol that uses DKIM (Domain Keys Identified Email) and SPF (Sender Policy Framework) to prevent spam, domain spoofing and phishing via email messages.
DMARC determines the authenticity of an email message by using DKIM and SPF and allows senders to decide how to handle messages that weren’t properly authenticated.
Recipients can then either mark the unauthenticated messages as spam or block them completely.
This helps ISPs (Internet Service Providers) identify spammers more easily, filter malicious emails, prevent brand abuse and have better authentication reporting.
All major email providers (Google, Microsoft 365, Yahoo) support DMARC.
How does DMARC work?
DMARC is a TXT DNS record defined under the _dmarc subdomain of the primary domain. It allows you to configure DMARC policies and where to receive the DMARC report.
Here’s how the typical DMARC record looks like:
_dmarc.yourdomain.com TXT v=DMARC1\; p=none\; pct=100\; rua=mailto:[email protected]\; sp=none; aspf=r;
DMARC components
Here’s a short description of various DMARC record components:
v=DMARC1
v is a version component. Version is checked by the receiving server each time it receives mail. If the sending domain doesn’t contain a TXT record that starts with v=DMARC1 – the receiving server will not run a DMARC check.
p=none
p is a policy component. The policy set in the DMARC record will tell the recipient email server what to do with mail that doesn’t pass SPF and DKIM checks but pretends to originate from the sending domain.
There are three types of policies that can be configured:
none – This will perform no actions against the mail message but send an email report to the email address set in the mailto: section of the DMARC record.
quarantine – This will quarantine the mail message, effectively sending it to the spam folder.
reject – This will completely reject all emails sent from the specific domain. If this policy is enabled, only messages that are 100% verified as being legitimately signed by your domain will be received. Please note that the mail server will automatically reject any emails that don’t pass this check.
rua=mailto:[email protected]
rua is a report component (aggregate). It tells the recipient where to send aggregate reports of DMARC failures. Aggregate reports include high-level information about the DMARC failures and are sent once per day to the administrator of the domain set in the DMARC record.
ruf=mailto:[email protected]
ruf is another report component (forensic). This section tells the mail server where to send forensic reports of DMARC failures. These reports contain all details about the individual failures and are sent in real-time to the administrator of the domain set in the DMARC record. Please note that you need to use the email address configured on the primary domain in this component.
rf=afrf
rf is a reporting format. This component tells the mail server which reporting the policyholder wants. afrf, for example, means an aggregate failure reporting format.
pct=100
pct is a percent component. You can use any number from 1-100, and it tells the recipient how much of their email should be checked against DMARC policies. If the p= component is set to reject, the mail server will reject 100% of the mail that fails DMARC.
Here are a couple of other mechanisms that can be used in a DMARC record as well:
sp=
sp is a subdomain policy component. It specifies if the DMARC policy is applied to subdomains as well.
adkim=
adkim is a DKIM alignment component. DKIM alignment can either be strict (“s”) or relaxed (“r”).
If strict checking is enabled, the authentication will pass only if the d= field in the DKIM signature 100% matches the from domain.
If relaxed checking is enabled, the authentication will pass if the DKIM d= field matches the address’s root domain.
ri=
ri is the report interval component. It specifies how often you want to receive aggregate reports about DMARC failures.
Do you need DMARC on your domain?
It depends.
If you’re a small business or don’t have any problems with unsolicited/spam emails, phishing attempts and malicious emails – you’ll probably be fine without DMARC.
If you have a business in the financial services industry or handle sensitive information through email, you should consider using DMARC to protect your customers‘ data.