Have you ever received an email from a source you usually trust or that seems legitimate at first glance, but the message is out of character or just plain odd? It’s vague, prompts urgency, maybe even tells you to give them your sensitive information (like a certain Nigerian prince).
That’s what happened to one of our Office Hours viewers, who approached Nathan, our host, for advice during our April 4, 2026, livestream. Despite having DMARC in place, their agency’s email address was still spoofed.
So what gives? That’s exactly what we are here to unravel. We’ll discuss what spoofing is, the purpose of DMARC, and how to handle such fake emails.
The viewer’s question
To better understand the situation and set a baseline for expectations about DMARC, let’s take a look at our viewer’s question.
A client of mine received a poor spoof email this morning using our brand with a Gmail account. The message urged a quick follow-up since they [the scammers] haven't heard back yet, and to prevent disruptions, it's important they verify our client’s website's data.
Thankfully, the client realized the email was not from us and sent it to confirm. Apart from DMARC on our domain setup and letting clients know we don't use Gmail, is there anything else we can do to prevent this?
There are several things to unpack here:
What is email spoofing?
What is DMARC?
Why didn’t DMARC prevent the email spoofing?
How do we deal with email spoofing?
The quick answer is: DMARC doesn’t prevent others from spoofing your email, and there isn’t a silver bullet for dealing with that. The main point of this blog post is to explain what DMARC is and what it can do, as that’s the primary misconception in our viewer’s case.
What’s email spoofing?
Before we dive into DMARC, let's quickly explain what email spoofing is so we have all the facts straight.
At its core, email spoofing is the act of sending an email pretending to be someone else. There are two primary ways of doing this.
Domain spoofing: This is the trickier of the two methods to spot as malicious. It’s when an attacker sends an email that appears to come directly from a legitimate, well-known, or even your domain (e.g., [email protected]). It’s done by forging the “From” and “Reply-to” headers in the email.
Brand impersonation: This method has nothing to do with your domain and is instead an exercise in testing the recipient’s perceptiveness. It relies on recipients not noticing that the email comes from a generic email service (like Gmail), or a subtly different domain (a missing or extra letter).
The second scenario is what happened to our viewer. Their client received an email from a Gmail account ([email protected]), hoping the recipient doesn’t notice the @gmail.com part.
Unfortunately, DMARC wouldn’t have helped in our viewer’s case. That’s not its purpose. Read on to learn what DMARC is and what it does.
What is DMARC?
DMARC stands for Domain-based Message Authentication, Reporting, and Conformance.
While the name is a mouthful, it does describe DMARC’s purpose pretty well. In other words, it’s an email security protocol designed to verify that a sender is allowed to send email from that domain, while also reporting on any infractions.
It builds on two other security protocols (SPF and DKIM; more on them in a second) and instructs email servers on how to handle emails that claim to come from you but fail authentication checks.
This is where we must draw an important distinction, which will show why DMARC can’t couldn’t have helped in our viewer’s situation. DMARC protects your domain. I; it cannot protect your brand name from being used by someone else.
And to round out what DMARC does, we must mention the two pillars it relies on: SPF and DKIM.
What are SPF and DKIM?
DMARC doesn’t work in isolation. Instead, it functions alongside two other email authentication standards. Without SPF and DKIM, DMARC would not accomplish anything.
SPF (Sender Policy Framework): SPF shows which mail servers are allowed to send on behalf of your domain. If itthe server isn’t, such as when someone is spoofing your domain name, it fails the SPF check, and most email servers will deny the message.
DKIM (DomainKeys Identified Mail): On the other hand, DKIM is a signature that verifies to email servers that the email was not tampered with in transit. It adds a cryptographic signature to outgoing emails, which the receiving server verifies against a public key stored on the sending server.
Finally, DMARC serves as a directive to the recipient server on what to do when authentication fails, since neither SPF nor DKIM does.
All three of these authentication methods live in the DNS zone of your domain. They are all TXT (text) records that contain all the rules and keys required for successful email deliverability.
How SPF, DKIM, and DMARC fit together
Let’s put this letter soup together and show you exactly what happens when you send an email from your domain (for example, [email protected]).
It’s a straightforward process that every major email provider does in one way or another to ensure that no unwanted mail reaches its customers’ inboxes.
Nathan Ingram talks extensively about it in our Who Stole My Email livestream, which we strongly suggest you watch if you want to learn all the nitty-gritty details about SPF, DKIM, and DMARC.
In the meantime, here’s a simplified explanation of how the three records work together.
When you hit “Send,” the sending server (where your domain is) attaches a DKIM signature to the email header.
After your message arrives, the receiving server checks SPF first. It checks the sending server’s IP address or hostname to determine whether they are allowed to send emails for your domain. That’s all noted in the SPF record in your domain’s DNS zone.
Then, it uses the public DKIM key available in your DNS zone to verify the DKIM signature. If the email hasn’t been altered, the key will match.
Once that’s done, the receiving server checks the DMARC record and its policy. If everything checks out and aligns (the SPF/DKIM match your domain), the email goes through.
That’s what happens in the best scenario. SPF, DKIM, and DMARC all check out, and the email goes through. But what if they don’t? That’s when the different DMARC policies come into play.
There are three of them, and they affect what the receiving server does with an email that doesn’t pass its SPF and DKIM checks and alignments.
p=none – The server just monitors the offending message.
p=quarantine – The server sends the suspicious message to spam.
p=reject – The server blocks the message entirely.
Which one should you use? Nathan himself recommends you use quarantine, never none, and only change it to reject when you are absolutely sure your SPF and DKIM records are correct.
Finally, DMARC also generates reports that the receiving server can send to an email address you’ve specified in the DNS record. There are two types:
Aggregate reports (RUA): These are broad reports of who’s sending emails from your domain.
Forensic reports (RUF): These provide more granular detail on individual failures.
Setting a DMARC record is pretty easy, and you can read our Knowledge Base entry about it, use an online tool, or ask your favorite chatbot to generate one.
So what can you do about spoofed emails?
DMARC, in conjunction with SPF and DKIM, should be enough to handle domain spoofing for the most part. Receiving servers will detect the SPF and DKIM discrepancies and block the suspicious message from reaching its intended recipient.
But DMARC is not the solution for our viewer’s issue. When it comes to brand spoofing, the best thing you can do is report the email address. Gmail has an abuse reporting form, and while it’s not guaranteed to result in immediate action, it’s the right first step.
The silver lining is that you can use such a situation to build trust with your clients. As Nathan put it:
This is solved by just communicating with your clients to let them know, " Hey, this just happened. This is why it's important that I'm part of your world to help you think through these things.
Letting your client know in such a calm manner that you are aware of the issue and educating them on the correct communication channels will go a long way.
DMARC rounds out email authentication
DMARC is an important and powerful standard that every sender, regardless of email volume, should set up. It stops attackers from sending emails that appear to come directly from your domain. That’s important!
And while it’s not a silver bullet and won’t solve email spoofing once and for all, it will ensure that receiving servers actually deliver your emails and prevent others from impersonating you. In the past, it was optional, but it’s now mandatory for many major email providers.
Set up your SPF, DKIM, and DMARC records correctly, and if you have any questions about them, WordPress, AI, or anything else hosting-related, join us for Office Hours. Nathan and the community will be glad to answer live!
FAQ
How do I read a DMARC aggregate report, and what should I actually be looking for in it?
Aggregate reports (RUA) arrive as XML files, which aren't easy to read raw. Most people use a free tool like MXToolbox's DMARC analyzer, dmarcian, or Postmark's DMARC digests to parse them into something human-readable.
What you're primarily looking for is any source appearing in the report that isn't a server you recognize as authorized to send email on behalf of your domain. Each report row shows a sending IP, how many messages it sent, and whether they passed SPF and DKIM alignment. Rows showing failures from your own legitimate sending infrastructure are actionable.
If someone is impersonating my brand using a look-alike domain is there anything technical I can do?
The options are more limited than with direct domain spoofing, but there are a few practical measures. First, registering common variations of your domain, like misspellings, hyphenated versions, different TLDs (.net, .co, .org), proactively removes the inventory attackers rely on for look-alike domains.
Second, some domain registrars and third-party services offer brand monitoring that alerts you when new domains resembling yours are registered, giving you early warning of a potential impersonation campaign.
Third, setting up DMARC with reporting enabled on your primary domain won't catch look-alike domain abuse directly, but the forensic reports (RUF) can sometimes surface related activity. For high-profile brands, working with a domain abuse protection service is the most comprehensive option.
Can having DMARC set to p=reject cause any of my own legitimate emails to get blocked?
Yes, and this is exactly why the blog recommends starting with p=quarantine rather than jumping straight to p=reject. If any of your legitimate sending sources aren't included in your SPF record or aren't signing with DKIM, those emails will fail DMARC alignment and get blocked entirely under a reject policy. With p=quarantine, those failures land in spam rather than disappearing completely, which makes it much easier to notice and fix the missing authentication before you tighten the policy further.
Does DMARC need to be set up on all my domains, including ones I don't actively send email from?
Yes, and this is something many organizations overlook. Domains that don't send email are actually particularly attractive to attackers for domain spoofing, precisely because their owners are less likely to be monitoring them and less likely to have authentication records in place.
Setting up DMARC on a non-sending domain is straightforward: publish an SPF record that explicitly states no servers are authorized to send (v=spf1 -all), and a DMARC record with p=reject to instruct receiving servers to block any emails claiming to come from that domain. There's no DKIM needed since you're not sending legitimate mail.