DMARC works by adding two things on top of SPF and DKIM: an alignment check that ties authentication to the domain your recipients actually see, and a reporting loop that tells you what's happening. When a receiving server gets a message claiming to be from your domain, it runs a short, well-defined sequence to decide what to do with it.
What happens when a receiver gets your email?
Here's the sequence a mailbox provider runs, start to finish:
- Read the From domain. The server pulls the domain out of the visible From address (the technical name is the RFC5322.From). This is the identity DMARC protects, because it's the one your recipient sees.
- Look up your DMARC record. It queries DNS for
_dmarc.yourdomain.comto find your published policy and reporting addresses. No record, no DMARC evaluation. - Check SPF. It verifies the message came from a server your SPF record authorizes, and notes which domain SPF authenticated.
- Check DKIM. It validates the DKIM signature and notes the signing domain.
- Test alignment. It compares the SPF and DKIM domains against the From domain. This is the step that makes DMARC more than the sum of its parts.
- Apply your policy. If the message passed (either path aligned), it's delivered normally. If it failed, the receiver follows your
p=instruction: nothing for monitor mode, quarantine, or reject. - Record it for reporting. The outcome gets added to the aggregate report that lands in your mailbox later.
What is alignment, and why does it matter?
Alignment is the heart of DMARC, so it's worth slowing down on. SPF and DKIM each authenticate a domain, but not necessarily the one your recipient sees. SPF checks the Return-Path (the bounce address), and DKIM checks whatever domain signed the message. A spammer can pass both for a domain they control while still showing your brand in the From line.
DMARC closes that by requiring the authenticated domain to match your From domain. SPF alignment means the Return-Path domain lines up with the From domain. DKIM alignment means the signing domain lines up with the From domain. The match can be relaxed (the organizational domain is the same, so mail.example.com aligns with example.com) or strict (an exact match). Relaxed is the default.
How much has to pass?
Just one path. A message passes DMARC if either SPF passes and aligns, or DKIM passes and aligns. You don't need both. This is deliberately forgiving, because mail takes messy routes through the internet and one mechanism often survives where the other breaks.
| Path | Domains compared | Passes DMARC when |
|---|---|---|
| SPF | Return-Path and From | SPF passes and the domains align |
| DKIM | Signing domain and From | DKIM passes and the domains align |
| Either | Both of the above | At least one passes and aligns |
DKIM alignment is the one to lean on, because it tends to survive forwarding where SPF doesn't. That's also why forwarding is a common source of confusing report data, covered in how to fix DMARC failures.
What does the receiver do with a failure?
Whatever your policy tells it to, within reason. Your p= value is a request, and most major providers honor it:
p=none: do nothing different, just report. This is monitor mode.p=quarantine: treat failing mail as suspicious, usually the spam folder.p=reject: refuse the message outright.
The policy choice is yours to ramp over time, which is the subject of what is a DMARC policy. The reporting half of the loop is what makes that ramp safe: you see exactly who's passing and failing before you tighten. Decoding those reports is covered in how to read a DMARC report.
Where does this leave you?
DMARC works because it checks the one identity that matters, the visible domain, and lets either authentication path carry the message. Publish a record, let the reports show you the full picture of who sends as you, and tighten the policy when the data says it's safe. If you want the conceptual map of all three protocols, SPF vs DKIM vs DMARC lays them side by side, and the authentication guide covers the Bird specifics.