DMARC (Domain-based Message Authentication, Reporting and Conformance) is a policy you publish in DNS, as a TXT record at _dmarc.yourdomain.com, that tells receiving servers what to do when an email claiming to come from your domain fails authentication. It builds on SPF and DKIM, adding the idea of alignment: the domain that passed SPF or DKIM must match the domain in the visible From address.
A message passes DMARC if either SPF or DKIM passes and aligns. Alignment can be relaxed (a subdomain such as mail.yourbrand.com aligns with yourbrand.com) or strict (an exact match). The policy tag p= sets what happens to failures: none (just report), quarantine (treat as suspicious, usually spam folder) or reject (refuse the message). The rua= tag says where aggregate reports should go.
Those reports are the most valuable part for most businesses. They show every source that sent mail using your domain, how much, and whether it passed. That is how you discover a forgotten billing tool, a website contact form or a reseller sending in your name. Start with p=none and reports, fix every legitimate source, then move to quarantine and finally reject. Jumping straight to reject can block your own invoices.
Gmail and Yahoo require bulk senders to publish a DMARC record, with p=none as the minimum, and BIMI requires an enforcing policy. Beyond compliance, a DMARC policy at quarantine or reject makes it much harder for fraudsters to send phishing emails that use your exact domain, which protects your customers too.
A Bengaluru fintech publishes “v=DMARC1; p=none; rua=mailto:dmarc@itsdomain.in”. Reports show its CRM sending unauthenticated mail. After setting up DKIM for the CRM and waiting a month with clean reports, it moves to p=quarantine and later to p=reject.
MailNesto checks whether each sending domain has a DMARC record during guided DNS setup, and its DNS lookup tool warns when a domain has no DMARC record.