Picture this. You get an email from your bank. It looks right – the logo, the tone, even the sender address. So you click the link, type in your password, and hand it straight to a criminal.
That’s what an email spoofing attack looks like in practice. The message never came from your bank. Someone simply faked the “From” field, and your inbox had no way to warn you.
This isn’t rare. The FBI reported that business email compromise – a form of spoofing targeting companies – has caused over $55 billion in losses globally. And that’s just the cases that got reported.
So why does email spoofing still work so easily? Because the original email system was built for trust, not security. There’s no built-in way to verify who actually sent a message – unless specific protections are in place.
That’s where SPF, DKIM, and DMARC come in. Together, these three protocols form the foundation of modern email authentication. They make it much harder for anyone to impersonate your domain or trick your contacts.
By the end of this guide, you’ll understand exactly how each one works – no technical background required.
What Is Email Spoofing – And Why Should You Care?
Email spoofing is sending an email from one person’s email address to trick the recipient into thinking it is coming from another person’s email address. Email spoofing is similar to writing a fake return address on a letter and sending it to someone. The person opening the email will see a familiar name, but the email is coming from somewhere completely different.
In order to understand why this works, you have to know one dirty little secret about email. The way email works is called SMTP, or Simple Mail Transfer Protocol. It was created in 1982. At this time, the internet was small, academic, and based on trust. No one thought to implement a way to verify email senders. This is why anyone can send email from anywhere they want.
The Two Main Types of Email Spoofing
The simple one is the display name spoofing. In this case, the scam artist retains the original sending domain but changes the display name to something like “PayPal Support” or “Your CEO.” This works because the average user tends to look at the name and not the actual sending address.
The other one is domain spoofing. In this case, the fake sender’s address contains the actual domain of the user, like [email protected], despite the fact that the mail never originated from there. This is the more serious of the two, and this is what the three protocols are designed to prevent.
Real-World Consequences
Email spoofing is the driving force behind some of the most expensive scams going around today. A fake invoice from a vendor you trust, a message from the “CEO” asking the finance team to wire some cash, or a login page that looks exactly like your bank’s login page are all examples of this kind of attack. The common thread among all of these is the spoofed sender, which makes the victim believe the message or page.
One more thing to clarify is that while the line between the two can be fuzzy, email spoofing and phishing are not the same thing. Spoofing is the act of falsifying the sender information, while phishing is the overall act of the scam, which uses spoofing as a method, but the intent of the act is to obtain login credentials, money, or information. Spoofing can be done without phishing, but the majority of all phishing attacks involve a spoofed sender as a method to gain the trust of the victim.
How Does Email Header Spoofing Actually Work?
Every email you send actually carries two “from” addresses – and most people never see both of them.
The first is the envelope sender, also called the Return-Path. This is the technical address used between mail servers during delivery. Think of it as the real return address written inside the package, hidden from the person who opens it.
The second is the “From:” header – the address your inbox displays. This is what you see in Gmail, Outlook, or Apple Mail when a message lands. Critically, these two addresses don’t have to match. The email standard doesn’t require it.
An attacker exploits exactly this gap. They send a message through their own mail server – so the envelope sender points to their domain – while setting the visible “From:” header to anything they like. Your bank. Your boss. A government agency.
So why don’t Gmail and Outlook catch this automatically? Sometimes they do. But without proper mail server authentication records in place, inbox providers have very little to compare against. They can flag suspicious patterns, but they can’t verify identity they were never given the tools to check.
That’s the gap SPF, DKIM, and DMARC are designed to close.
The Three Fixes: What Is SPF, DKIM, and DMARC?
Fortunately, the email system has evolved. Three email security protocols now exist to protect your business email from the verification gap that spoofing exploits – and together, they form a layered defense that’s genuinely hard to beat.
Think of it like boarding an international flight. SPF is your ticket – it confirms you’re allowed to be at the gate in the first place. DKIM is your passport – it proves your identity hasn’t been faked or tampered with. And DMARC is the immigration officer – the authority that looks at both documents, decides whether everything checks out, and determines what happens if it doesn’t.
None of the three works as well alone. Together, they cover each other’s blind spots.
In the sections below, we’ll break down each protocol separately – what it does, how it works, and where it falls short on its own.
What Is an SPF Record – And What Does It Actually Do?
SPF stands for Sender Policy Framework. In simple terms, it is a public list that specifies to the rest of the Internet what mail servers are allowed to send emails on your behalf.
SPF is like a guest list outside the door of a venue. If you send an email that claims to come from yourcompany.com, it is checked against this list. If it is included in the list, it is allowed in. If it is not included in the list, something is wrong.
How SPF Actually Works
Your SPF record exists in the back-end configuration of your domain’s DNS records as a simple text string, referred to as a TXT record. Any mail server in the world can look up this text string. A sample text string looks like this:
v=spf1 include:_spf.google.com include:mailchimp.com ~all
In simple English, this text string is stating the following: “Emails sent FROM this domain are allowed if they are sent FROM Google mail servers OR Mailchimp mail servers. Any other emails should be considered suspicious.”
When you send an email, the mail server looks up the Return-Path header of the email and sees your domain. They then look up the DNS email record and compare the sending server’s IP with the approved sending servers. This process happens in milliseconds and behind the scenes before the recipient opens the email.
Where SPF Falls Short
Here’s the important limitation. SPF only checks the envelope sender – the Return-Path address used between servers. It does not verify the visible “From:” address that you actually see in your inbox. As a result, an attacker can pass SPF on their own domain while still displaying your name and address to the recipient.
Additionally, SPF has a hard technical ceiling: no more than ten DNS lookups per check. Most businesses today use multiple sending tools – a CRM, a marketing platform, a helpdesk system. Each one adds lookups. Exceed the limit, and your SPF record fails entirely, which can quietly damage your email deliverability without any obvious warning.
That’s why SPF alone is not enough to stop spoofing. It’s a strong first layer – but only the first. DKIM picks up where SPF leaves off.
What Is DKIM – The Digital Signature Your Emails Need
SPF ensures that you know for a fact that a particular email originated from an authorized server. However, it will not help you verify if the email you sent has been altered in transit. That is where DKIM comes in.
DKIM is short for DomainKeys Identified Mail. DKIM is based on the principle of embedding a digital signature on all emails you send out, which proves that not only is it coming from you, but also that it has not been altered during transit.
The Key Pair: How DKIM Signatures Work
DKIM relies on two mathematically linked keys that work as a pair.
The private key is stored on your mail server. This is private information and stays on the server. Every time you send an email, this private key is used to generate a signature using the content of the message and other headers.
The public key is stored in the DNS records of your domain and is available for anyone to see. When the mail server receives your email, it retrieves the public key and uses this to verify the signature. If the signature verifies correctly, then the mail has not been tampered with.
The DKIM signature looks like a string of text in the header of the email, but it is not visible to the average reader. This signature contains the domain, the algorithm used, and the headers. You will never have to read this, but it is important to know it exists.
Where DKIM Falls Short
DKIM is a significant step up from SPF. However, it has one important limitation: it doesn’t instruct the receiving server on what to do when verification fails. A failed DKIM check raises a flag – but without further instruction, many servers deliver the message anyway. That decision gap is where impersonation attacks continue to slip through.
There’s also a meaningful upside worth knowing. When DKIM is correctly configured and paired with DMARC enforcement, it unlocks BIMI – Brand Indicators for Message Identification. In practical terms, that means your verified logo appears directly in the recipient’s inbox beside your email. It’s a visible trust signal that reinforces mail server authentication and makes spoofed messages immediately more obvious by contrast.
DKIM does the verification. But it needs a partner to act on the results. That partner is DMARC.
What Is DMARC – The Protocol That Ties It All Together
SPF checks the sending server. DKIM verifies the message. But neither one tells the receiving server what to do when something fails – and neither one checks the address your recipient actually sees. DMARC solves both problems at once.
DMARC stands for Domain-based Message Authentication, Reporting, and Conformance. It builds directly on top of SPF and DKIM, adding two critical capabilities they lack: enforcement and visibility.
The Alignment Fix – Closing the Spoofing Loophole
Here’s the key insight that makes DMARC genuinely powerful. For an email to pass DMARC, it’s not enough for SPF or DKIM to pass on their own. The authenticated domain must also align with the visible “From:” address – the one your recipient actually reads.
This alignment requirement is what closes the spoofing loophole. Without it, an attacker could pass SPF using their own domain while displaying your address in the From field. DMARC sees through that. If the authenticated domain and the visible sender don’t match, DMARC fails the message – regardless of what SPF or DKIM say individually.
Three DMARC Policy Options, Explained Simply
When you publish a DMARC record in your DNS, you choose one of three policy levels that tell receiving servers exactly how to handle messages that fail authentication.
p=none is monitoring mode. Failing emails are still delivered, but you receive reports about what’s happening. It’s the right starting point – but it offers zero protection on its own.
p=quarantine tells receiving servers to send failing messages to the spam folder. Your domain is partially protected, and legitimate senders have time to fix authentication issues before you go further.
p=reject is full enforcement. Emails that fail DMARC alignment are blocked entirely – they never reach the recipient’s inbox. This is the goal, and it’s the policy level that delivers genuine email phishing prevention for your domain.
DMARC Reporting – Visibility You Can’t Get Elsewhere
One underappreciated feature of DMARC is its reporting mechanism. When active, receiving servers send aggregate reports back to your domain showing exactly who is sending email on your behalf, which messages passed or failed, and where unauthorized sending attempts originated.
These reports are invaluable for brand protection. They give you a live map of your domain’s email activity – including senders you didn’t know existed. In a zero trust email environment, that visibility isn’t optional.
Why Most Domains Stall at p=none
Unfortunately, the majority of domains that publish a DMARC record never move past monitoring mode. According to research from Valimail, between 75% and 80% of domains with DMARC records fail to reach enforcement. The most common reason isn’t technical – it’s inertia. Teams set up p=none, forget to review the reports, and stay vulnerable for months or years.
This matters more now than ever. Since 2024, Gmail, Yahoo, and Apple have required SPF, DKIM, and DMARC for bulk email senders. Microsoft followed in 2025. Without a functioning DMARC record – and a path toward enforcement – your emails increasingly risk being filtered or rejected outright, regardless of how legitimate they are.
DMARC is, in short, where email authentication stops being passive and starts having consequences.
SPF vs. DKIM vs. DMARC: What Each One Actually Checks
At this point, it helps to see all three protocols side by side. Each one checks something different – and that’s precisely why you need all three.
| Protocol | What it checks | What it can’t do alone |
| SPF | Where – confirms the sending server is authorized to send for your domain | Doesn’t verify the visible “From:” address; can’t detect message tampering |
| DKIM | What – verifies the message content and headers haven’t been altered in transit | Doesn’t check the visible “From:” address; gives no instruction if verification fails |
| DMARC | Who + what to do – checks that SPF or DKIM aligns with the visible “From:” address, then enforces a policy | Requires SPF and/or DKIM to function; can’t verify anything on its own |
The pattern is clear. SPF and DKIM each catch part of the problem. Neither one checks the address your recipient actually reads. And neither one tells a receiving server what action to take when something goes wrong. DMARC closes both gaps – but only because SPF and DKIM gave it something to work with first.
Think of it this way: SPF answers where did this come from? DKIM answers was this message tampered with? DMARC answers: does the sender match who they claim to be – and what should we do if it doesn’t?
How SPF, DKIM, and DMARC Work Together to Stop Email Spoofing
Understanding each protocol separately is useful. Seeing how they operate as a system is where it clicks.
Think of it as three security checkpoints at an international airport. Each one checks something different. Each one can be bypassed alone. But together, they make it extraordinarily difficult to get through as an impostor.
The Authentication Journey of a Single Email
Here’s what happens the moment you hit send – invisibly, in milliseconds.
Checkpoint one: SPF. The receiving server looks at the envelope sender address and checks your domain’s SPF record. Is this sending server on the approved list? If yes, SPF passes. If not, it fails – and a flag goes up.
Checkpoint two: DKIM. The receiving server finds your public DKIM key in DNS and uses it to verify the message signature. Has the email been altered since leaving your server? If the signature holds, DKIM passes. If anything changed in transit, it fails.
Checkpoint three: DMARC. This is where alignment happens. The receiving server checks whether the domain that passed SPF or DKIM actually matches the visible “From:” address. Then it applies your published policy – deliver, quarantine, or reject.
Why All Three Must Work Together
Consider a concrete example. An attacker sends an email appearing to come from [email protected]. They route it through their own server, so SPF passes for their domain. They even sign it with their own DKIM key, so DKIM passes too. Without DMARC, that email could reach your client’s inbox looking completely legitimate.
DMARC catches it. Because even though SPF and DKIM passed, neither authenticated domain aligns with the visible yourcompany.com in the From field. DMARC fails the message and – if your policy is set to p=reject – blocks it entirely.
That’s how you protect your domain from spoofing in practice. Not with one layer, but with three working in sequence. Inbox spoofing exploits gaps between systems. These protocols, combined, leave no gap to exploit.
Without DMARC, passing SPF and DKIM is a little like having a passport and boarding pass but no immigration officer checking they belong to the same person. The credentials exist – but nobody’s verifying they match.
How to Check If Your Domain Is Protected Right Now
Knowing how these protocols work is one thing. Knowing whether they’re actually protecting your domain right now is another. Fortunately, you can find out in a few minutes – no technical expertise required.
Step One: Read Your Own Email Headers
Every email you receive carries a hidden authentication report in its headers. Here’s how to find it in the most common inboxes.
Gmail: Open any email, click the three dots in the top right corner, and select Show original. A new window opens with the full raw message.
Outlook: Open the email, click File, then Properties. Look for the Internet headers box.
Apple Mail: With the email open, go to View → Message → All Headers.
In all three cases, look for a line that reads Authentication-Results. A healthy result looks like this:
spf=pass · dkim=pass · dmarc=pass
If any of those reads fail or none, your domain has a gap worth investigating.
Step Two: Use a Free Online Tool
For a broader view of your domain’s DNS email records, free tools like MXToolbox and mail-tester let you enter your domain name and instantly see whether your SPF record exists, whether DKIM is published, and what your current DMARC policy is set to. Neither requires an account to run a basic check.
Step Three: The Quick Three-Point Self-Check
Even without tools, these three questions tell you where you stand.
- Does your SPF record exist? If you’ve never set one up, the answer is almost certainly no.
- Is DKIM published for every service that sends on your behalf? Most businesses miss at least one – a CRM, a helpdesk tool, a newsletter platform.
- Is your DMARC policy above p=none? If it’s stuck at monitoring mode, your domain is visible but still unprotected.
If any answer concerns you, a conversation with your domain administrator or hosting provider is the right next step.
5 Common Email Authentication Mistakes (And How to Avoid Them)
Setting up SPF, DKIM, and DMARC is only half the job. The other half is avoiding the configuration errors that quietly undermine everything you’ve put in place. These five mistakes show up repeatedly – across businesses of every size.
1. Leaving DMARC permanently at p=none
Publishing a DMARC record at p=none feels like progress. In reality, it’s a starting point – not a destination. Monitoring mode collects data but blocks nothing. An attacker can still send spoofed emails from your domain, and every one of them will reach its target. Moving toward p=quarantine or p=reject is the only path to real protection. Set a deadline to review your reports and advance your policy.
2. Exceeding the SPF 10-lookup limit
Every time you add a new sending tool – a CRM, a marketing platform, a support helpdesk – your SPF record grows. SPF has a hard limit of ten DNS lookups per authentication check. Exceed it, and your entire SPF record becomes invalid. The result is silent email deliverability damage that’s frustratingly difficult to diagnose. Audit your SPF record whenever you add a new sending service.
3. Forgetting DKIM for third-party senders
Your main domain may have DKIM configured correctly. However, every platform that sends email on your behalf needs its own DKIM record published in DNS. Mailchimp, Salesforce, Zendesk, and similar tools all support custom DKIM signing – but it rarely happens automatically. Check each sender individually rather than assuming the setup carries over.
4. Jumping straight to p=reject without reviewing reports
DMARC enforcement is the goal, but rushing there causes its own problems. Setting p=reject before you’ve identified all legitimate senders can block your own emails – newsletters, transactional messages, automated notifications – before you’ve had a chance to authenticate them properly. Start at p=none, review your aggregate reports for at least two to four weeks, then advance gradually.
5. Ignoring DMARC aggregate reports entirely
This is arguably the costliest mistake of all. DMARC reports are not administrative noise – they’re a detailed map of everything sending email under your domain, including sources you never authorized. Inside those reports lives the intelligence you need to reach full enforcement confidently. Treating them as background data means staying blind to both misconfiguration and active impersonation attempts.
Why These Protocols Matter Even If You’re Not a Tech Person
It’s easy to assume SPF, DKIM, and DMARC are problems for IT departments to solve and forget about. In reality, these email security protocols affect everyone who sends or receives email – which is essentially everyone.
If You’re a Recipient
Every time a spoofed email lands in your inbox, it’s partly because the sender’s domain lacked proper authentication. Conversely, every time a fake message gets quietly blocked before you ever see it, these protocols are the reason why. You benefit from them without knowing it – and you’re exposed when they’re missing.
If You’re a Sender
For freelancers, small business owners, and anyone who emails clients professionally, an unprotected domain creates two real risks. First, your legitimate emails look suspicious to receiving servers – and increasingly land in spam. Second, your domain becomes an easy target for impersonation. Someone can send fake invoices, fraudulent requests, or phishing messages that appear to come from you, with no way for your clients to know the difference.
Email spoofing explained simply comes down to this: the easier your domain is to fake, the more trust you stand to lose.
Why Your Email Provider’s Choices Matter Too
Authentication doesn’t happen in a vacuum. It depends partly on infrastructure decisions made by your email provider – how they handle signing, encryption, and sender verification behind the scenes.
This is one reason privacy-focused providers like Atomic Mail have gained attention. Beyond offering end-to-end encryption and zero-access architecture, services built around genuine email privacy tend to treat authentication as a baseline – not an afterthought.
The Bottom Line on Email Authentication
SPF confirms who’s allowed to send on your behalf. DKIM proves your message wasn’t tampered with. DMARC ties both together, checks alignment with the visible sender address, and enforces a policy when something fails. Each one covers what the others can’t. None of them is optional.
Together, they’re the most effective tool available to prevent email spoofing – and increasingly, they’re the baseline expectation from every major inbox provider on the planet.
Authentication protects your identity at the sending end. Encryption protects your content at every step. Both matter. Neither replaces the other.
Leave a Reply