Implementing DMARC (Domain-based Message Authentication, Reporting and Conformance)

SPF checks whether the sending server is authorized to send emails on behalf of a domain. DKIM uses digital signatures to confirm that the content of an email has not been altered during transmission. DMARC combines these two by checking the "alignment" between the visible From address and the technically verified sender.

Steps

1. Check your current SPF and DKIM configuration

Before implementing DMARC, you must ensure that SPF and DKIM are working correctly. Check your SPF record:

dig TXT yourdomain.nl | grep "v=spf1"

A valid SPF record looks like this: v=spf1 mx ip4:192.0.2.1 include:_spf.google.com ~all

Check your DKIM record (the selector name depends on your mail server configuration): dig TXT selector1._domainkey.yourdomain.nl

2. Start with a DMARC record with policy "none"

Always start with policy `none` to monitor which email traffic flows through your domain. This prevents legitimate emails from being rejected during the testing phase. Publish the following record in your DNS zone:

_dmarc.yourdomain.nl.  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.nl; ruf=mailto:dmarc@yourdomain.nl; fo=1; adkim=r; aspf=r; pct=100"

Explanation of the tags:

• `v=DMARC1` — the DMARC version
• `p=none` — take no action on failing emails (monitoring mode)
• `rua=mailto:dmarc@yourdomain.nl` — receive aggregate reports
• `ruf=mailto:dmarc@yourdomain.nl` — receive forensic reports
• `fo=1` — generate forensic reports on SPF or DKIM failure
• `adkim=r` — relaxed DKIM alignment (domain may be a subdomain)
• `aspf=r` — relaxed SPF alignment
• `pct=100` — apply the policy to 100% of emails

3. Check that your DMARC record is correctly published

Wait until the DNS change has propagated (usually 5-30 minutes, depending on your TTL) and then check:

dig TXT _dmarc.yourdomain.nl

The result should contain the TXT record you published.

4. Analyze the DMARC reports

Leave the DMARC record with policy `none` for at least 2-4 weeks. During this period, you will receive aggregate reports at the `rua` address. These reports contain XML data with information about:

• How many emails were sent on behalf of your domain
• Which IP addresses sent these emails
• Whether these emails passed SPF and DKIM checks
• What the alignment results were

You can analyze these reports manually or use tools such as `opendmarc` (OpenDMARC) on your server:

sudo apt install opendmarc

5. Refine your SPF and DKIM configuration based on the reports

Analyze the reports and identify:

• Legitimate mail servers not in your SPF record — add them
• Servers not using DKIM correctly — reconfigure them
• Unknown IP addresses sending emails on behalf of your domain — block them

Update your SPF record with the correct IP addresses: v=spf1 mx ip4:192.0.2.1 ip4:192.0.2.2 include:_spf.google.com ~all

6. Increase the policy to "quarantine"

When you are sure that all your legitimate email traffic passes SPF and DKIM checks, increase the policy to `quarantine`. This places suspicious emails in the spam folder instead of rejecting them outright:

_dmarc.yourdomain.nl.  IN  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.nl; ruf=mailto:dmarc@yourdomain.nl; fo=1; adkim=r; aspf=r; pct=100"

7. Switch to policy "reject"

After a further test period of 2-4 weeks with policy `quarantine`, without legitimate emails ending up in spam, you can move to the strictest policy: `reject`. This rejects emails that do not pass authentication:

_dmarc.yourdomain.nl.  IN  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain.nl; ruf=mailto:dmarc@yourdomain.nl; fo=1; adkim=r; aspf=r; pct=100"

8. Set up a DMARC processor for automatic analysis

For automated processing of DMARC reports, you can configure OpenDMARC on your mail server. Install and configure it:

sudo apt install opendmarc
   sudo systemctl enable opendmarc
   sudo systemctl start opendmarc

Configure the reporting address in `/etc/opendmarc.conf`:

AuthservID yourdomain.nl
   RejectFailures false

Verification

Check that your DMARC configuration works correctly with these commands:

<h2>Check your DMARC record</h2>
dig TXT _dmarc.jouwdomein.nl
<h2>Check whether your mail server processes DMARC correctly</h2>
dig TXT _dmarc.jouwdomein.nl | grep "v=DMARC1"
<h2>Test the authentication of an email (replace /var/log/mail.log with your log file)</h2>
grep "dmarc" /var/log/mail.log | tail -20

A correctly configured DMARC record shows the policy you have set. In the mail log you will see lines such as:

dmarc=fail (p=reject) header.from=example.com
dmarc=pass header.from=example.com

Common problems

1. Legitimate emails end up in spam after increasing the policy

This means that some of your mail servers are not correctly configured for SPF or DKIM. Set the policy back to `none`, analyze the reports, and identify which servers are failing. Check whether all IP addresses are in your SPF record and whether DKIM is active on all servers.

2. DMARC reports do not arrive at the `rua` address

Check whether the email address you specified in the `rua` attribute is valid and whether your mail server accepts emails from external parties. Some mail providers block automatic reports. Use a separate email address for DMARC reports and check your spam filter.

3. `dig` shows no DMARC record

This can have two causes: DNS caching delays the visibility of your new record, or the record is not published correctly. Check whether you have placed the record on the correct hostname (`_dmarc.jouwdomein.nl`) and whether your DNS provider correctly supports TXT records with special characters. Wait a few hours and try again with:

dig TXT _dmarc.jouwdomein.nl +trace

Background and development

DMARC is not a new protocol developed from scratch. It builds on SPF and DKIM, both of which had their limitations. SPF only checks the technical sender, not the visible From address. DKIM confirms the integrity of the content but says nothing about the identity of the sender. DMARC fills this gap by checking the alignment between the two.

The development of DMARC began in 2010, when a group of technology and financial organizations worked together on a standard for email authentication. PayPal, Google, Microsoft and Yahoo were involved in this collaboration. They all dealt with mass email fraud and saw the limitations of the existing protocols. The result was a common approach that was given the name DMARC.

The first official specification appeared on January 30, 2012. On March 31, 2013, the specification was submitted as an Internet Draft to the IETF (Internet Engineering Task Force). On April 2, 2014, the project was moved to the Independent Submissions track within the IETF. The final publication as RFC 7489 followed in March 2015.

DMARC.org serves as the central information point for the protocol. The Dutch government, via the Netherlands Enterprise Agency (RVO), recommends DMARC as a best practice for email security. The protocol is now a standard part of a robust email security strategy. Adoption is growing worldwide, but the implementation rate varies greatly by sector and region. The question is no longer whether you should implement DMARC, but when you dare to make the switch to policy `reject`.