What are SPF, DKIM, and DMARC? How email authentication works

SPF, DKIM, and DMARC are the three core protocols behind email authentication, helping email providers verify who can send from your domain, whether a message has been tampered with, and how to handle suspicious mail.

When these protocols work together, they turn separate technical checks into a practical system for protecting domain reputation and helping legitimate messages reach the inbox.

The key is understanding each role, where they overlap, and how to deploy them without creating problems with forwarding, alignment, or third-party sending services.

What is SPF?

Sender Policy Framework (SPF) is the protocol that lets your domain declare which mail servers are allowed to send email on its behalf.

It works through a DNS TXT record. When you send an email, the receiving server checks the sender’s IP address against your SPF record to see if that server is authorized.

Here’s a simple example:

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

This tells receiving servers: “Emails from Google’s servers are allowed. Everything else should fail.”

A simple way to think about SPF is a guest list at a club entrance.

You hand the club bouncer a list of approved people. When someone shows up, the security guard checks: Are you on the list?

• If yes → they’re allowed in
• If no → they’re turned away

SPF works the same way. The “guest list” is your SPF record, and the “person at the door” is the sending server’s IP address.

SPF focuses only on source authorization. It answers one question: Is this server allowed to send for this domain? It does not check the message itself, so it cannot tell if the content was changed.

This still makes it useful for email spoofing prevention. If an attacker tries to send an email from your domain using their own server, SPF can flag that message as unauthorized.

There are two important limits to understand.

SPF can fail when you forward your emails. For example, if someone forwards your email from Gmail to another inbox, the receiving server sees Gmail’s server (not yours), and that server is not in your SPF record.

In practice, this looks like a message coming through the wrong office; your name is on it, but it didn’t come from your building, so it raises suspicion.

SPF also does not protect the address people see in the “From” field. An attacker can send an email from their own server but put your domain in the “From” address, so the message still looks like it came from you.

Think of it as someone sending a letter from their own house, but writing your name on it.

SPF works best as a foundation. DKIM verifies the message itself, and DMARC uses both to enforce rules at the domain level.

What is DKIM?

DomainKeys Identified Mail (DKIM) is the protocol that adds a digital signature to your emails so receiving servers can verify the message was sent by your domain and was not changed in transit.

It works using a pair of keys: a private key and a public key. Your mail server uses the private key to sign each outgoing message. The receiving server then looks up the public key in your DNS to verify that signature.

A helpful way to think about DKIM is a tamper-proof seal on a package.

You send a package with a seal that only you can create. When it arrives, the recipient checks the seal:

• If it’s intact → the package is original
• If it’s broken → something was changed

DKIM focuses on message integrity and domain-level authenticity. It answers a question: Was this message really authorized by this domain, and did it stay unchanged?

DKIM records are stored in DNS and use a selector. A selector is just a label that points to a specific DKIM key in your DNS.

For example:

selector1._domainkey.example.com

This allows you to use multiple keys at the same time, for example, when rotating keys or using different email services.

This works because each selector points to a different public key record. You can create multiple selectors (like selector1, selector2, google, mail, etc.), and each one can store a different key.

DKIM complements SPF by protecting the message itself rather than the sending path. Even if the email is forwarded and the sending server changes, the DKIM signature can still pass as long as the message content stays intact.

What is DMARC?

Domain-based Message Authentication, Reporting, and Conformance (DMARC) is the protocol that tells receiving servers what to do when an email fails authentication and provides reports on those failures.

It builds on SPF and DKIM, but adds two key pieces: alignment and policy.

Alignment means the domain that passed SPF or DKIM must match the domain people see in the “From” address.

In simple terms, the technical sender and the visible sender must be the same. If they don’t match, DMARC fails, even if SPF or DKIM passed on their own. This is what prevents domain spoofing, where an attacker makes an email look like it came from your domain.

You can think of this as a final identity check. It’s not enough that a message was sent from an approved server or signed correctly; it also has to match the identity shown to the user.

DMARC also lets you set a policy that tells receiving servers how to handle failed messages.

There are three levels:

• none → do nothing, just monitor
• quarantine → send the message to spam
• reject → block the message completely

For example, a simple DMARC record might say:

v=DMARC1; p=quarantine; rua=mailto:reports@example.com

This tells receiving servers to send failing messages to spam and send reports back to you.

Those reports are a big part of DMARC’s value.

They show:

• Which services are sending emails for your domain
• Which messages pass or fail authentication
• Where things are misconfigured

This helps you spot unknown senders, fix setup issues, and understand how your domain is actually being used.

DMARC focuses on control and visibility. It uses SPF and DKIM results to decide what should happen next.

SPF vs DKIM vs DMARC

SPF, DKIM, and DMARC each solve a different part of email authentication: who sent the email, whether it was changed, and what to do if something is wrong.

Feature	SPF	DKIM	DMARC
Core role	Verifies sending server	Verifies message integrity	Enforces policy and reporting
What it checks	Sender IP address	Digital signature on the message	SPF/DKIM results + domain alignment
Main question it answers	Is this server allowed to send?	Was this message changed?	Should this message be trusted?
Protects against	Unauthorized senders	Message tampering	Domain spoofing

Another simple way to look at it:

• SPF checks where the email came from
• DKIM checks that the message wasn’t changed
• DMARC checks that everything lines up and decides what happens next

Each protocol fills a gap that the others don’t cover. Used together, they turn basic checks into a complete system that can block spoofed emails and give you visibility into what’s happening with your domain.

Why SPF, DKIM, and DMARC matter

SPF, DKIM, and DMARC matter because they protect your domain from abuse and help your emails reach the inbox.

The most immediate benefit is spoofing and phishing protection. SPF blocks unauthorized senders, DKIM protects the message, and DMARC stops attackers from using your domain in the “From” address. Together, they make it much harder to impersonate your business.

They also improve your sender reputation. Mail providers track how your domain behaves over time. When your emails consistently pass authentication, your domain is seen as trustworthy.

That trust directly affects email deliverability. Authenticated emails are more likely to land in the inbox instead of spam, especially with providers like Gmail and Outlook that rely heavily on these checks.

Another key benefit is visibility. DMARC reports show who is sending email on your behalf, including services you may have forgotten about or never approved. This gives you a clear picture of your email ecosystem.

These protocols protect both sides:

• Your organization – by preventing domain abuse and protecting reputation
• Your recipients – by reducing the chance they receive fake or harmful emails

How SPF, DKIM, and DMARC work together

SPF, DKIM, and DMARC work together by checking who sent the email, whether the message was altered, and whether the authenticated domain matches the sender shown to the recipient.

Here’s how that process works from start to finish:

1. You publish your DNS records – Your domain has SPF, DKIM, and DMARC records in place. These tell receiving servers which senders are allowed, how to verify signatures, and what policy to apply.
2. Your server sends an email with a DKIM signature – Before the email is sent, your mail server signs it using DKIM so the message can be verified later.
3. The receiving server checks SPF – It looks at the sending server’s IP and compares it to your SPF record to see if the source is authorized.
4. The receiving server verifies DKIM – It retrieves your public key using the selector and checks that the message hasn’t been changed.
5. DMARC checks alignment and applies policy – It looks at the SPF and DKIM results and checks if they align with the “From” domain. If something fails, the DMARC policy decides what happens next.
6. The receiving server applies the result and sends reports – The message is delivered, sent to spam, or rejected. At the same time, DMARC reports are generated so you can see what passed, what failed, and who is sending email on your behalf.

Common problems and limitations of SPF, DKIM, and DMARC

SPF, DKIM, and DMARC can fail when setup is incomplete, or systems do not work well together.

The most common issue with SPF is that records can become too complex.

Each email service you use, such as Google Workspace, Mailchimp, your CRM, or your support tool, adds extra checks to your SPF record. These are often added using include statements, which tell receiving servers to look up additional records.

For example:

v=spf1 include:_spf.google.com include:mailchimp.com include:another-service.com -all

Each “include” adds another check. SPF allows only 10 of these checks. If your record needs more, the check fails.

You can think of this as a limit on how many stops the server is willing to make. Once that limit is reached, it stops checking and treats the message as failed.

This creates a problem. Even if all your services are legitimate, the receiving server will still treat the message as a failed SPF check.

As a result, your emails can end up in spam, fail DMARC, or be rejected entirely.

Forwarding is another known problem. As explained earlier, SPF checks the sending server, so forwarded emails often fail because the forwarding service is not in your SPF record.

DKIM has a different weakness. It can break if the message is modified after it is sent. Even small changes, like adding a footer or rewriting links, can invalidate the signature.

DMARC failures usually come down to alignment. If the domain that passed SPF or DKIM does not match the “From” domain, DMARC fails. This often happens when different services use slightly different domain configurations.

Another common issue is missing senders. Many businesses use multiple tools, such as CRMs, marketing platforms, and support systems, and each one needs to be properly included and configured. If one is missed, its emails may fail authentication.

The key point is that having SPF, DKIM, and DMARC records published does not mean your email authentication is working correctly. It only works when every service that sends email for you is properly set up and sends emails using your domain.

How to improve email deliverability with SPF, DKIM, and DMARC

You improve email deliverability by correctly setting up SPF, DKIM, and DMARC, and ensuring all your email sources pass these checks consistently.

Start with the basics. Make sure SPF includes every service that sends email for you, DKIM is enabled and signing your messages, and DMARC is set with a policy that matches your setup.

Next, check consistency. All your tools should send emails using your domain in a way that passes authentication and alignment. If one service is misconfigured, it can affect your overall reputation.

Then monitor what’s happening. DMARC reports show which emails pass or fail and help you spot issues early. It’s also a good idea to back up your emails regularly, especially if you rely on email for business communication, so you don’t lose important messages during migrations, account issues, or service failures.

Finally, move gradually. Start with a DMARC policy set to none, review your reports, then move to quarantine or reject once you are confident everything is working.

In practice, this is easier when your email setup is managed in one place.

Email hosting services like Hostinger Business Email help you handle the basics without digging through multiple tools.

For example, you can:

• Manage your domain email and authentication setup together
• Use email forwarding without losing control over your inbox
• Create aliases for different use cases without adding new mailboxes
• Access your email from tools like Gmail or Outlook while keeping your domain as the sender

All of the tutorial content on this website is subject to Hostinger's rigorous editorial standards and values.