What is DMARC?
DMARC (Domain-based Message Authentication, Reporting and Conformance) is an email authentication protocol that lets an email domain owner configure how receiving servers should handle messages detected as spoofing that domain—for example, sending them to spam, quarantining them, or rejecting them outright. It also reports successful or failed authentication results to a designated mailbox.
For example, my email domain is li-yang.cn, and I have configured the DMARC policy “v=DMARC1; p=quarantine; ruf=mailto:i@li-yang.cn; aspf=s;”. If someone sends email pretending to be from my domain, and the system receiving the spoofed message supports DMARC, the message will be quarantined and I will receive the report about the spoofed email generated by that system.
DMARC policies are very effective for businesses monitoring spoofed email and commercial fraud. At the same time, a recipient that follows the sender’s DMARC policy and processes and reports messages promptly can avoid being deceived by spoofed email.
Why enable DMARC?
In simple terms, it collects records of messages sent while pretending to be your domain or mailbox, and applies policies you configured in advance to that impersonation.
How does DMARC work?
Assume that Zhang San wants to impersonate Li Si at my company (li4@li-yang.cn) and send a phishing email to Wang Wu at Company B (wang5@li-yang.cn). Because of the way SMTP itself works, the customer’s server does not authenticate messages when it receives them. If my company’s server has no SPF, DKIM, or DMARC configured (and we set aside any custom protections on the customer’s mail server), Wang Wu will receive the spoofed message normally and be successfully tricked.
Suppose my company has correctly configured SPF (or DKIM) and DMARC. When the customer’s mail server receives the message, it first checks whether the SPF for my company’s domain matches the IP address of the previous hop that delivered the message. If they match, SPF passes; otherwise, it fails. What happens after SPF fails? Ignoring the server’s default SPF policy, if DMARC is enabled, the customer’s mail server queries the TXT record at _dmarc.li-yang.cn on Company A’s server. The record is “v=DMARC1; p=quarantine; ruf=mailto:security@li-yang.cn”. It sees that the action is to quarantine and report to security@li-yang.cn, so the spoofed message is quarantined and promptly obtained by my company’s security team. Once the team learns that someone is impersonating my company, it can warn business partners through other channels and avoid losses.
How do you enable DMARC?
DMARC requires SPF or DKIM to be active. SPF is also configured through DNS records, while DKIM requires support from your mail provider. Once you have confirmed that at least SPF is configured, you can proceed with DMARC. (If SPF is not configured, refer here.) If SPF is enabled, continue below:
DMARC has powerful policy options and can evaluate SPF and DKIM results. If you want to save time, I strongly recommend using an online DMARC generator to automate the record, and these sites usually parse DMARC reports as well. Examples include DMARCLY, DMARCIAN, and MXToolBox. If you want to write a DMARC policy manually, keep reading.
- DMARC format
As mentioned above, a DMARC policy is a TXT DNS record. It is expressed as key-value pairs separated by semicolons. It starts with the fixed value “v=DMARC1”, which indicates that the record follows the DMARC protocol, followed by p=, the mail-handling policy, and then more detailed options. - Mail-handling policy
There are three policy options. During initial deployment, businesses are advised to use none, which reports only and takes no action, because a company may have third-party systems sending mail in its name without being added to SPF in time or without DKIM configured correctly—for example, company-news subscriptions, third-party HR systems, or bulk notifications. Individual users who have confirmed that they use no third-party senders can configure “quarantine” to have recipients isolate spoofed messages, or “reject” to reject them outright. After observing for a while and confirming that legitimate messages are not being misreported—or adding SPF when an issue is found—a business can gradually enable “quarantine” or “reject”. - Receiving reports
There are two kinds of reports. One is an aggregate report, a summary sent every 24 hours of messages received that passed and failed DMARC during the day. The XML report includes the sending mail server’s IP address, the number of passes and failures, and the reasons; configure this with “rua”, for example, “rua=mailto:aggregate_report@li-yang.cn”.
The other is an individual report for an authentication failure. In my experience, some servers send the failed message directly as an attachment, which makes further investigation easier for administrators. Configure this type with “ruf”, for example, “ruf=mailto:failure_report@li-yang.cn” - Other detailed policies
DMARC also supports configuring how SPF and DKIM are aligned, such as checking only SPF, only DKIM, or both, for four combinations in total. You can configure the percentage of DMARC-covered mail to which the policy applies; if you are worried about recipients blocking too much mail during initial deployment, lower the percentage first. DMARC can also configure whether the policy applies to subdomains. For detailed configuration, refer to DMARCLY, DMARCIAN, and MXToolBox.
Configuring SPF
SPF configuration is also an SPF DNS record, much like DMARC, though it is considerably simpler: you only need to organize a list of mail-sending server IP addresses. The addresses can be written directly as IP addresses, include other SPF records, or configure lookups for other domains’ A and MX records. For example, if my mailbox’s sending server IP is 224.0.1.1, the SPF record could be “v=spf1 a:224.0.1.1 ~all”. In reality, my domain uses Tencent’s domain mailbox service. After checking the official Tencent documentation, I can use “v=spf1 include:spf.mail.qq.com ~all”.
What does “～” mean here? Like DMARC, SPF also lets you configure a policy. “+” means pass and is the default, so it can be omitted; “～” means a soft fail, similar to DMARC’s p=none, and is usually used for debugging during initial deployment. “-” means a hard fail, or reject; “?” is a neutral result meaning that there is no policy. Of course, these policies are only recommended handling instructions for recipients. The receiving server may well have its own default rules, such as quarantining every message that fails SPF.