What is DMARC?
DMARC is the record published in a domain's DNS that requires the sender shown in a message, the one the person reads on screen, to be the same domain authenticated by SPF or DKIM. It also tells providers what to do when that match fails (p=none, p=quarantine or p=reject), and returns a daily report of who has been sending in the domain's name. It is the only one of the three email authentication records that, at a blocking policy, actually stops someone from using your company's domain as the sender.
How DMARC works
SPF authorizes servers and DKIM signs messages, but neither one looks at the address shown on the recipient's screen. DMARC, short for Domain-based Message Authentication, Reporting and Conformance, steps in exactly there: it compares what was authenticated against what is being displayed, and only accepts when the two match. That comparison is called alignment, and it is the heart of the standard.
The company publishes the policy
A text record in DNS declares what the domain owner wants to happen when the check fails, and which address the reports should be sent to.
The recipient checks SPF and DKIM
On receiving the message, the server runs the two usual checks: the origin was authorized, the signature is valid.
It compares against the sender shown on screen
This is the step only DMARC takes. It counts for nothing that the message passed a check performed on some other domain: the standard requires the authenticated domain and the displayed domain to match.
It applies the published policy
If alignment fails, the server does what the domain owner asked: nothing, send it to quarantine, or refuse delivery.
It returns the report
Every day, providers send the declared address a summary of everything sent in the domain's name, including what passed, what failed and where it came from. It is the only source of visibility into who is forging your name.
Source: RFC 7489, the official DMARC specification published by the IETF, which defines identifier alignment, the policies and the reports, Microsoft's official documentation on email authentication, and N-able University's email DNS configuration material.
Where DMARC's reach ends
- It is an outbound control, not an inbound one. DMARC stops the world from being deceived with your company's name. It does not filter what reaches you from other domains: that depends on inbound filtering on your side and on your provider evaluating the sender's policy. There is one exception worth its weight: when someone forges your own domain to your own team, it is your policy at blocking that takes the message down before the mailbox. Confusing the two leads to treating a problem as solved when it is not.
- It does not reach lookalike domains. Against a similarly spelled domain, registered by the criminal with its own valid authentication, no policy helps, because nothing there is being forged.
- It breaks when a message is modified in transit. Mailing lists and services that alter content take down the signature and the alignment, which calls for separate handling so legitimate mail is not lost.
- In monitoring, it does not stop a single forged message. A policy that only asks for reports is a measurement tool, and it is the minimum Gmail, Yahoo and Microsoft accept from volume senders, but it is not a defense: while it stays published, forged messages keep being delivered exactly as before.
The three DMARC policies
- No action (p=none) Asks providers to do nothing beyond sending the reports. It exists to discover who sends in the domain's name before blocking anything. A legitimate starting point and a terrible place to park.
- Quarantine (p=quarantine) Asks for the misaligned message to be treated as suspicious and sent to the spam folder. It is the middle rung, useful while there is still doubt about some infrequent sender.
- Reject (p=reject) Asks for the misaligned message to be refused before it is even delivered. It is the only state in which nobody can use your domain in the sender field, and the destination of any serious rollout.
- Beyond the three: the subdomain policy (sp=) A separate parameter lets subdomains be treated differently from the parent domain. When it is absent, subdomains inherit the parent policy. The risk lies in the subdomain that publishes a record of its own, and a weaker one: that record is the one that counts, and that is where spoofing gets in.
Why publishing DMARC became a market requirement
DMARC adoption nearly doubled in three years, but the number that matters is the other one: most domains that published the record stopped at the policy that asks for nothing. There is a decisive difference between three states, and the market routinely confuses the last two: the control absent, the control declared, and the control provably in force. A domain in monitoring shows up as protected in any shallow check, satisfies the line in the internal compliance report, and prevents not a single forged message. It is the rung where false comfort lives. And the yardstick is no longer internal: since February 2024 Gmail and Yahoo require authentication from volume senders, and since May 2025 Microsoft refuses delivery from volume senders to its consumer mailboxes that fall below the required level. Authentication left the territory of good practice and entered that of deliverability: without it, the proposal and the invoice stop arriving.
How to reach DMARC at p=reject without losing email
The path is always the same, and haste is what takes legitimate email down. Five steps, in order:
- Publish in monitoring, with reports going to a mailbox someone readsStart with the policy that asks for no action, pointing the reports at a monitored address. Reports landing in a mailbox nobody opens is the most common mistake, and it turns the measurement stage into waiting.
- Find out who really sends for your domainThe daily reports reveal every origin using your name, including systems signed up by other departments that never reached the IT inventory. It is that list, not anyone's memory, that decides when it is safe to move on.
- Fix the authentication of every legitimate senderFor each system that appears in the report and belongs there, make sure SPF covers the origin and DKIM signs with the right domain. When alignment refuses to line up, it is always one of those two.
- Move to quarantine and watchWith every legitimate sender passing, switch to quarantine and follow the reports for a few weeks. If something slipped through the mapping, it shows up in spam instead of vanishing.
- Move to reject and close the subdomainsThis is the destination. Check the subdomains too: any record published on one of them overrides the parent record, and an old, looser one keeps serving as a doorway. Only here does your company's domain stop being usable by third parties.
In practice
Ask what your domain's policy is, not whether it has DMARC. The answer “we have DMARC published” says nothing about protection: if the policy only asks for reports, anyone in the world can still send email carrying your company's name, exactly as before the record existed. What protects is not the presence of the record, it is what the record tells the world to do.
How Zamak handles DMARC
Zamak Technologies runs DMARC as a measured path to reject, never as a record published and forgotten: monitoring with reports landing in a mailbox that is read, mapping of every sender, fixing the SPF and DKIM of each one, and promotion to blocking only with evidence that nothing legitimate is lost, alongside the team that already looks after the domain. The email spoofing check shows in seconds which policy your domain publishes today. Watching those reports continuously is part of Managed Email Security and of Managed Cybersecurity in the Zamak Method.