The short answer
SPF lists which servers may send for your domain. DKIM adds a cryptographic signature that proves the message was not altered. DMARC ties both to the From address your reader sees, tells receivers what to do on failure, and sends you reports. Start at p=none and read the reports first.
Almost every guide to these three records tells you what to paste into DNS and stops there. That is why so many small businesses end up with all three published and still no idea what they bought. The useful thing to understand is not the syntax. It is that each record checks a different address, and only one of the three checks the address your customer actually reads.
Email has two "from" addresses, and that is the whole problem
When a message is delivered, two separate conversations happen. First there is the SMTP transaction between machines, which opens with a MAIL command carrying a reverse-path in angle brackets - the mailbox used to report errors [4]. That is the envelope sender. The standard is explicit that this mailbox can be different from the actual sender's mailbox, and notes that with mailing lists this arrangement is common and useful, so that bounces go to the list maintainer rather than the original writer [4].
Second, inside the message data, there is the From header field defined by the Internet Message Format [5]. That is the one your mail program renders. Nobody has ever looked at an envelope sender in daily life; everybody looks at the From line.
Those two addresses do not have to match. Nothing in the base protocols requires it. Hold on to that fact, because it explains why SPF alone was never going to stop anyone impersonating you.
SPF: which servers are allowed to speak for your domain
SPF is a list published in DNS. The specification describes a protocol by which a domain owner can authorize hosts to use their domain names in the MAIL FROM or HELO identities, and compliant receivers use the published record to test whether the connecting mail server was permitted to use that identity [1]. In plain terms: your record says "mail claiming to come from my domain should only originate from these servers," and the receiving server checks the IP address that just connected against that list.
Two limits are worth knowing. The first is the identity problem already described - SPF checks the envelope and the HELO name, and the spec warns that checking other identities against SPF records is not recommended because there are known cases that give incorrect results, mailing-list rewriting being the example it gives [1]. The second is mechanical: an SPF evaluation may only trigger ten DNS-lookup mechanisms, and exceeding that produces a permanent error [1]. Every third-party sender you add with an include statement eats into that budget. Businesses that bolt on a newsletter tool, a booking tool and an invoicing tool over three years frequently break their own SPF record without ever seeing an error message.
DKIM: a signature that travels with the message
DKIM works completely differently. It lets a person, role or organization claim some responsibility for a message by associating a domain name with it, and that claim is validated through a cryptographic signature, with the verifier querying the signing domain's DNS to retrieve the public key [2]. There is no IP address involved and nothing about who connected.
What gets signed is the point. The signature covers a set of chosen header fields plus a hash of the canonicalized message body, carried in the signature as a separate value that the verifier recomputes and compares [2]. If someone edits the body in transit, the recomputed hash will not match and verification fails. That is what people mean when they say DKIM detects tampering.
It also explains why DKIM often survives a forward when SPF does not. The signature is inside the message, and the specification notes that relays between author and recipient typically make no substantive change to message content and thus preserve the DKIM signature [2]. The connecting IP address changes with every hop; the signature does not care. Note also that a verification failure does not force rejection of the message under DKIM alone [2] - on its own, DKIM asserts, it does not enforce.
DMARC: alignment, policy, and reports
Now the two gaps show up. SPF authenticated an envelope your customer never sees. DKIM authenticated whichever domain happened to sign, which is not necessarily your domain either. A scammer can register a disposable domain, publish a perfectly valid SPF record for it, sign with valid DKIM for it, and put your business in the From line. Everything passes. Nothing protected you.
DMARC's real contribution is closing exactly that gap. It authenticates use of the From domain by requiring that it match - be aligned with - an authenticated identifier [3]. The specification says the From field was chosen as the central identity because it is a required header field and most mail programs present it as the originator of the message, rendering it to end users, which makes it the prime target for abuse [3]. So a message passes DMARC when SPF or DKIM passes and the domain that passed lines up with the visible From domain. One passing check with a mismatched domain is not a pass. Alignment also cannot exist with a DKIM signature that does not verify [3].
The second contribution is the instruction. Receivers look up your DMARC record and read the p tag: none means you request no specific action; quarantine means you want failing mail treated as suspicious, which depending on the receiver means the spam folder, extra scrutiny, or a flag; reject means you want it refused, and rejection should happen during the SMTP transaction [3].
The third contribution is the one people underuse. Before DMARC there was no widely available mechanism to communicate handling policy or to request reporting, and the spec observes that without feedback reports, senders who implemented authentication had difficulty telling how effective it was [3]. Add an rua address and receivers send you aggregate feedback about mail claiming to be from your domain [3]. That is how you discover the invoicing tool nobody told you about.
Why you start at none and not at reject
The order is the part that separates a working deployment from an outage. At p=none, receivers change nothing, and you spend a few weeks reading reports until you can name every legitimate source of mail using your domain. Only then do you tighten. The specification lists deploying DMARC in a reporting-only mode among the remedies for a domain whose authentication is not yet solid [3], and it provides a pct tag precisely so owners can enact a slow rollout, noting that the prospect of all-or-nothing prevents many organizations from experimenting with strong authentication [3].
Skip that and the failure is silent. You will not get a warning; your own mail will simply start disappearing, and you may not learn about it for weeks, because the person who did not receive your quote assumes you never sent one.
The honest limits
Three things DMARC at p=reject will not do for you.
- It is not a spam filter. It protects your domain in other people's inboxes. It does nothing about the unwanted-but-legitimate mail landing in yours. Content analysis is explicitly listed as out of scope [3].
- It does not stop lookalikes. The spec states plainly that DMARC does not attempt to solve all problems with spoofed or fraudulent email, and in particular does not address visually similar cousin domains or abuse of the human-readable display name in the From field [3]. Someone sending as "Your Business" from an unrelated address is out of reach.
- Misconfiguration hurts only you. Enforcement applies to your domain. Get it wrong and the mail that stops is your own.
There is a related trap with forwarding. Transiting a mediator such as a mailing list often causes either authentication or alignment to be lost, and mail sent by authorized independent third parties might not be aligned either, preventing a pass [3]. If your staff auto-forward work mail to a personal account, or you post to industry lists, test before you enforce.
What a small business should actually do
If you send only ordinary person-to-person business mail from a single provider, SPF and DKIM together get you most of the available benefit for an afternoon of work, and they are the two your provider can usually configure for you. Publish both, correctly, once.
Then add DMARC at p=none with a reporting address, and leave it there. Reports cost you nothing and tell you what is really sending as your domain. Move to quarantine when the reports are boring, and to reject when quarantine has been boring for a month. If you send invoices, quotes or booking confirmations - anything worth forging - work toward enforcement deliberately rather than skipping steps. If you send a newsletter through a third party, expect to authorise that vendor properly rather than hoping alignment happens by accident.
None of this is exotic. It is three records, three different jobs, and one sensible order.