Is "Dee Mark" the Newest Country Music Sensation? No Clue — But Say Hello to DMARC for Your Emails, Not Dee Mark.

Is "Dee Mark" the newest country music sensation?

No clue. Never heard of her. But say hello to DMARC for your emails, not Dee Mark.

And before we go any further — we owe you an apology. We had this post ready to go for days. Written, fact-checked, sitting in the queue. What held it up wasn't the DMARC content. It was us, staring at a blank line, trying to come up with a headline pun as good as "sun tan lotion" or "Who is The Kim." We're not entirely sure we succeeded. But we stand behind the sun tan lotion one. That was a good one.

Okay. Onto the actual subject.

That's Part 3 of our four-part series on email security. Part 1 covered SPF — the guest list that checks which servers are authorized to send email for your domain. Part 2 covered DKIM — the digital signature that helps verify that a signed message wasn't altered on the way to the inbox. Both are useful on their own, and receiving mail systems can use their results when deciding what to do with a message. What SPF and DKIM don't do by themselves is tie everything back to the address the recipient actually sees and give the receiving server a policy from your domain for handling failures. That's where DMARC comes in.

What DMARC actually is

Picture a bouncer standing at the door of a club. Two people show up claiming to be on the list. The bouncer checks the guest list — that's SPF, checking whether the server that sent the message is authorized for the domain it used to send. The bouncer also checks the wristband — that's DKIM, verifying the message's digital signature and helping confirm that the signed parts weren't altered in transit.

But here's the thing: DMARC adds one very important check of its own before deciding what happens next. It makes sure at least one of those successful checks actually lines up with the domain the recipient sees in the From address. In bouncer terms, it's not enough to have a valid guest-list entry or wristband — the credentials also have to belong to the name you're claiming at the door.

DMARC is the bouncer.

It uses the results of SPF and DKIM, checks that at least one passing result aligns with the visible From domain, and then gives the receiving mail server your domain's requested policy for messages that fail:

• Don't request DMARC enforcement — monitor the results and let the receiving provider make its normal delivery decision (p=none)
• Quarantine it — ask the receiving provider to treat it as suspicious, often by sending it to spam or junk (p=quarantine)
• Reject it outright — ask the receiving provider not to accept the message at all (p=reject)

Without DMARC, SPF and DKIM can still influence what a receiving server does with a message — spam filters and anti-spoofing systems already pay attention to them. What you're missing is a policy published by your own domain that ties those checks to the visible From address and says, "if this doesn't line up, here's what we'd like you to do about it." DMARC turns separate authentication results into a domain-level policy with alignment and reporting behind it.

Do you need to worry about this?

If your business email runs through Microsoft 365, Google Workspace, or a similar provider, DMARC isn't automatic just because SPF and DKIM are set up. It's a separate DNS record you (or whoever manages your domain) has to publish on purpose. A lot of domains have SPF and DKIM configured correctly and still have no DMARC record at all — which means they're missing the piece that ties those checks to the visible From domain and publishes their own policy for what receiving servers should do when authentication doesn't line up.

There's also a middle ground worth knowing about: a lot of domains publish DMARC at p=none. That's not nothing — it lets receiving servers evaluate DMARC without your domain asking them to quarantine or reject failures, and if you've configured DMARC reporting, it can give you valuable data on what's passing, failing, and sending mail as your domain. But p=none is still a monitoring policy, not an enforcement policy. If someone's spoofing your domain, the receiving provider may catch it with its own security systems, but your DMARC record isn't asking that provider to quarantine or reject the message because of the DMARC failure.

What happens if you skip it (or leave it at "none")

Without an enforced DMARC policy, someone can still try to send an email that looks like it's from your business — your domain, your name. Modern providers such as Microsoft and Google have their own spam and anti-spoofing systems that may catch it, quarantine it, send it to junk, or reject it. But without an enforcing DMARC policy, your own domain isn't giving those providers an explicit DMARC instruction to quarantine or reject messages that fail authentication and alignment. Worst case, a convincing spoof slips through, looks legitimate enough that someone acts on it — wires money, hands over credentials, or opens something they shouldn't. That's the gap SPF and DKIM alone don't fully close. Receiving providers can act on those authentication results themselves, but DMARC adds alignment and lets your domain publish a clear policy for what should happen when a message claiming to be from you doesn't authenticate properly.

The bottom line

SPF checks which servers are authorized to send for a domain. DKIM verifies a digital signature and helps confirm that the signed parts of a message weren't altered along the way. DMARC ties those checks back to the domain the recipient actually sees, adds reporting, and lets the domain owner publish a policy for failures. Together, all three are what separates "we have some email security stuff configured" from "our domain is actually protected."

There's still one more piece to this series — the lesser-known technologies that go beyond the basics, the kind of thing that separates "protected" from genuinely polished. That's Part 4, and yes, we'll try to come up with a headline pun for that one too.