DMARC Records

DMARC (Domain-based Message Authentication, Reporting & Conformance) ties SPF and DKIM together with a policy, telling receiving servers what to do when a message fails authentication — and giving you reports on what's being sent in your name.

Prerequisites

Effective DMARC requires SPF records and DKIM signing for outgoing messages to already be in place.

Quick Start

For a straightforward, non-disruptive starting point, publish this basic record. It monitors authentication without affecting delivery:

TypeHostValue
TXT_dmarcv=DMARC1; p=none; sp=none; adkim=r; aspf=r;
v=DMARC1; p=none; sp=none; adkim=r; aspf=r;

Key Components

DMARC records use several tags to control behavior:

TagMeaning
vVersion — always DMARC1.
pPolicy — action on failed authentication: none, quarantine or reject.
rua / rufOptional reporting endpoints for aggregate and forensic reports.
adkim / aspfAlignment settings for DKIM and SPF (r = relaxed, s = strict).

Implementation Strategy

Take a gradual approach so you never accidentally block your own legitimate mail:

  1. Monitor
    Start with p=none and review the reports you receive.
  2. Confirm sources
    Verify that SPF and DKIM pass for every legitimate sender.
  3. Tighten policy
    Progressively move to p=quarantine and eventually p=reject as you gain confidence.

Don't forward DMARC reports to Gmail

Avoid forwarding DMARC reports to Gmail addresses. Google doesn't accept forwarded DMARC reports from itself, which can harm deliverability for your domain.

DMARC is the final piece of the authentication stack. Make sure your SPF Records and DKIM Records are configured first, and see Technical Configuration for the full picture.

Table of Contents