Resolving the ‘DMARC policy not enabled’ error
This easy guide will help you set up the right DMARC policy for your domain. The three options to choose from are p=none, p=quarantine, and p=reject. Let’s first start with the two-step solution to the ‘DMARC policy not enabled error.’
Define a suitable policy for your DMARC record
To get rid of the ‘DMARC policy not enabled error,’ you first need to understand what each of the policy do and which one is suitable for your domain.
What does the ‘None’ policy do?
The ‘None’ policy doesn’t offer any protection against phishing and spoofing emails sent from your domain. This is because it is the ‘monitoring’ policy. It tells the receiving mail servers to take no action if emails from your domain fail the authentication checks (SPF or DKIM, or both).
This means that even if an email fails DMARC, it will still be delivered to the recipient’s inbox, but the domain owner will receive aggregate reports detailing these failures. The ‘None’ policy is typically used during the initial phase of DMARC deployment to help organizations analyze email traffic, identify legitimate sources, and detect potential spoofing attempts, without affecting email deliverability or causing disruptions to real senders.
What does the ‘Quarantine’ policy do?
The ‘Quarantine’ policy is stricter than the ‘None’ policy. It tells the receiving mail servers to proceed with unauthenticated emails with caution. It essentially instructs it to direct such emails to the spam folders, serving as a warning system. It protects recipients from potential spoofed messages while still allowing the domain owner to monitor what’s going wrong.
What does the ‘Reject’ policy do?
The ‘Reject’ policy is the strictest one as it instructs the receiving mail servers to outright deny entry to emails that fail DMARC checks. With this DMARC policy in place, there is no possibility of a targeted victim interacting with a potentially fraudulent message and getting duped. However, if there is a case of a false positive, the ‘Reject’ policy will cause even genuine emails to get rejected, impacting communication. This is why many domain owners lack the confidence to implement this policy.
Publish or republish the DMARC record with a suitable policy
Once you have chosen the right DMARC policy, it’s time to publish or republish your DMARC record. If you have never had a DMARC record, then you need to generate one using an online generator tool and publish it in your domain’s DNS. However, if you already have one and it’s just missing the policy, then simply include the ‘p=’ tag with the suitable policy, such as p=none, p=quarantine, or p=reject. After that, just go ahead and republish the record.
Without the ‘policy’ tag, the DMARC setup is not only incomplete but entirely useless. This is because no instructions are sent to the receiving servers on how to handle suspicious emails.
By adding this, you give clear instructions, and it should fix the ‘DMARC policy not enabled’ error for your domain.
Fixing the ‘DMARC quarantine/reject policy not enabled’ error
If you see a warning like ‘DMARC policy not enabled,’ ‘No DMARC protection,’ or ‘DMARC Quarantine/Reject policy not enabled,’ it just means that your domain’s DMARC is set to ‘None.’ This setting only lets you monitor email activity, but doesn’t actually stop suspicious or fake emails from being delivered.
If your domain or DMARC record is new, then it’s suggested to use the ‘None’ policy. This is because it works by helping you only monitor the email traffic and take no action. When your domain or DMARC record is new, there is a high chance of false positives and negatives—things take time to settle in. So, with this lenient policy, you can see who all are sending emails on your behalf. This will help you spot unauthorized senders while also letting you know if you missed listing any of your genuine senders as ‘authorized’ (in the SPF record).
After 3-4 weeks, you can gradually move to the less forgiving DMARC policies, which are ‘Quarantine’ and ‘Reject.’
Here is how your DMARC record should look if you have implemented the ‘Quarantine’ policy-
v=DMARC1; p=quarantine; rua=mailto:example@domain.com; ruf=mailto:example@domain.com;
Here is how your DMARC record should look if you go ahead with the ‘Reject’ policy-
v=DMARC1; p=reject; rua=mailto:example@domain.com; ruf=mailto:example@domain.com;
The right way to transition from p=quarantine to p=reject
Shifting from p=quarantine to p=reject takes some strategy, unless you don’t mind tossing your email deliveries upside down. As much as this transition sounds daunting for your email deliveries, it’s important for ensuring protection against phishing and spoofing. That’s why this process needs to be conducted carefully to avoid blocking legitimate emails.
Here’s how you can go about it-
Regularly review your DMARC reports
Read your aggregate DMARC reports for a few weeks or months. See if the emails that are failing the DMARC checks are actually sent by unauthorized senders, or if this is happening because of false positives. You may also spot emails failing from genuine senders because their IP addresses or mail servers aren’t listed in the SPF record.
Fix any authentication gaps
Ensure all your legitimate email sources are correctly configured with SPF and DKIM. If any valid source fails authentication, first fix the setup. You may need to update your SPF records, add DKIM signing, or correctly include third-party senders.
Gradually tighten control using the ‘percentage’ tag (pct tag)
Proceed gradually using the ‘percentage’ tag that allows you to apply the ‘reject’ policy to a prespecified percentage of outgoing emails. For example, start with p=reject; pct=25 to apply the reject policy to 25% of failing emails. Slowly increase the percentage over time—50%, then 75%, and finally 100%
However, please note that you must continue to monitor the DMARC reports to increase the percentage. Suppose you increased the percentage from 50% to 80%, and some of the genuine emails are failing DMARC, then adjust it back to 50%. The ‘reject’ policy is not forgiving; false positives simply mean hampered communication.
Keep monitoring after moving to p=reject
Even after moving to p=reject, continue reviewing your DMARC reports. This helps ensure that no legitimate emails are accidentally blocked and confirms that your domain is well-protected.
DMARC demands proactiveness!
DMARC is not a one-time job. You must continually evaluate the reports and adjust the SPF, DKIM, and DMARC records accordingly. Our experts at DuoCircle can do all this and more for you, helping you with email protection and improved deliverability. Contact us today to know more.