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

DMARC (Domain-based Message Authentication, Reporting and Conformance) is an email authentication standard that builds on SPF and DKIM.

DMARC allows a domain owner to:

• Tell receiving mail servers how to handle messages that fail authentication.
• Receive reports about emails claiming to come from the domain.
• Protect the domain against email spoofing and phishing.

SPF and DKIM each solve part of the authentication problem.

However, without DMARC:

• Receiving servers decide for themselves how to treat authentication failures.
• Domain owners receive no visibility into spoofing attempts.

DMARC provides a consistent policy that tells receivers what action to take.

When an email arrives:

1. The receiving server performs an SPF check.
2. The receiving server performs a DKIM check.
3. It verifies whether either authentication method is aligned with the visible From: domain.
4. It reads the domain's DMARC DNS record.
5. It follows the policy published by the domain owner.

Incoming Email

↓

SPF Check

↓

DKIM Check

↓

Alignment Check

↓

Read DMARC Policy

↓

Accept / Quarantine / Reject

DMARC is published as a DNS TXT record.

Example:

_dmarc.example.com

Example record:

v=DMARC1;
p=quarantine;
rua=mailto:dmarc@example.com

The most important DMARC setting is the policy (p).

Monitoring only:

v=DMARC1; p=none

Quarantine suspicious mail:

v=DMARC1; p=quarantine

Reject spoofed mail:

v=DMARC1; p=reject

DMARC requires domain alignment.

The domain used by SPF or DKIM must match the domain visible in the From: header.

Example:

From:
support@example.com

If SPF authenticates:

mailer.example.com

the domains are aligned.

If SPF authenticates:

mailer.otherdomain.com

alignment fails.

DMARC supports two types of reports.

Sent periodically.

They summarize:

• Authentication results
• Sending IP addresses
• Message counts

Example:

rua=mailto:dmarc@example.com

Sent when individual messages fail authentication.

Example:

ruf=mailto:dmarc@example.com

Not all providers send failure reports.

A common deployment process is:

• Start with p=none
• Review DMARC reports
• Fix SPF and DKIM issues
• Change to p=quarantine
• Eventually use p=reject

This minimizes the risk of rejecting legitimate email.

The Telenegar Mail Check service can verify:

• Whether a DMARC record exists
• DMARC syntax
• Published policy
• Report destinations
• Alignment settings
• Common configuration errors

This helps improve both email security and deliverability.

These standards work together.

SPF
↓

"Was the sending server authorized?"

DKIM
↓

"Was the message modified?"

DMARC
↓

"What should the receiver do if SPF or DKIM fails?"

• DMARC replaces SPF and DKIM.
  • False. DMARC depends on SPF and DKIM.

• DMARC encrypts email.
  • False. DMARC is an authentication policy.

• Using p=reject should be the first step.
  • False. It is usually better to begin with p=none and review reports first.

• Publish SPF, DKIM and DMARC together.
• Begin with p=none.
• Monitor aggregate reports.
• Fix authentication problems before enforcing stricter policies.
• Move to p=quarantine and finally p=reject when ready.

• SPF
• DKIM
• DNS Explained
• Mail Check

email dmarc spf dkim dns authentication smtp security