Domain-based Message Authentication, Reporting, and Conformance (DMARC)

DMARC (Domain-based Message Authentication, Reporting, and Conformance) is an email authentication standard that lets a domain owner publish, in DNS, what receiving mail servers should do with messages that claim to come from the domain but fail authentication. It builds on SPF and DKIM: a message passes DMARC only if one of those checks passes for a domain that matches the address in the visible From line. DMARC also asks receivers to send the domain owner reports, which show the sources those receivers saw sending mail in the domain’s name.

At a glance

• DMARC is a TXT record at _dmarc.yourdomain.com that sets a policy: none (monitor), quarantine (treat as suspicious, usually spam folder) or reject.
• A message passes if SPF or DKIM passes and the passing domain aligns with the visible From domain.
• Receivers decide how to apply your policy, but large mailbox providers generally honor it.
• Aggregate reports show the sources that reporting receivers saw sending as your domain and whether they passed, which makes DMARC useful well before enforcement; they are not a complete inventory.
• An enforced policy makes exact-domain spoofing much harder; it doesn’t stop lookalike domains or compromised supplier mailboxes.

What problem it solves

Without DMARC, anyone can send email that shows your domain in the From line. SPF and DKIM alone don’t prevent this, because they check domains the recipient never sees: a criminal can pass SPF for their own server’s domain or sign with DKIM for their own domain while displaying yours. That gap is how fake invoices, payment-change requests and executive impersonation emails (business email compromise) appear to come from you.

DMARC closes the gap by requiring alignment with the visible From domain and by telling receivers what to do when it is missing. It also solves a quieter problem: many organizations don’t know every service that sends as their domain. Marketing platforms, billing systems, help desks, HR tools and scanners all send mail, and DMARC reports surface many of them, though low-volume or rarely used senders may not appear in the reports at all. Large mailbox providers now also expect DMARC from high-volume senders, as covered under bulk sender requirements.

How it works

1. You publish a policy. A TXT record at _dmarc.yourdomain.com such as v=DMARC1; p=none; rua=mailto:reports@yourdomain.com declares the policy and where reports go. Optional tags set alignment strictness (adkim, aspf) and a separate policy for subdomains (sp).
2. A receiver checks SPF and DKIM. When a message arrives, the receiving server runs both checks.
3. It checks alignment. SPF aligns if the envelope sender (return-path) domain matches the From domain; DKIM aligns if the signing domain (d=) matches. “Relaxed” alignment, the default, accepts subdomains of the same organizational domain; “strict” requires an exact match.
4. It applies your policy. If neither aligned check passes, the receiver applies your policy, taking its own local rules into account.
5. It reports back. Receivers that support reporting send daily aggregate XML reports listing sending sources and their pass or fail results. Some also send failure reports with message details, though many large providers don’t.

The aggregate reports are hard to read raw, so many organizations use a reporting tool or service to summarize them. Reports only cover mail that reached receivers that send reports, so reconcile them with an internal list of sending services before enforcing.

When it matters for buyers

• When spoofed invoices or payment requests appear. An enforced DMARC policy is the main control against exact-domain spoofing.
• When marketing or billing mail starts going to spam. Mailbox providers may require DMARC from bulk senders, and missing or failing authentication hurts delivery.
• When a customer, insurer or auditor asks. Security questionnaires often ask whether your domains publish DMARC at enforcement.
• When adding a new email-sending service. Each one needs aligned SPF or DKIM before it goes live, or enforcement will block it.
• For domains you don’t use for email. Publishing p=reject on parked domains, alongside an SPF record of v=spf1 -all, lets receivers reject mail that spoofs them.

A typical path is to publish p=none, use the reports and an internal list of every service that should send as your domain to fix each legitimate sender, then move to quarantine and reject once only unknown sources are failing. How long that takes depends on how many services send as your domain.

Questions to ask vendors

These apply to email security providers and DMARC reporting services.

• Do you parse our aggregate reports into a sender inventory, and how do you flag new or failing sources?
• Will you help us configure aligned DKIM and SPF for each third-party sender, or only report on them?
• How do you recommend moving from none to reject, and how do you protect legitimate mail during the change?
• Do you also detect lookalike domains, which DMARC doesn’t cover?
• Does your gateway enforce senders’ DMARC policies on our inbound mail, and can we see the results?

How it differs from SPF and DKIM

SPF lists the servers allowed to send mail for a domain, and DKIM adds a cryptographic signature that proves which domain authorized a message and that signed content wasn’t changed. Neither one, on its own, checks the From address people actually see or tells receivers what to do on failure. DMARC adds those two things plus reporting. The three work together, and BIMI, which shows a verified logo next to messages, requires DMARC at enforcement first. For filtering and protecting inbound mail, see our secure email gateway overview.

Problems this helps with

• Criminals sending fake invoices or payment requests from our own domain
• Our legitimate emails going to spam or being rejected
• Mailbox providers requiring DMARC for our marketing or billing email
• No idea which services are sending email in our name