This article explains how to manage DMARC record configuration in Valimail Enforce for both root domains and subdomains.
Note: If you're using Valimail Monitor instead, see this article.
To manage your DMARC record in Valimail, point your domain's DMARC record to Valimail using either a NameServer (NS) or CNAME record; see these instructions for step-by-step guidance. Note that pointing DMARC to Valimail via a TXT record lets us receive aggregate feedback reports for your domain, but it won't let you manage the DMARC record in Enforce.
Manage DMARC for the root domain
After pointing your domain's DMARC record to Valimail with either an NS or CNAME record, you can proceed with the following steps to access the domain's configuration page and make changes to the DMARC record.
Log in to Enforce.
Go to Domains on the left.
From the list of domains, click on the domain name that you want to update.
The section at the top of the domain configuration page is where the DMARC record can be managed.
1. Configured Status: Shows the current DMARC record configuration and also contains the section for adding additional Aggregate Report (RUA) or Failure Report (RUF) Addresses.
2. DMARC policy: The option to change the DMARC policy.
3. Sending Status: Change the Sending Status. If the domain is sending authenticated emails, the status should be kept on Active at all times.
4. Add External Reporting Domains.
Configuration Status
In this section, we will indicate if the DMARC record is pointing to Valimail using an NS or CNAME record.
Configured: DMARC is pointing to Valimail with an NS or CNAME record.
Not Configured: DMARC is not pointing to Valimail.
Reporting Only: DMARC is pointing to Valimail with a TXT record.
Clicking on the Not Configured and the Reporting Only statuses will open a window displaying the instructions to point DMARC to Valimail with an NS record. Clicking on the Configured status will open the window where you can see the current DMARC record as well as the section where you can add additional reporting addresses.
Changing the DMARC policy
Follow the steps below to change the DMARC policy:
Click on the DMARC Policy.
Select the desired policy (None, Quarantine, or Reject).
Click the Change Policy button on the confirmation window.
Advanced Options
At the bottom of the Set DMARC Policy window, you will find the Advanced Options.
Enforcement Percentage (deprecated in RFC 9989): Sets the percentage of messages subject to your p=quarantine or p=reject policy, via DMARC's pct tag. This tag lets you roll out enforcement gradually; for example, setting it to 25% applies your policy to roughly a quarter of messages that fail DMARC. Meanwhile, the remainder is treated as if the policy were p=none. The default and recommended setting is 100%, so that all mail is subject to DMARC processing.
Caution: Not all email service providers honor the pct value consistently, so a partial percentage may not behave the same way across every receiving domain. Only the domains that currently have an Enforcement Percentage set in their DMARC record configuration have access to this feature.
Testing Mode (t=): The tag is a plain signal to receivers: "I'm still testing this policy". It doesn't change what policy is published, it changes what the receiver actually does about a failing message by downgrading enforcement one level:
Policy is p=reject (or sp=/np=reject, whichever applies) and t=y → receiver treats failing mail as if the policy were quarantine.
Policy is quarantine and t=y → receiver treats failing mail as if the policy were none (monitor only, deliver normally).
Policy is already none, t=y has no further effect (can't downgrade past none).
t=n (the default) → receiver just applies the published policy as-is, no softening.
Organizational Domain Boundary (psd=): This tag was added because the old way of figuring out a domain's "Organizational Domain", consulting the externally maintained Public Suffix List, was never actually part of the DMARC standard itself; RFC 7489 never specified which PSL to use or how often to refresh it, so different receivers could reach different conclusions about the same domain, and the list itself needed a domain to already be publicly known as shared infrastructure (like a ccTLD or a platform such as GitHub Pages) before anyone would think to add it. The psd= tag replaces that dependency with a DNS tree walk, allowing a domain to declare its own status directly in DNS so the walk knows when to stop.
psd=y: A receiver queries up the domain hierarchy looking for a DMARC record; if it finds one carrying psd=y, that tells the receiver "this domain is a public suffix so everything below it belongs to separate, unrelated organizations," and the walk stops there.
psd=n: Asserts the opposite, "this is a single organization's domain, and it is the Organizational Domain for itself and all its subdomains". Also ends the walk, just with the domain claimed rather than excluded.
psd=u (default value): U for "unknown", which just means the domain hasn't declared either way and the receiver falls back to normal tree-walk discovery.
Subdomain Policy: Set a DMARC policy for the subdomains under the apex domain. The default setting is “Domain Policy - Use the policy defined for the domain,” which means that the subdomains will inherit the policy from the apex domain.
Non-Existent Subdomain Policy (np=): A DMARC policy dedicated to non-existent subdomains. "Non-existent" here has a specific, DNS-based meaning: if a DNS query for that subdomain name returns NXDOMAIN, the subdomain is considered non-existent. A subdomain that exists (has any DNS records, even just an A record with no mail service) is treated as a real, existing subdomain, and np= doesn't apply to it.
Strict Alignment: This refers to DKIM/SPF alignment, which has two modes: relaxed (option is unchecked) and strict (option is checked). Strict alignment (option is checked) means that the sender domain needs to match exactly the DKIM signing domain (d=domain parameter in the email header) or the domain in the MAIL FROM command (for SPF). The default setting is ‘Relaxed’ (the option is unchecked in the UI), which allows you to use subdomains for SPF and DKIM authentication when the sender domain is your apex domain, or vice-versa.
Sending Status
For a complete guide on managing the Sending Status, please see this article.
Any domain that is sending authenticated emails should have an Active sending status at all times.
Add External Reporting Domains
To learn what external reporting domains are and when they should be used, please read the following article.
You can't manage external reporting domains in Valimail if DMARC points to us with a CNAME or TXT record.
Managing DMARC for a subdomain
Subdomains automatically inherit the DMARC policy from the root domain, but the DMARC specification lets domain owners publish a DMARC record on a subdomain and manage its policy independently of the root domain.
If you have already pointed the DMARC record for your subdomain to Valimail using an NS or CNAME record, you can use the following steps to manage DMARC for that subdomain.
Open the domain's configuration page.
Scroll down to the subdomain in question, and click on its name.
Click on the DMARC Policy.
Click on the acknowledge checkbox, then click on Continue.
Select the desired Enforcement policy.
Click on Change Policy.
If you did not publish a DMARC record on the subdomain, the subdomain will inherit the policy from the root domain, which is the recommended configuration. In this case, the configuration page will show a "Configured" status on the subdomain.
If the subdomain has a DMARC TXT record published, the configuration page will show a "Not Configured" status on that subdomain, regardless of whether the DMARC record is pointing to Valimail or not.