What Is DMARC?

DMARC (Domain-based Message Authentication, Reporting and Conformance) is an email authentication protocol that builds on SPF and DKIM. It tells receiving mail servers what to do when a message fails authentication — and sends reports back to the domain owner so they can see who is sending email on their behalf.

DMARC works alongside SPF and DKIM. Where SPF and DKIM verify that a message is legitimate, DMARC adds the policy layer: what should happen when verification fails, and who should be notified.

Why DMARC Matters

Without DMARC, a receiving server that sees a failed SPF or DKIM check has no clear instruction. It might deliver the message anyway, send it to spam, or reject it — the behaviour varies by provider. DMARC removes that ambiguity.

DMARC also solves a problem that SPF and DKIM cannot solve on their own: domain alignment. SPF checks the envelope sender (the Return-Path), and DKIM checks the signing domain (the d= value). Neither one checks the From header — the address the recipient actually sees. DMARC requires that at least one of those mechanisms aligns with the From domain.

This is what makes DMARC effective against spoofing. An attacker can send a message that passes SPF for their own domain, but DMARC will fail it if the From address uses your domain and the SPF or DKIM domain does not match.

How DMARC Works

When a message arrives, the receiving server checks for a DMARC record on the From domain. The process follows these steps:

1. The server receives the message and reads the From header domain.
2. It performs a DNS lookup for _dmarc.example.com to find the DMARC policy.
3. It checks whether the message passes SPF — and whether the SPF domain aligns with the From domain.
4. It checks whether the message passes DKIM — and whether the DKIM signing domain aligns with the From domain.
5. If at least one mechanism passes AND aligns, the message passes DMARC.
6. If both fail or neither aligns, the server applies the DMARC policy (none, quarantine, or reject).
7. The server sends an aggregate report to the address specified in the DMARC record.

The DMARC DNS Record

DMARC is published as a TXT record at _dmarc.yourdomain.com. Here is a typical record:

v=DMARC1; p=reject; rua=mailto:dmarc@example.com; ruf=mailto:dmarc@example.com; adkim=s; aspf=s; pct=100

DMARC Tags Explained

• v=DMARC1 — Required. Identifies the record as DMARC.
• p= — Required. The policy for messages that fail. Values: none, quarantine, reject.
• rua= — Aggregate report address. Receives daily XML reports showing who sent email using your domain.
• ruf= — Forensic report address. Receives detailed reports on individual failures (not all providers send these).
• adkim= — DKIM alignment mode. "s" for strict (exact domain match), "r" for relaxed (subdomains allowed).
• aspf= — SPF alignment mode. "s" for strict, "r" for relaxed.
• pct= — Percentage of failing messages the policy applies to. Useful for gradual rollout.
• sp= — Subdomain policy. Overrides p= for subdomains.
• fo= — Failure reporting options. Controls when forensic reports are generated.

DMARC Policies: none, quarantine, reject

p=none (Monitor Only)

No action is taken on failing messages. The server delivers them normally. Reports are still sent, so you can see what is happening without affecting mail delivery. This is where every DMARC deployment should start.

p=quarantine

Failing messages are treated as suspicious. Most receiving servers will send them to the spam or junk folder. This is the intermediate step — you have reviewed your reports, fixed legitimate sources, and are ready to start filtering.

p=reject

Failing messages are rejected outright. The receiving server will not deliver them. This is full protection — only messages that pass authentication and align with your domain will be delivered.

DMARC Alignment

Alignment is the key concept that makes DMARC effective. It checks whether the domain used by SPF or DKIM matches the domain in the From header.

Relaxed Alignment (Default)

The organizational domain must match. If your From address is user@mail.example.com and SPF passes for bounce.example.com, relaxed alignment passes because both share example.com.

Strict Alignment

The exact domain must match. In the same scenario, strict alignment would fail because mail.example.com and bounce.example.com are different subdomains.

Strict alignment provides stronger protection but requires more careful configuration. Most deployments start with relaxed alignment and tighten later.

DMARC Reports

Aggregate Reports (rua)

These are XML files sent daily by receiving servers. They show the volume of messages sent using your domain, which IP addresses sent them, and whether each message passed or failed SPF, DKIM and DMARC. Aggregate reports are essential for understanding your email ecosystem before enforcing a policy.

Forensic Reports (ruf)

These contain details about individual messages that failed DMARC. They can include message headers and sometimes body content. Not all providers send forensic reports due to privacy concerns. Google, for example, does not send them.

The raw XML reports are not easy to read. Most organisations use a DMARC reporting tool or service to parse and visualise them.

How to Deploy DMARC

1. Ensure SPF and DKIM are correctly configured for all legitimate sending sources.
2. Publish a DMARC record with p=none to start collecting reports without affecting delivery.
3. Monitor reports for 2-4 weeks. Identify all legitimate sources and fix any authentication failures.
4. Once all legitimate sources pass, move to p=quarantine. Watch for any delivery issues.
5. After confirming no legitimate mail is being quarantined, move to p=reject for full protection.
6. Continue monitoring reports. New sending sources (marketing tools, CRM systems) will need SPF and DKIM configuration.

Common DMARC Mistakes

Starting With p=reject

Jumping straight to reject without monitoring will block legitimate email. Always start with p=none, review your reports, and progress gradually.

Ignoring the Reports

A p=none policy with no one reading the reports provides zero protection. The reports are the entire point of the monitoring phase.

Forgetting Third-Party Senders

Marketing platforms, CRM systems, helpdesk tools and other services that send email on your behalf all need to be included in your SPF record and should be configured to sign with DKIM using your domain.

Not Setting rua

Without a reporting address, you cannot see what is happening. Always include rua= in your DMARC record.

How to Check Your DMARC Record

You can look up your DMARC record using dig or nslookup:

dig TXT _dmarc.example.com

nslookup -type=TXT _dmarc.example.com

If no record is returned, DMARC is not configured for that domain.

DMARC, SPF and DKIM Together

DMARC does not replace SPF or DKIM — it depends on both. Think of it this way:

• SPF defines which servers are allowed to send email for your domain.
• DKIM proves the message has not been altered and was signed by an authorised sender.
• DMARC checks that at least one of these passes and aligns with the From domain, then enforces a policy.

All three records are published in your domain's DNS. Together, they form the standard email authentication stack. For a complete guide to MX records and DNS configuration, see our DNS articles.

Do You Need DMARC?

Yes. If your domain sends email — whether transactional, marketing or internal — DMARC protects it from being spoofed. Without DMARC, anyone can send email that appears to come from your domain, and receiving servers have no policy to stop it.

Major email providers including Google and Yahoo now require DMARC for bulk senders. Even if you send low volumes, DMARC protects your domain reputation and your recipients.

If you need help implementing DMARC for your business domain, get in touch with our team. We configure SPF, DKIM and DMARC as part of every business email hosting and email security deployment.