SPF, DKIM and DMARC each answer a different question about an email that claims to come from your domain. None of them is enough on its own.
SPF: is this server allowed to send for the domain?
SPF is a TXT record listing the servers and services allowed to send mail for your domain. The receiving server compares the connecting IP address with that list. Its limit: SPF checks the envelope sender (the bounce address), not the From address people see, and it breaks when mail is forwarded, because the forwarder's server is not on your list.
DKIM: was this message signed, and has it changed?
DKIM adds a cryptographic signature to the message headers and body. The receiver fetches the public key from the DNS of the domain that signed it, under a selector name chosen by whoever sends the mail, and checks the signature. A valid signature usually survives forwarding, unless the forwarder changes the message. Its limit: the signature can be made by any domain, so on its own DKIM says nothing about whether the signer is the domain in the From address.
DMARC: does it line up with the From address, and what should happen if not?
DMARC ties the two together. A message passes DMARC when SPF or DKIM passes and the domain that passed matches the visible From domain. This matching is called alignment. DMARC also publishes your policy, telling receivers what to do with mail that fails (p=none, p=quarantine or p=reject), and asks them to send you aggregate reports (rua=) so you can see who is sending as you.
Why you need all three
- SPF alone fails on forwarded mail and never looks at the From address.
- DKIM alone proves a message was signed, not who is allowed to use your name.
- DMARC without SPF or DKIM has nothing to align against.
With all three in place, and aggregate reports telling you which services send as you, you can move DMARC to an enforcing policy without blocking your own mail. DMARC policy progression explains how.