Every Workspace interview asks this, and most answers are three definitions in a row. The definitions are the easy half. What separates someone who has done it is knowing why the three exist together, and what actually goes wrong when you tighten them.
What each one does
- SPF publishes which servers are allowed to send for your domain. It is checked against the envelope sender, which is not the address the recipient sees.
- DKIM signs the message with a key you publish in DNS, so a receiver can verify the message was not altered in transit and that it came from someone holding the key.
- DMARC ties the other two to the visible From address through alignment, tells receivers what to do when neither passes, and asks them to send you reports.
Alignment is the whole point
This is the part worth being able to explain. SPF validates the envelope sender and DKIM validates the signing domain. Neither of those is necessarily the address a human reads in their mail client.
DMARC requires that a passing SPF or DKIM result aligns with the From domain the user actually sees. Without it, an attacker can pass SPF for a domain they control while displaying your domain in the From field, and the mail looks authenticated to a naive check.
So: SPF and DKIM without DMARC leave unprotected exactly the thing the recipient is looking at.
Moving from p=none to p=reject
The policy escalation is where people get hurt, and it is a discovery problem long before it is an enforcement problem.
1. Publish p=none and collect reports. You are not protecting anything yet. You are finding out who sends mail as your domain.
2. Enumerate every sender, including the ones nobody told you about. The marketing platform, the ticketing system, the finance tool, the ancient server in a cupboard that sends invoices. This step takes weeks, not days, and it is the entire job.
3. Fix alignment for each, usually by signing with DKIM on a subdomain that the vendor controls, rather than by stretching your SPF record until it breaks.
4. Move to quarantine with a percentage and raise it gradually while watching the reports.
5. Then reject.
Rushing this is how a company stops receiving its own invoices, and the failure is silent from your side because the mail is rejected at the recipient.
Diagnosing "your mail goes to our spam folder"
A partner reports it. Everything else is guessing until you get the full headers of an actual message.
- Read the authentication results: did SPF pass, did DKIM pass, and crucially did either align.
- Check whether something in the path relayed the message and broke the signature, which mailing lists and forwarding both do.
- Check your DMARC aggregate reports for that receiver specifically.
- Only then look at reputation and content.
Reputation problems that are really alignment problems are extremely common, and fixing the authentication often resolves what looked like a content issue.
Where it goes wrong
SPF records that exceed the lookup limit. Every vendor you add costs a DNS lookup, and past the limit the record fails rather than degrading. Consolidate rather than appending forever.
Assuming SPF covers the visible sender. It does not, and that misunderstanding is why DMARC exists.
Going to reject on a schedule rather than on evidence. The date should follow the reports, not the other way round.
Forgetting subdomains and parked domains. A domain you own and never send from is a free identity for a spoofer unless it has a policy.
The short version
SPF authorises servers, DKIM signs messages, DMARC binds both to the visible From address through alignment and tells receivers what to do on failure. Move to reject only after the reports show you have found every legitimate sender, because the hard part is discovery, not policy.