DMARC Policy: Why p=none is a bad choice
DMARC (Domain-based Message Authentication, Reporting, and Conformance) plays a central role in protecting email domains against misuse. However, the correct configuration of a DMARC policy is crucial: a seemingly harmless setting such as ‘p=none’ can lead to considerable security risks. In this article, we explain why ‘p=none’ is not a good choice and what an effective DMARC record should look like.
DMARC (Domain-based Message Authentication, Reporting, and Conformance) is an official IETF standard. It was developed to protect email domains from misuse, especially spoofing and phishing. It supplements and extends the existing authentication mechanisms Sender Policy Framework (SPF) and DomainKeys Identified Mail (DKIM) with guidelines for email processing and reporting functions.
DMARC enables the sender of an email to provide additional information about the processing of the email sent. It informs the recipient
- how emails sent by them should be authenticated,
- what should be done with unauthenticated emails and
- to whom and how often reports should be sent back to the sender.
SPF, DKIM and DMARC: How are they connected?
SPF and DKIM can be used to ensure the authenticity and integrity of emails. However, neither SPF nor DKIM give the receiving server clear instructions on what to do with emails that have not passed the SPF and DKIM checks. This gap is closed by DMARC (Domain-based Message Authentication, Reporting and Conformance), provided that you have made the correct settings in the corresponding DMARC record.
What does a DMARC record look like?
The TXT record used for a DMARC policy can contain the following fields:
| Field | Description | Examples |
|---|---|---|
| v | Version of the DMARC entry | v=DMARC1 |
| p | Policy on how to handle emails from the main domain that fail authentication | p=none: no action p=quarantine: quarantine p=reject: reject |
| sp | Policy on how to handle emails of the subdomain whose authentication fails | p=none: no action p=quarantine: quarantine p=reject: reject |
| pct | Percentage of emails to be reported according to DMARC policy | pct=100 (default) |
| rua | Specifies whether and to which email address an aggregated report of the received emails should be sent | rua=mailto:report@example.com |
| ruf | Determines whether and to which email address a forensic report on the received emails is to be sent. This report contains all details about the respective emails. Take note of data protection. | ruf=mailto:report@example.com |
| fo | Failure Reporting Options. Detailed setting for when emails are to be reported. Only applies in connection with “ruf”. | fo=0: SPF and DKIM have failed (default) fo=1: SPF or DKIM have failed fo=d: DKIM is considered failed if the signature is not correct – even if the key matches. fo=s: SPF is considered failed if the SPF evaluation fails for any reason, even if the SPF records in the header and DNS record match. |
| rf | Reporting Format. The file format for the reports. Only applies in connection with “ruf”. | rf=afrf: Authentication Failure Reporting Format (default) rf=iodef: Incident Object Description Exchange Format |
| ri | Reporting Interval. Frequency in seconds at which reports are sent. | ri=86400, once a day (default) |
| aspf | Alignment mode for the SPF check | s=strict, i.e. strict. The ‘MAIL FROM’ address must exactly match the Header-From address. Example: info@example.com r=relaxed, i.e. loose. It may also be a subdomain. Example: info@newsletter.example.com For more information, see mxtoolbox. |
| adkim | Alignment mode for the DKIM check | see above |
p=none is worse than no DMARC policy at all
The different settings for the p field are crucial in these examples.
While all unauthenticated emails are rejected in the first example, nothing is done for unauthenticated emails to the main domain, which means that any protection offered by SPF and DKIM is lost.
This is not only problematic, but downright negligent: Senders of spam, phishing and malware emails specifically use domains as sender addresses that either have no DMARC policy or use p=none.
But that’s not all: p=none is even more problematic than having no DMARC policy at all, because gateways such as NoSpamProxy, which adhere to the RFCs, do not reject emails even if the SPF and DKIM checks fail, unless malware, spam or similar is found.
The reputation of your domain suffers
Attackers can continue to successfully send emails under your domain, which makes your domain vulnerable to phishing attacks and spam. In addition, your domain reputation will suffer if attackers misuse your domain for malicious purposes. This can lead to legitimate emails from your domain ending up in the spam folder or being blocked more frequently.
What is the point of p=none?
If p=none in a DMARC policy is dangerous and effectively makes DMARC ineffective, why does this setting actually exist?
The p=none setting can actually be useful, for example in an introductory phase of DMARC. With p=none, problems can be identified without blocking emails. This gives you an overview of the outgoing emails that are sent on behalf of your domain. If you have enough information in the form of DMARC reports, you can change the configuration and improve compliance to prepare for the transition to a stricter DMARC policy in your organisation.
In a test phase, you can collect reports and check whether SPF and DKIM are implemented correctly.
How to implement DMARC correctly
We recommend implementing DMARC in several steps. Start with simple monitoring of your domain and gradually expand the policy until all emails that do not pass the DMARC check are rejected (p=reject).
Step 1: Monitoring
Start with the pure monitoring of a subdomain and/or a main domain and request regular reports. The use of SPF and DKIM is not yet required for this step. The corresponding DMARC record could look like this:
‘v=DMARC1; p=none; sp=none; rua=mailto:report@example.com’.
Make sure to remove p=none at the end of the monitoring and change it to p=reject in step 3.
Step 2: Set up a quarantine policy
Before you perform this step, you must have fully implemented SPF and DKIM. Once this is done, set up a DMARC quarantine policy. This instructs the receiving servers to move emails from your domain that do not pass the DMARC check to the spam folder. The corresponding DMARC record could look like this:
‘v=DMARC1; p=quarantine; sp=quarantine; rua=mailto:report@example.com’.
Step 3: Reject all unauthenticated emails
In the last step, you instruct the receiving servers to reject emails from your domain that do not pass the DMARC check. The corresponding DMARC record could look like this:
‘v=DMARC1; p=reject; sp=reject; rua=mailto:report@example.com’.
Check your DMARC record
With the help of tools such as mxtoolbox, you can quickly and easily check whether a DMARC record exists for your domain.
How to set up a DMARC record and improve email security
With the help of DMARC, domain owners have improved control over their company’s electronic communication and improve the security of their IT infrastructure. Surveys have also shown that the use of domain as a sender address in spam mails decreases significantly as soon as the domain is DMARC-protected.
The use of DMARC as an influencing factor for sender reputation is a milestone for security and efficiency in email communication. At the same time, it means that you do not fall behind in comparison to spam senders, as word has got around about the advantages of DMARC-protected domains. Evaluating the sender’s reputation is an extremely reliable tool in the fight against ever-increasing volumes of spam and increasingly perfidious malware attack scenarios.
Free hands-on guide: DMARC, DKIM, SPF and DANE
In our free guide, we give you step-by-step instructions for setting up SPF, DKIM, DMARC and DANE. Secure your email traffic now!
