Publish a DMARC policy | LightServe Docs

DMARC is a DNS policy that tells receiving servers what to do with mail from your domain that fails SPF and DKIM checks, and where to send reports about it. This article publishes a DMARC record in monitoring mode, shows how to read the results, and walks through tightening the policy step by step.

Before you begin

SPF and DKIM working for example.com (see the SPF and DKIM articles). DMARC builds on both.
A mailbox that can receive reports, such as dmarc-reports@example.com. Create it with the virtual mailboxes article, or use a mailbox you already read.
Access to your DNS settings, such as Lantern DNS, LightServe's DNS editor.
The dig tool, from the dnsutils package.

Step 1: Confirm that SPF and DKIM pass

Before you enforce anything, check that your real mail passes both checks. Send a test message from your server to an address you can read, then open the full message headers. Your mail app has an option such as "show original" or "view source". Look for an Authentication-Results header that the receiving server added. It should contain spf=pass and dkim=pass.

If either one fails, fix that first. DMARC makes failures more visible, not less.

Step 2: Create the DMARC record

A DMARC record is a TXT record named _dmarc on your domain. It starts with v=DMARC1 and contains tags separated by semicolons. This first version is in monitoring mode, which means receivers do not block anything yet:

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; adkim=r; aspf=r

Here is what each part means:

p=none is the policy. It only asks for reports and changes nothing for delivery.
rua=mailto:dmarc-reports@example.com is where aggregate reports go. Replace the address with a mailbox you can read.
adkim=r and aspf=r set the alignment checks to relaxed, which allows subdomains to match the main domain. This is the friendly default for most setups.

Create the TXT record with the name _dmarc. Some DNS panels take only the name _dmarc and append the domain themselves, so check what your panel expects.

Step 3: Check the record is live

Query a public resolver to see the record as the rest of the internet sees it:

dig +short TXT _dmarc.example.com @8.8.8.8

Expected output:

"v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; adkim=r; aspf=r"

If nothing appears, wait a few minutes for DNS to update and try again.

Tip: Keep monitoring mode for at least two to four weeks. Reports arrive as compressed XML files, which are hard to read by hand. Many free and paid DMARC report viewers exist, or you can simply check that the sender list includes only your own servers.

Step 4: Read the reports and find unknown senders

Reports list the servers that sent mail claiming to be from your domain and whether each message passed SPF and DKIM. Look for senders you do not recognize. These are often spam, but they can also be a legitimate service that you forgot to add to SPF or DKIM. Fix the legitimate ones before you tighten the policy.

You can also check the mailbox for report files directly on the server, which is handy while testing:

sudo ls -lh /var/mail/vhosts/example.com/dmarc-reports/Maildir/new

Adjust the path to match where your virtual mailbox lives. The virtual mailboxes article uses this layout.

Step 5: Tighten the policy gradually

Once your legitimate mail consistently passes, move to quarantine. Receivers will then send failing mail to spam instead of delivering it. Publish a new version of the record with p=quarantine:

v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com; adkim=r; aspf=r

Watch the reports for another few weeks. When nothing legitimate fails, you can use p=reject, which asks receivers to refuse failing mail outright. Replace the record's policy tag each time, and keep the same report address.

Careful: p=reject stops every failing message, including messages from forms, newsletters and third-party apps you forgot about. Move to it only after reports show that all your real senders pass.

Troubleshooting

The record shows an error or does not appear: make sure there is one DMARC record only, that it starts with v=DMARC1, and that the name is _dmarc on your domain.
No reports arrive: reports can take a day or more, and some receivers send them rarely. Confirm the rua address exists and accepts mail, using a test message to it.
Legitimate mail fails DMARC: the sender is missing from SPF, or DKIM signing does not cover that sender. Check the headers as in Step 1.
Subdomain mail behaves oddly: add sp=none or another subdomain policy only after you understand which subdomains send mail.

Next steps

With SPF, DKIM and DMARC in place, your domain's mail is much harder to forge and far more likely to reach the inbox. Keep reading the reports for a few months, and revisit the record whenever you add a new service that sends mail for your domain.