Deliverability glossary · Updated 2026-08-10
DMARC
Also called: Domain-based Message Authentication, Reporting and Conformance
DMARC is a DNS policy that tells receivers what to do when a message fails SPF and DKIM alignment: nothing, quarantine it, or reject it. It also requests aggregate reports on authentication results.
DMARC is the layer that makes SPF and DKIM meaningful, because it introduces alignment. A message passes DMARC when it passes SPF or DKIM *and* the domain that passed matches the domain in the visible From header. Without alignment, an attacker could pass SPF for their own domain while displaying yours.
The policy is set with `p=`: `none` monitors without acting, `quarantine` sends failures to spam, `reject` refuses them outright. Every domain should start at `p=none` with reporting enabled, read the aggregate reports for a few weeks to find legitimate senders that fail, then tighten.
Since 2024, Gmail and Yahoo have required a DMARC record for bulk senders. A published policy is no longer an advanced practice; it is table stakes for anyone sending at volume to consumer mailbox providers.
For cold email specifically, DMARC on your sending subdomain protects the parent domain’s reputation too. This is one more argument for never running cold volume from the domain your company relies on.
How Raechly handles it
A DMARC record is included in the DNS set returned by `create_domain`. Raechly does not send from a domain until DKIM verification has succeeded, so authentication is in place before the first message.
Related terms
Back to the full deliverability glossary, or read how these pieces fit together in how Raechly protects deliverability.