DKIM vs DMARC: They're Not Alternatives
The question "DKIM vs DMARC" assumes they're competitors. They're not. DKIM is a cryptographic signature. DMARC is a policy layer that uses DKIM (and SPF) to enforce and report. Conflating them is like asking "TCP vs HTTP" as though you pick one.
Here's what each actually does.
What DKIM does
DKIM signs outbound email with a cryptographic key. The signature lives in the DKIM-Signature header and proves that a message bearing that signature was created by an authorized server for a specific domain.
When you set up DKIM, you generate a keypair and publish the public key in DNS under a selector record. For example, if your selector is default, the DNS record lives at default._domainkey.example.com. The receiving server fetches that key, verifies the signature on the incoming message, and confirms: "This message was genuinely signed by someone who controls example.com's private key."
The signature covers specific headers and the body. If the message is modified in transit (a header added, the body rewritten), the signature fails. This makes DKIM useful for forwarding scenarios: even if the message hops through five servers, the original signature remains intact on the message bytes themselves.
DKIM doesn't set policy. A failed DKIM signature doesn't automatically reject the message. It just tells the receiving server the signature check result. Without DMARC, that result is useless information.
What DMARC does
DMARC ties authentication mechanisms to the visible sender domain. It answers the question: "I see this message claims to be from user@example.com. Did it come from someone I authorized?"
DMARC requires one of two things to pass:
- SPF alignment: The message passed SPF AND the server that sent it matches (or is authorized by) the domain in the From header.
- DKIM alignment: The message has a valid DKIM signature AND the
d=domain in the DKIM-Signature header matches (or is an organizational parent of) the From header domain.
"Organizational parent" means relaxed alignment. If you sign mail with mail.company.com but the From header says company.com, DMARC alignment still passes because mail.company.com is a subdomain of company.com. This is the default behavior, and it's usually what you want.
DMARC also sets policy. You declare what the receiving server should do with messages that fail alignment:
p=none: monitor only, deliver everything.p=quarantine: deliver to spam folder if alignment fails.p=reject: reject the message outright if alignment fails.
And DMARC enables reporting. Receivers send aggregate reports (rua=) and forensic reports (ruf=) to your specified address, showing you exactly which messages failed and why.
Without DMARC, there is no policy. Your DKIM signature is present and verifiable, but the receiving server has no instruction on what to do if alignment fails.
Why you need both
A practical example: you're running a SaaS and sending transactional mail from noreply@app.example.com via Resend. You configure DKIM so the signatures are valid. You point DMARC's rua= at your inbox.
A week in, your DMARC reports show that 5% of messages are failing SPF alignment. This happens because some customers are forwarding your mail, and forwarding breaks SPF (the original sender's IP is now two hops upstream). But your DKIM signatures are still valid. Because you have both DKIM and DMARC, the messages pass alignment via DKIM and land in the inbox. If you only had SPF, they'd fail alignment and fail DMARC because there's no DKIM to back you up.
Conversely, if you only had DKIM and no DMARC record, your signatures would be validated, but Gmail, Yahoo, and other receivers would have no policy to consult. They might still deliver you, or they might apply their own heuristics. You'd have no reporting, so you'd never know alignment was breaking.
The relationship
Think of it this way:
- DKIM is the authentication mechanism: "Here's a cryptographic proof this came from us."
- DMARC is the policy layer: "Trust authentication results and enforce this policy when alignment fails. Send me reports so I can see what's going on."
DKIM feeds into DMARC. DMARC uses DKIM's result as one input to its alignment decision. They're not alternatives. You configure both. If you're still untangling how the three pieces fit, the SPF, DKIM, and DMARC overview lays out the full chain.
Checking yours
Use the email authentication checker to see what your domain currently has. It will show you DKIM records, SPF alignment, and DMARC policy in one view. If you're missing either, you'll see it immediately.
If you only have DKIM, add a DMARC record with p=none to start collecting reports without breaking delivery. If you only have DMARC without DKIM, align your SPF or generate and publish a DKIM key.
Use the DMARC record checker to inspect and validate your specific DMARC record syntax.
Both tools work for any domain. Start with whatever you want to understand first.
Once your DKIM and DMARC are live, aggregate reports will start arriving within 24 to 48 hours. DMARCdrift turns the XML into a readable digest; free for one domain.