If you've spent any time trying to fix email deliverability, you've seen DKIM and DMARC mentioned together constantly. They sound similar, they both live in your DNS settings, and they both show up in the same email-authentication tools — so it's natural to wonder whether they're redundant.
They aren't. DKIM and DMARC do completely different jobs, and you need both — alongside SPF — to actually protect your domain and keep your mail out of spam. Here's the difference, plainly.
What DKIM does
DKIM (DomainKeys Identified Mail) is about proving a message wasn't tampered with and came from a domain you control. Think of it as a tamper-proof seal stamped on every email you send.
Here's the mechanism: your mail server signs the message (specific headers and the body) with a private key. That signature travels with the email. When the receiving server gets it, it looks up your public key in DNS — at a record like:
`
selector1._domainkey.yourdomain.com
`
It verifies that the signature is valid and that the message wasn't changed in transit. If the signature checks out, the message is DKIM-valid.
The key detail is that DKIM is a signature, not a policy. It proves this specific message is authentic and unchanged, but it doesn't tell the receiver what to do if a message fails authentication. That decision is DMARC's job.
What DMARC does
DMARC (Domain-based Message Authentication, Reporting & Conformance) is a policy statement published in a single DNS TXT record that tells receiving servers what to do with messages that fail SPF and DKIM checks — and it requires those checks to pass against your domain.
A DMARC record looks like this:
`
v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@yourdomain.com; pct=100
`
DMARC does three distinct things:
- Requires alignment. The authentication result has to match the domain people actually see in the From header. An attacker can't just SPF-authenticate with their own domain and set a "From" that shows yours — alignment breaks that.
- Sets the enforcement policy.
p=none(report only),p=quarantine(send to spam), orp=reject(block outright). - Collects reports. The
rua=address receives daily aggregate XML reports showing every server that sent mail as your domain and whether each message passed or failed.
DKIM vs DMARC: comparison table
| Aspect | DKIM | DMARC |
|---|---|---|
| What it is | A cryptographic message signature | A DNS policy + reporting record |
| Main job | Prove a message wasn't tampered with | Tell receivers what to do on failure |
| Requires a key | Yes (private + public DNS key) | No |
| Enforces policy | No — it just signs | Yes — quarantine or reject |
| Provides reports | No | Yes (aggregate via rua=) |
| Needs SPF/DKIM to work | Independent | Depends on SPF and/or DKIM |
| Blocks spoofing alone? | Partially | Yes, with the right policy |
The simplest way to remember it: DKIM proves a message is genuine; DMARC decides what happens when it isn't.
Why you need both
A domain protected with only DKIM is missing enforcement. If someone spoofs your domain — sending mail that doesn't carry your valid signature — DKIM will simply fail for that message. But nothing tells the receiving server to do anything about the failure. The forged mail can still reach the inbox, and you'll have no idea it happened because you're getting no reports.
Adding DMARC closes that gap. Now the receiver has instructions: quarantine or reject mail that fails authentication and doesn't align with your From domain. And because DMARC returns aggregate reports, you can see exactly who's sending as you — and catch legitimate-but-broken sending sources before they hurt your reputation.
There's another practical reason you need both: spoofed mail can be signed too. An attacker can run their own DKIM key on their own domain and put your address in the From header. Without DMARC alignment checking that the signature matches the visible From domain, that forged mail can look DKIM-valid. DMARC is what ties the signature back to the domain recipients actually see.
The enforcement escalation
p=none→ monitoring only, nothing blocked. Start here.p=quarantine→ failed mail goes to spam.p=reject→ failed mail is blocked entirely.
Most teams move through these stages as their reports confirm every legitimate sender passes.
How SPF fits in
DKIM and DMARC aren't a complete story without SPF (Sender Policy Framework). SPF publishes a list of IP addresses and services allowed to send email as your domain:
`
v=spf1 include:_spf.google.com include:sendgrid.net -all
`
SPF checks the sending server; DKIM checks the message integrity. They cover different failure modes:
- SPF breaks when email gets forwarded, because the forwarding server isn't on your approved list.
- DKIM survives forwarding because the signature travels with the message.
DMARC can pass alignment through either SPF or DKIM. That flexibility is exactly why SPF, DKIM, and DMARC are usually described as a three-layer system: SPF approves senders, DKIM signs messages, and DMARC enforces policy while reporting what's happening. For a full plain-English walkthrough, see our guide to SPF, DKIM, and DMARC explained simply.
All three are also at the heart of the Gmail and Yahoo sender requirements — bulk senders are expected to have authentication, alignment, and a DMARC record, or face throttling and rejection.
Frequently asked questions
Can I use DKIM without DMARC?
You can, but it leaves your domain partly unprotected. DKIM on its own verifies your signed mail, but nothing enforces a policy on unsigned or spoofed mail, and you get no visibility into who's sending as you. Adding a p=none DMARC record is a low-risk way to start collecting that data.
Can I use DMARC without DKIM?
Yes, as long as your SPF is working and aligned. DMARC passes if either SPF or DKIM aligns with your From domain. That said, relying on SPF alone is fragile — SPF breaks on forwarded email — so enabling DKIM too gives you a stronger safety net.
Is DKIM or DMARC better?
They're not alternatives; they're complementary layers. DKIM provides the cryptographic proof, DMARC provides the policy and reporting. You want both. If you had to describe one as "more important" for protection, it's DMARC — because enforcement is what actually stops spoofing — but DMARC is useless without a working authentication method (SPF or DKIM) to enforce.
Are DKIM and DMARC required to send email?
For a single low-volume sender, technically no. But in practice, mail from domains without DKIM and DMARC increasingly lands in spam, and bulk senders hitting Gmail and Yahoo inboxes are effectively required to have them under the sender requirements. Setting them up is one of the highest-leverage deliverability fixes available.
Check your setup for free
Unsure whether your DKIM and DMARC are actually working — or aligned with your From domain? MailPosture's free scanner checks your SPF, DKIM, and DMARC records and gives you the ready-to-paste DNS fixes for anything missing. It's free for one domain, with Pro and Agency plans if you want 24/7 monitoring and alerts.