Email & security

DMARC (Domain-based Message Authentication)

DMARC checks whether an SPF- or DKIM-authenticated domain aligns with the domain in an email's From address, then lets the domain owner publish a requested handling preference and ask for reports.
← Back to glossary

What is DMARC?

DMARC (Domain-based Message Authentication, Reporting & Conformance) is an email authentication protocol that checks whether an SPF- or DKIM-authenticated domain aligns with the domain in a message's From address. A domain owner can publish a requested handling preference for messages that fail DMARC validation and request aggregate or message-specific failure reports.

Why DMARC is essential

SPF and DKIM authenticate sending identifiers. On their own, they do not check whether an authenticated identifier aligns with the domain in the From address or state the domain owner's handling preference for failed messages.

DMARC solves this by:

  • Stating a handling preference: None, quarantine, or reject for messages that fail DMARC
  • Checking alignment: At least one authenticated SPF or DKIM identifier must align with the From domain
  • Requesting reports: Aggregate and message-specific failure reports provide insight into observed authentication results

How DMARC works

1. Sender publishes DMARC policy in DNS (TXT record at _dmarc.domain.com)

2. Email is sent with From: [email protected]

3. Receiver checks SPF and DKIM

4. Receiver checks alignment: Does authenticated domain match From header?

5. Handling decision: The receiver considers the requested policy and other signals

6. Reports may be sent: Participating receivers may send requested aggregate or message-specific failure reports

DMARC alignment

DMARC requires alignment: the domain in the From header must align with at least one authenticated identifier under the record's relaxed or strict mode:

  • SPF alignment: The SPF-validated MAIL FROM domain, or the HELO domain when MAIL FROM is null
  • DKIM alignment: The d= domain in a valid DKIM signature

Without alignment, SPF or DKIM can pass while DMARC fails. DMARC directly addresses specific forms of spoofing that use the exact From domain. It does not detect visually similar domains or misuse of the sender's display name.

DMARC record format

DMARC records are TXT records at _dmarc.yourdomain.com:

_dmarc.example.com.    IN    TXT    "v=DMARC1; p=reject; rua=mailto:[email protected]"

DMARC tags

TagRequiredDescriptionExample
vYesVersionv=DMARC1
pRecommended (optional)Requested handling preference for mail that fails DMARC validationp=none/quarantine/reject
ruaNoAggregate report URIrua=mailto:[email protected]
rufNoMessage-specific failure report URIruf=mailto:[email protected]
tNoPolicy test modet=y or t=n
spNoRequested policy for existing subdomainssp=reject
npNoRequested policy for non-existent subdomainsnp=reject
adkimNoDKIM alignment modeadkim=s (strict) or adkim=r (relaxed)
aspfNoSPF alignment modeaspf=s or aspf=r

The pct tag is historic. The current DMARC standard no longer uses it to apply a policy to a percentage of failing messages. The p tag is recommended but optional; an otherwise valid record without it is treated as p=none.

DMARC policies

p=none: Express no handling preference for failed messages. Domain owners commonly use it while reviewing reports.
v=DMARC1; p=none; rua=mailto:[email protected]
p=quarantine: Request that receivers treat DMARC-failing messages as suspicious.
v=DMARC1; p=quarantine; rua=mailto:[email protected]
p=reject: Request that receivers reject DMARC-failing messages. Receivers consider this preference with other signals, so it does not guarantee rejection.
v=DMARC1; p=reject; rua=mailto:[email protected]

DMARC implementation path

Phase 1: Monitor (p=none)

Start with monitoring to understand your email ecosystem:

v=DMARC1; p=none; rua=mailto:[email protected]

Analyze reports to identify:

  • Legitimate sending services missing SPF/DKIM
  • Unauthorized senders (spoofing)
  • Alignment issues

Phase 2: Quarantine (p=quarantine)

Once legitimate sources are authenticated:

v=DMARC1; p=quarantine; rua=mailto:[email protected]

Review reports and confirm legitimate mail is authenticated before choosing a stricter policy. The current DMARC standard does not define a percentage rollout.

Phase 3: Reject (p=reject)

Request rejection for DMARC-failing messages:

v=DMARC1; p=reject; rua=mailto:[email protected]

DMARC reports

Aggregate reports (rua)

Receivers are recommended to send aggregate XML reports daily or more often. Reports summarize observed message streams, so availability and coverage depend on the reporting receivers:

  • Volume of email
  • Pass/fail rates for SPF, DKIM, DMARC
  • Sending IP addresses
  • Recipient organizations

Failure reports (ruf)

Message-specific reports may include message headers or content. Not all receivers send them, often because of privacy concerns:

  • Authentication failure details

Report processing

Aggregate DMARC reports are XML and can be hard to read. Use services like:

  • DMARC Analyzer
  • Dmarcian
  • Valimail
  • Postmark DMARC

Checking DMARC

The authenticated DomScan Email Authentication API costs 3 credits per domain and returns the DMARC record and parsed tags.

dig _dmarc.example.com TXT
curl -H "X-API-Key: $DOMSCAN_API_KEY" "https://domscan.net/v1/email-auth?domain=example.com"

# Check dmarc.record and dmarc.tags in the JSON response

Common DMARC issues

No reports received: Ensure rua address can receive large emails; some providers filter. Legitimate email failing: Check SPF/DKIM configuration for all sending services; verify alignment. Third-party services failing: Many services require custom DKIM setup for DMARC alignment.

DMARC adds alignment, a requested handling preference, and reporting to SPF and DKIM. Review your sending sources and reports before requesting stricter handling.

Put this knowledge to work

Use DomScan's API to check domain availability, health, and more.