What Are DMARC,
SPF & DKIM?
The three records that decide whether the world can trust email from your domain — explained in plain English.
Email was built in an era of trust, so by default anyone can put your domain in the From lineof a message. That’s how phishing and CEO-fraud work: an attacker sends mail that looks like it came from you, and your customers or staff have no easy way to tell it’s fake.
SPF, DKIM, and DMARC are the three records that fix this. Together they let receiving mail servers verify that a message genuinely came from you — and reject it when it didn’t. Here’s what each one actually does.
SPF, DKIM & DMARC, One at a Time
SPFSender Policy Framework
A list, published in your DNS, of the mail servers allowed to send email for your domain. When a server receives mail claiming to be from you, it checks whether the sending IP is on your SPF list.
Think of it as the guest list at the door — only the servers you named are allowed to send as you.
DKIMDomainKeys Identified Mail
A cryptographic signature added to every message you send. The receiving server uses a public key in your DNS to verify the signature, proving the message really came from your domain and wasn’t altered in transit.
Think of it as a tamper-proof wax seal — if anyone changes the letter, the seal breaks.
DMARCDomain-based Message Authentication, Reporting & Conformance
The policy that ties SPF and DKIM together. It tells receiving servers what to do when a message fails authentication, and it sends you reports showing exactly who is sending email as your domain.
Think of it as the rulebook — it decides what happens to mail that fails the guest list or the seal.
SPF + DKIM prove a message is real. DMARC decides what happens when it isn’t.
When mail arrives, the receiver checks SPF and DKIM. DMARC then asks one question: does an authenticated result line up with the domain your recipient sees? If yes, the mail is trusted. If no, your DMARC policy — not the attacker — decides whether it’s delivered, junked, or blocked.
What p=none, p=quarantine & p=reject Mean
Your DMARC policy is set with a single tag. The journey to protection is moving through these three settings — safely.
p=noneMonitor only
Nothing is blocked. You just collect reports to learn who sends as your domain. This is the safe starting point — never the finish line.
p=quarantineSend to spam
Mail that fails authentication is routed to the spam/junk folder. A useful middle step while you confirm every legitimate sender passes.
p=rejectBlock outright
Mail that fails authentication is refused before delivery. This is the goal — spoofed email can no longer reach anyone.
The catch: jumping straight to p=rejectbefore every legitimate sender is authenticated will silently block your real email — invoices, password resets, newsletters. The order of operations matters more than the records themselves.
Free Tools to Build & Check Your Records
Common Questions
Do I need all three — SPF, DKIM, and DMARC?
Yes. SPF and DKIM each prove something about a message, but on their own they don’t tell receivers what to do when a check fails, and they don’t report back to you. DMARC adds the policy and the visibility. You need all three aligned for real protection.
What does “alignment” mean?
Alignment means the domain that passes SPF or DKIM matches the domain shown in the From address your recipients see. A message can pass a raw SPF check yet still fail DMARC if the domains don’t line up. Getting alignment right for every sender is the tricky part.
Is publishing a DMARC record enough?
Not by itself. A record at p=none provides reporting but blocks nothing — spoofers are unaffected. Protection only kicks in at p=quarantine and p=reject, and you can only get there safely after authenticating every legitimate sender first.
Why is reaching p=reject hard to do alone?
Most organizations send mail from far more services than they realize — email platform, CRM, invoicing, support desk, marketing tools, payroll. If even one isn’t authenticated when you move to p=reject, its mail gets blocked. The work is finding every sender and fixing each one before you tighten the policy.
How does this relate to Google and Yahoo’s 2024 rules?
Since February 2024, Google and Yahoo require bulk senders to use SPF, DKIM, and a published DMARC record. Domains without proper authentication get rejected or sent to spam — which is why email authentication moved from “nice to have” to a baseline requirement.
Want Someone to Get You to p=reject Safely?
We inventory every sender, fix your SPF and DKIM, and walk your domain to full enforcement — without breaking a single legitimate email.
From Understanding It to Being Protected
Now you know what the records do. We’ll make them work for your domain — inventory, authenticate, enforce, and monitor.