Email authentication
SPF, DKIM and DMARC are three parts of one system. Understanding what each does explains why all three are needed.
Three mechanisms, three jobs
SPF publishes which servers may send mail using your domain in the envelope sender. DKIM signs messages with a key published in your DNS. DMARC ties both to the From address a reader actually sees and says what to do when they fail.
None of the three is sufficient alone, which is why advice to "just add SPF" tends to disappoint.
Why SPF alone does not stop spoofing
SPF authenticates the envelope sender used during the SMTP exchange, not the From header displayed to the reader. A message can pass SPF for one domain while showing a completely different From address.
SPF also breaks on forwarding, because a forwarded message arrives from the forwarder's server rather than from anything the original domain authorised.
What DKIM adds
DKIM signs the message itself, so the signature survives forwarding in a way SPF cannot. It also proves the signed content was not altered in transit.
DKIM still says nothing about the From header on its own. A message can carry a valid signature from one domain and display another.
DMARC closes the gap
DMARC requires that the domain authenticated by SPF or DKIM aligns with the From header domain. Either mechanism passing is enough, which is what makes the combination survive both forwarding and mailing lists more often than either alone.
It also adds reporting, which is the part that makes deployment practical: you can see who is sending as your domain before you enforce anything.
The order to deploy them
Publish SPF and DKIM first and confirm your legitimate senders pass both. Then publish DMARC at p=none with a reporting address and read the reports until the picture is complete.
Only then raise the policy to quarantine and eventually reject. Enforcing before your own senders align is the standard way to lose legitimate mail, and the reports exist precisely to stop you doing it.