DMARC — Domain-based Message Authentication, Reporting, and Conformance — is a DNS record that tells receiving mail servers what to do when an email from your domain fails SPF or DKIM authentication. It is the third and final layer of the email authentication stack. Without a DMARC record, receiving servers handle authentication failures using their own policies. With DMARC, you control the outcome.
The Three DMARC Policies
A DMARC record specifies a policy — p=none, p=quarantine, or p=reject. With p=none, failing emails are delivered normally but the failure is reported. With p=quarantine, failing emails go to spam. With p=reject, failing emails are not delivered at all. For new cold email sending domains, start with p=none to monitor authentication without risking lost emails, then move to p=quarantine once you have confirmed SPF and DKIM are passing.
Why DMARC Matters for Cold Email Specifically
Google and Yahoo require DMARC records on domains sending more than 5,000 emails per day — a threshold cold email campaigns routinely exceed. Without a DMARC record, these providers treat the domain as lacking baseline security compliance, which contributes to spam filtering. More importantly, DMARC reporting tells you if someone is spoofing your sending domain — a real risk for active cold email domains that gain visibility as high-volume senders.
A Correct DMARC Record for Cold Email
A basic DMARC record for a cold email domain looks like: v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@yourdomain.com; pct=100. The rua field sends aggregate reports to the specified email — useful for monitoring authentication failures. This record is added as a TXT record at _dmarc.yourdomain.com. Omni configures DMARC on every cold email sending domain as standard practice in the infrastructure setup process.