DMARC is an email-authentication protocol for the domain shown in a message’s From address. It checks whether SPF or DKIM passes and aligns with that domain. A domain owner can publish a policy requesting how receiving systems handle messages that fail, and can request reports about use of the domain.
DMARC helps reduce successful exact-domain spoofing. It does not inspect message content, prove that a message is trustworthy, stop lookalike domains, protect a compromised mailbox or guarantee inbox placement.
Standards note: DMARC is specified in RFC 9989.
How SPF, DKIM and DMARC fit together
SPF
Checks whether the connecting server is authorised for the envelope-sender domain.
DKIM
Checks a cryptographic signature associated with a signing domain.
DMARC
Requires an SPF or DKIM pass that aligns with the visible From domain, then evaluates the published policy.
A message can pass SPF for one domain while displaying another domain in the From field. DMARC’s alignment requirement is what connects authentication to the domain a recipient sees.
SPF or DKIM pass + alignment → DMARC result → receiver handling decision
The three policy values
p=none
Monitoring mode. The domain owner expresses no requested handling for failures and can collect aggregate reports.
p=quarantine
The domain owner asks receivers to treat failing messages with additional suspicion, often by placing them outside the inbox.
p=reject
The domain owner asks receivers to refuse failing messages.
These are requested policies. Receiving systems can apply local policy, so a published value is not a universal delivery guarantee.
What aggregate reports show
Aggregate reports summarise observed use of the domain, including source IP, message counts, SPF and DKIM results, alignment and receiver disposition. They help domain owners identify legitimate services, authentication gaps and unfamiliar sources. They do not identify the person behind an IP address or reproduce a full inbox view.
A safe implementation path
- Inventory systems that send mail using the domain.
- Publish a valid monitoring record with an approved aggregate-report destination.
- Collect enough report evidence to cover normal and periodic sending.
- Fix SPF or DKIM alignment for every legitimate source.
- Move policy only when the evidence supports the change and a rollback path exists.
- Continue monitoring after enforcement because sending systems change.
Read the policy progression guide
What DMARC does not do
DMARC is not an inbound spam filter, malware scanner, email gateway, backup system or complete anti-fraud control. It does not stop attacks using lookalike domains, display-name deception or a genuinely compromised account. Those risks require other controls.
FAQ
Does DMARC require both SPF and DKIM to pass?
No. A DMARC pass requires at least one of SPF or DKIM to pass with alignment to the visible From domain. Configuring both provides useful resilience across different mail flows.
Will DMARC block legitimate email?
A monitoring policy does not request blocking, but stronger policies can affect legitimate mail that is not authenticated and aligned. That is why report analysis and staged progression matter.
Can I publish p=reject immediately?
It is technically possible, but unsafe unless every legitimate sender is already known and aligned. Begin with evidence and move policy deliberately.
Does DMARC guarantee that email reaches the inbox?
No. Authentication is only one input to receiving systems. Reputation, content, receiver policy and other factors still apply.
Does DMARC stop all phishing?
No. It addresses unauthorised use of an exact From domain. It does not stop lookalike domains, display-name attacks or compromised accounts.
See what your domain publishes now
Run a point-in-time DNS check, then use aggregate reports for ongoing evidence.