# Email Authentication Explained: SPF, DKIM & DMARC

Email authentication explained: how SPF, DKIM, and DMARC work together to stop spoofing, protect your domain, and get your emails into the inbox.

Email authentication is how receiving mail servers decide whether a message that claims to be from your domain is genuine. It is built on three DNS-based standards—SPF, DKIM, and DMARC—that work as a system to stop spoofing and get your legitimate email into the inbox.

This guide is the hub for all three. We will cover why authentication matters, what each protocol does, and most importantly how they fit together—then link you to the in-depth guide and free checker for each one.

## Why Email Authentication Matters

Without authentication, anyone can put your domain in the From address of an email. Receiving servers have no reliable way to tell a real message from a forgery, so they either let spoofed mail through— damaging your brand and your customers—or treat everything from your domain with suspicion. Authentication solves both problems at once.

### Protects Against Spoofing

Attackers routinely impersonate trusted domains to launch phishing and business email compromise attacks. Authentication lets receivers reject mail that is not genuinely from you, protecting your recipients and your reputation.

### Improves Deliverability

Mailbox providers weigh authentication heavily when deciding between the inbox and the spam folder. Properly authenticated mail is more trusted, which means better inbox placement and fewer messages lost to filtering.

### Required by Major Providers

Since February 2024, Google and Yahoo require SPF, DKIM, and a DMARC policy for anyone sending more than 5,000 messages a day to their users. Authentication has moved from best practice to baseline requirement.

### Gives You Visibility

DMARC reporting shows you every source sending email as your domain—including shadow IT and abuse—so you can spot problems and lock down your sending before they cost you.

#### Authentication Is the Foundation, Not the Whole House

Passing SPF, DKIM, and DMARC removes a major deliverability blocker, but it does not guarantee the inbox. Sender reputation, content quality, and engagement still matter. Authentication is the entry ticket that makes the rest of your work count.

## The Three Protocols at a Glance

Each protocol answers a different question about an incoming email. Here is how they compare:

| Protocol | What it checks | DNS record |
| --- | --- | --- |
| SPF | Which servers may send email for your domain | TXT at root domain |
| DKIM | That the message was signed and not altered | TXT at selector.\_domainkey |
| DMARC | What to do on failure, plus reporting | TXT at \_dmarc |

### SPF: Authorizing Your Senders

SPF (Sender Policy Framework) is a published list of the servers allowed to send email using your domain. You add a single TXT record to your root domain naming each authorized service, and receiving servers reject or flag mail that arrives from an IP address that is not on the list. SPF validates the sending server, but it can break when a message is forwarded, which is exactly why DKIM exists alongside it. [Read the full SPF guide](/guides/what-is-spf) or [test your record with the SPF checker](/tools/spf-checker).

### DKIM: Signing Your Messages

DKIM (DomainKeys Identified Mail) attaches a cryptographic signature to every outgoing message. Your mail server signs with a private key, and receivers fetch the matching public key from a TXT record at `selector._domainkey.yourdomain.com` to verify the signature. Because the signature covers the headers and body, DKIM proves the message was not tampered with in transit—and unlike SPF it survives most forwarding. [Read the full DKIM guide](/guides/what-is-dkim) or [verify your key with the DKIM checker](/tools/dkim-checker).

### DMARC: Setting the Policy

DMARC (Domain-based Message Authentication, Reporting, and Conformance) sits on top of SPF and DKIM. It tells receiving servers what to do when a message fails authentication—monitor (`p=none`), quarantine (`p=quarantine`), or reject (`p=reject`)—and it sends you aggregate reports about every source using your domain. DMARC also enforces alignment, ensuring the authenticated domain matches the one your recipients actually see. [Read the full DMARC guide](/guides/what-is-dmarc) or [validate your policy with the DMARC checker](/tools/dmarc-checker).

## How SPF, DKIM & DMARC Work Together

The three protocols are not alternatives—they are layers. Each one covers a weakness in the others, and DMARC is the piece that turns them into a single, enforceable system. Here is what happens when a receiving server evaluates one of your messages:

### 1\. SPF and DKIM Run First

The receiver checks whether the sending IP is authorized by your SPF record and whether the DKIM signature on the message is valid. Either check can pass or fail independently.

### 2\. DMARC Checks Alignment

DMARC requires that a passing SPF or DKIM result _aligns_ with the domain shown in the visible From header. Alignment is what stops an attacker from passing SPF on their own domain while spoofing yours in the From line. DMARC passes if at least one of SPF or DKIM passes and aligns.

### 3\. The Policy Decides the Outcome

If DMARC passes, the message is delivered normally. If it fails, the receiver applies your published policy—nothing, quarantine, or reject—so you control how forgeries are handled instead of leaving it to each provider's guesswork.

### 4\. Reports Close the Loop

Receivers send DMARC aggregate reports back to you, revealing every source sending as your domain. You use these to authorize legitimate services you forgot about and to spot abuse before tightening your policy.

In practice, all three live side by side in your DNS as TXT records at different locations:

SPF, DKIM & DMARC records for one domain

```
# SPF — published at the root domain
example.com.                 IN TXT  "v=spf1 include:spf.bitelio.com ~all"

# DKIM — published at the selector your provider gives you
bit._domainkey.example.com.  IN TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEB..."

# DMARC — published at the _dmarc subdomain
_dmarc.example.com.          IN TXT  "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"
```

#### Why You Need All Three

SPF breaks on forwarding, DKIM says nothing about how to treat failures, and DMARC cannot pass without an aligned SPF or DKIM result behind it. Deploy all three and each protocol covers the others' blind spots—giving you the overlapping protection mailbox providers now expect.

## Email Authentication Setup Checklist

Set the three protocols up in order—SPF and DKIM first, then DMARC—so DMARC has something aligned to build on.

1

### Inventory Every Sending Source

List every service that sends email as your domain: your email platform, CRM, help desk, marketing tools, and billing system. Missing one is the most common reason authentication fails later.

2

### Publish One SPF Record

Combine every authorized sender into a single SPF TXT record at your root domain, ending in `~all`. Remember the 10 DNS lookup limit—do not create more than one SPF record.

3

### Enable and Publish DKIM

Have each sending service generate a DKIM key pair, then publish the public key at the selector it provides. Enable signing on every source so no legitimate mail goes out unsigned.

4

### Start DMARC in Monitor Mode

Add a DMARC record at `_dmarc.yourdomain.com` with `p=none` and a `rua` reporting address. This gathers data without affecting delivery.

5

### Review Reports, Then Tighten

Read DMARC reports for two to four weeks, fix any legitimate source that is failing, then move your policy from `p=none` to `p=quarantine` and finally `p=reject`.

#### Bitelio Sets This Up For You

When you add a domain in Bitelio, we generate the exact SPF and DKIM records to paste into your DNS and verify them automatically—so you can focus on getting DMARC to a reject policy with confidence.

## How to Verify Your Setup

Never assume a record is live just because you saved it—DNS changes can take time to propagate and typos are easy. Verify each protocol independently:

- [SPF Checker](/tools/spf-checker): Confirm your record parses correctly and stays under the 10 DNS lookup limit.

- [DKIM Checker](/tools/dkim-checker): Verify the public key resolves for the selector your provider signs with.

- [DMARC Checker](/tools/dmarc-checker): Validate your policy syntax and reporting addresses.

As a final end-to-end test, send a message to a Gmail or Outlook account, open the original headers, and look for `spf=pass`, `dkim=pass`, and `dmarc=pass`. When all three pass and align, your domain is properly authenticated.

## Deep Dives: SPF, DKIM & DMARC

Ready to configure each protocol in detail? Start with the guide for whichever one you are setting up next.

- [What is SPF?](/guides/what-is-spf): Authorize your sending servers with a single SPF record.

- [What is DKIM?](/guides/what-is-dkim): Sign every message so receivers can verify it is unaltered.

- [What is DMARC?](/guides/what-is-dmarc): Set a policy and read reports to enforce authentication.

---

> Source: https://dev.bitelio.com/guides/email-authentication