A DMARC record is a TXT entry at _dmarc.<domain> (e.g. _dmarc.brand.com). Its core directive is the p= policy tag, taking one of three values: none (monitor only), quarantine (deliver to spam), or reject (do not deliver). The record also names aggregate (RUA) reporting addresses; receivers send daily XML reports there, which is how a brand sees which sending platforms are passing or failing before enforcement.
DMARC sits on top of two older protocols. SPF authorizes which IPs may send for a domain; DKIM cryptographically signs outbound mail with a domain-published public key. DMARC adds an alignment requirement: the visible From header must match the domain that SPF or DKIM authenticated. Without alignment, an SPF or DKIM pass alone does not produce a DMARC pass.
For DTC brands, this is no longer optional. Gmail and Yahoo’s bulk-sender requirements, in effect since February 2024, require any domain sending more than 5,000 messages per day to their users to publish a DMARC policy (p=none is sufficient), pass SPF and DKIM with alignment, and offer one-click unsubscribe. The brand newsletter list usually crosses that threshold once subscribers are in the tens of thousands, and the email program is a core surface where first-party data is activated.
The recommended rollout is p=none → p=quarantine (often staged via the pct= tag) → p=reject, gated on reports showing every legitimate source — Klaviyo, Shopify transactional, Gorgias, Sendgrid — passing alignment. Jumping straight to p=reject with a misconfiguration drops legitimate mail.
The operator trap: email marketing owns the program, but DNS lives with engineering or IT, and the handoff is where bad records ship. The right pattern is a DMARC monitoring tool (Valimail, EasyDMARC, Postmark) plus a deliberate ramp over weeks. The wrong pattern is copying a record from a tutorial and watching domain reputation degrade silently while marketing reads it as a campaign-performance problem.