Email authentication explained for beginners

13 June 2026 · 15 min read

Email was designed in an era when everyone on the network trusted everyone else, so it shipped with no built-in way to prove who actually sent a message. The "From" address you see in your inbox is just a label the sender typed in. Nothing in the original protocol stops anyone, anywhere, from putting your company's domain in that label and sending mail that looks exactly like it came from you. Email authentication is the set of standards that bolted proof onto this trusting old system after the fact. If you have never touched a DNS record and the words SPF, DKIM and DMARC mean nothing to you yet, this guide is written for you. By the end you will understand what each one proves, why you genuinely need all three rather than just one, and the single most useful thing to do first.

We will go slowly and avoid jargon where we can. Where a technical term is unavoidable, we will define it the first time it appears. You do not need to be a network engineer to follow along.

The problem: anyone can pretend to be you

Imagine posting a paper letter. You can write any name and return address you like on the envelope and on the letter inside. The postal service does not check whether the return address is really yours. It just delivers the letter. Email works the same way, and that is the whole problem.

When an email is sent, there are actually two "from" addresses involved, and this trips up almost everyone at the start:

• The envelope sender (also called the Return-Path or MAIL FROM): this is the behind-the-scenes address that mail servers use to route the message and to send back bounce notifications. You usually never see it in your inbox.
• The header From: this is the friendly "From: Acme Ltd <billing@acme.com>" line your email client displays. This is the address a human reads and trusts.

A scammer can set both of these to whatever they want. They can send an email where the header From says billing@yourcompany.com, your real domain, even though they have no connection to your company at all. This is called spoofing, and it is the engine behind most phishing and business email compromise fraud. A customer or an employee receives a message that genuinely appears to come from you, asking them to pay a fake invoice, reset a password, or click a malicious link.

Email authentication exists to answer one question for the receiving mail server, such as Gmail or Microsoft 365: was this message really authorised by the domain it claims to come from? SPF, DKIM and DMARC are three different, complementary ways of answering that question. They all work by publishing small records in your domain's DNS, the public address book of the internet, so that any receiving server can look up the rules you have set and check incoming mail against them.

What DNS is, in one paragraph

Before we go further, a quick word on DNS, because all three standards live there. DNS (the Domain Name System) is the internet's directory. It maps a name like yourcompany.com to the numbers and settings computers need. Most people only think of DNS as turning a domain into a website address, but DNS also holds TXT records, which are simply small pieces of text anyone can publish and anyone can read. SPF, DKIM and DMARC are all published as TXT records (with one small DKIM exception we will mention later). When a receiving mail server wants to check your mail, it reads these public TXT records to learn the rules you have set. You add these records through whoever manages your domain's DNS: your registrar, your hosting provider, or a platform that does it for you.

If you want to see what your domain currently publishes, you can run it through the free DMARC checker, SPF checker and DKIM checker. It is genuinely worth doing this now, before you read on, so the rest makes sense against your own domain.

SPF: which servers are allowed to send for you

SPF stands for Sender Policy Framework. It answers a narrow but useful question: is the server that delivered this email on the list of servers I have authorised to send mail for my domain?

You publish a single TXT record listing the sources allowed to send email using your domain. In practice these sources are your providers: Google Workspace, Microsoft 365, your newsletter tool, your invoicing software, your help desk, and so on. A very simple SPF record looks like this:

v=spf1 include:_spf.google.com include:sendgrid.net -all

Reading it left to right: v=spf1 says this is an SPF record; each include: pulls in the set of servers belonging to a named provider (here Google and SendGrid); and -all at the end means "anything not listed above is not authorised, reject it." When a receiving server gets an email claiming to be from your domain, it looks at the actual sending server's address and checks whether it falls within the sources your SPF record permits.

SPF is helpful, but it has two important limits that beginners need to know, because they explain why SPF alone is not enough:

1. SPF checks the envelope sender, not the From address your users see. Remember the two "from" addresses from earlier. SPF validates the hidden envelope sender, not the visible header From. A spoofer can pass SPF on a domain they control while still showing your domain in the visible From line. By itself, SPF does nothing about the address humans actually read. DMARC, later, is what ties SPF back to the visible address.
2. SPF breaks when email is forwarded. If someone receives your message and forwards it, the forwarding server becomes the new sending server, and it is almost certainly not in your SPF record. So the forwarded copy fails SPF even though the original was perfectly legitimate. This is normal and expected, and it is one of the main reasons you cannot rely on SPF on its own.

There is also a strict technical rule that catches many people out: an SPF record may trigger at most ten DNS lookups when it is evaluated. Every include: for a provider counts towards that limit, and large providers can consume several each. Exceed ten and your SPF record returns a state called PermError, at which point receivers may treat your mail as if SPF were not set up at all. Plenty of perfectly well-intentioned domains quietly break this way as they add more sending tools over time. If you want to understand this in depth, see SPF failing with PermError: too many DNS lookups, and to check your own count, run the SPF checker.

So SPF proves: this message came from a server I authorised. That is genuinely useful, but it says nothing about whether the message was altered in transit, and on its own it does not protect the address your recipients actually see.

DKIM: a tamper-proof signature on the message

DKIM stands for DomainKeys Identified Mail. Where SPF is about which server sent the mail, DKIM is about the message itself. It answers: was this message genuinely signed by the domain it claims to come from, and has it been changed since?

DKIM works using a pair of cryptographic keys, which sounds intimidating but the idea is simple. There are two halves:

• A private key, which your mail provider keeps secret. When you send an email, the provider uses this private key to generate a unique digital signature based on the message's contents, and it attaches that signature to the email's hidden headers.
• A public key, which you publish in your DNS as a record anyone can read. The receiving server fetches your public key and uses it to check the signature.

Here is the clever part. The maths only works one way: a signature made with your private key can only be verified by your matching public key, and the signature is calculated from the message content. So if the signature checks out, the receiver knows two things at once. First, the message really was signed by someone holding your domain's private key, which should only be your authorised provider. Second, the important parts of the message (the From address, subject and body) have not been altered since signing, because any change would make the signature fail to verify.

A DKIM public key in DNS looks roughly like this, published at a special name such as selector1._domainkey.yourcompany.com:

v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQ...

The long string after p= is the public key itself. That word selector1 is the selector, a label that lets you run more than one key at a time, which is handy when you use several providers or want to rotate keys for security.

DKIM has a big advantage over SPF: because the signature travels inside the message, DKIM usually survives forwarding. The forwarded copy still carries the original signature, and as long as the content was not modified, it still verifies. This is exactly the gap SPF leaves open.

DKIM has its own subtleties. The signature only covers the headers the provider chose to include, the private key must be kept genuinely private, and keys should be rotated periodically so an old leaked key cannot be abused forever. But the core promise is strong: DKIM proves this specific message was authorised by the domain and has not been tampered with. You can inspect any domain's DKIM setup with the DKIM checker.

Why two is still not enough: the alignment gap

At this point a fair question is: if SPF proves the server and DKIM proves the message, why do we need a third thing? Because of a gap that both share. Neither SPF nor DKIM, on its own, is required to involve the domain your recipients actually see in the From line.

Recall that SPF checks the hidden envelope sender, and DKIM signs using whatever domain the provider chose, which is not necessarily your visible domain. A spoofer can craft a message that passes SPF and even DKIM using a throwaway domain they fully control, while still displaying your brand in the visible From address. Both checks come back green, yet the recipient is still being deceived. SPF and DKIM are the locks; nothing yet forces those locks to be fitted to the right door.

This missing link is called alignment, and closing it is precisely the job of the third standard.

DMARC: tie it all together and decide what happens

DMARC stands for Domain-based Message Authentication, Reporting and Conformance. It is the layer that makes SPF and DKIM actually protect the address your recipients read. DMARC does three things, and the name spells them out: it sets a policy (Conformance), it requests Reporting, and it enforces Authentication alignment.

DMARC introduces the concept we just named: alignment. For DMARC to pass, it is not enough for SPF or DKIM to pass in isolation. The domain that SPF or DKIM validated must match the domain shown in the visible From address. Specifically:

• SPF alignment: SPF passed and the envelope sender's domain matches the visible From domain.
• DKIM alignment: the DKIM signature verified and the signing domain matches the visible From domain.

DMARC passes if at least one of SPF or DKIM passes and is aligned. This is the rule that defeats the spoofer from the previous section. Their throwaway domain might pass SPF and DKIM, but it does not match your visible From domain, so it fails alignment, and therefore fails DMARC. The locks are now fitted to the right door.

A basic DMARC record, published as a TXT record at _dmarc.yourcompany.com, looks like this:

v=DMARC1; p=none; rua=mailto:reports@yourcompany.com

Three parts matter for a beginner:

• v=DMARC1 says this is a DMARC record.
• p=none is the policy: what you are asking receivers to do with mail that fails DMARC. We will come back to this, because it is the single most important and most misunderstood setting.
• rua=mailto:... is where receiving servers send you aggregate reports: daily summaries of how much mail passed and failed across every source using your domain. These reports are how you discover what is really sending mail as you, including things you had forgotten about.

The three policy levels

The p= value can be one of three settings, and they form a journey rather than a one-off choice:

1. p=none (monitor only): receivers do nothing different. Failing mail still gets delivered. You simply collect reports. This is where everyone starts, and it is completely safe because it never blocks anything. But, and this is critical, p=none provides no protection at all. A spoofer's mail still lands. It exists only so you can observe before you act. Treating p=none as "done" is one of the most common and dangerous mistakes; we wrote about it in the false security of p=none.
2. p=quarantine: mail that fails DMARC is sent to the spam or junk folder rather than the inbox. This is partial protection and a useful intermediate step.
3. p=reject: mail that fails DMARC is refused outright and never delivered. This is full protection. A spoofed message using your domain simply does not arrive. Reaching p=reject is the actual goal of this entire exercise. Everything else is a means to get there safely.

The reason you do not jump straight to p=reject is that, until you have used the reports to find and authenticate every legitimate sender, enforcing a strict policy could block some of your own real mail. The whole craft of doing this properly is moving from p=none to p=reject without ever taking down your own legitimate email. That is a real risk done carelessly, and it is exactly what our done-for-you DMARC service exists to manage. If you would rather understand the path yourself, how to reach p=reject without breaking your email walks through it, and will enforcing DMARC break my email? addresses the fear head-on.

How the three fit together

It helps to see the standards as a sequence the receiving server runs through for every message that claims to be from your domain:

1. SPF asks: did this come from a server the domain authorised? It checks the hidden envelope sender against your published list of allowed sources.
2. DKIM asks: is there a valid cryptographic signature from the domain, proving the message was authorised and unaltered?
3. DMARC asks: did SPF or DKIM pass and line up with the visible From address, and if not, what did the domain tell me to do about it?

SPF and DKIM are the two independent ways to prove authenticity. DMARC is the supervisor that requires at least one of them to succeed in alignment with the visible sender, then applies your chosen policy and sends you a report. This is why you need all three. SPF without DMARC leaves the visible From unprotected and breaks on forwarding. DKIM without DMARC also leaves the visible From unprotected. DMARC without SPF and DKIM has nothing to evaluate. Together, they close the loop.

There are two further standards you will meet once these three are solid, and it is worth knowing they exist so the landscape makes sense:

• MTA-STS (Mail Transfer Agent Strict Transport Security) protects the connection between mail servers, forcing email to your domain to be delivered over encryption and blocking certain interception attacks. Check any domain with the MTA-STS checker.
• BIMI (Brand Indicators for Message Identification) lets your logo appear next to your messages in supporting inboxes, but only once you are at enforcement. BIMI is a reward for getting DMARC right, not a starting point. The BIMI checker shows whether a domain qualifies.

These come later. SPF, DKIM and DMARC are the foundation, and you should not worry about MTA-STS or BIMI until the foundation is in place.

What to do first

If you take one action from this guide, make it this: find out where your domain stands today, then move deliberately towards p=reject. Here is a sensible order for a complete beginner.

1. Check your current state. Run your domain through the DMARC checker, the SPF checker and the DKIM checker. You will learn whether you publish each record at all, and whether they are valid. Many domains are missing one or more entirely. For a single overview, the domain analyzer checks everything at once.
2. Publish a DMARC record at p=none with reporting on. This is the safe first step. It blocks nothing, but it switches on the daily aggregate reports that reveal every source sending mail as you. You cannot safely tighten anything until you can see what is happening, and p=none is how you start seeing. Our getting started guide covers exactly how.
3. Read the reports and authenticate every legitimate sender. The raw aggregate reports are dense XML and hard to read by hand. Paste one into the DMARC report analyzer to turn it into something human-readable, and see reading your first DMARC report for help interpreting it. Your task here is to find each genuine service that sends on your behalf, the newsletter tool, the CRM, the invoicing system, and make sure it is covered by SPF and signs with DKIM, and that both align with your domain.
4. Tighten the policy in stages. Once the reports show your real mail consistently passing in alignment, move from p=none to p=quarantine, watch again, and then to p=reject. Step by step, watching the reports at each stage, so you never block your own legitimate mail. This is the cautious path that gets you to full protection without an outage.
5. Keep watching after you reach enforcement. Authentication is not "set and forget." You will add new sending tools over time, providers change their infrastructure, and a key can expire. Continuous monitoring catches a new unauthorised or misconfigured source before it becomes a delivery problem or a security gap. Our monitoring service emails you the moment something changes.

If reading XML reports and shepherding a policy from none to reject sounds like more than you want to take on, that is a completely reasonable conclusion, and it is the exact problem we built DMARC Engine to solve. The platform takes a domain from p=none to p=reject safely, manages SPF, DKIM, MTA-STS and BIMI for you, and keeps watch afterwards, all without an email outage. Either way, whether you do it yourself or hand it over, the destination is the same: legitimate mail authenticated and aligned, spoofed mail rejected, and your domain no longer free for anyone to impersonate.

A short recap

Email shipped without a way to prove who sent a message, so anyone can put your domain in the visible From line. Three standards fix this, and you need all three:

• SPF proves the message came from a server you authorised, but it checks the hidden sender and breaks on forwarding.
• DKIM proves the message was signed by your domain and not altered, and it survives forwarding.
• DMARC ties SPF and DKIM to the address your recipients actually see (alignment), then lets you decide, via p=none, p=quarantine or p=reject, what receivers should do with mail that fails, while sending you reports so you can act safely.

Start by checking your domain with the DMARC checker, publish DMARC at p=none to switch on reporting, and work steadily towards p=reject. If a term still puzzles you, the glossary defines the lot in plain language, and the requirements page lays out what providers like Gmail and Microsoft now expect. That is email authentication, start to finish, with no prior knowledge assumed.