Email Authentication: SPF, DKIM, and DMARC Guide

Email authentication proves that your sending system has permission to send mail for your domain. If you send marketing, transactional, lifecycle, or sales email, you need SPF, DKIM, and DMARC set up correctly before mailbox providers will trust you.

What email authentication means

Email authentication is the technical proof that a sender is allowed to send email for a domain.

Mailbox providers like Gmail, Yahoo, Outlook, and corporate gateways use that proof to answer a basic question:

Did this message really come from the domain it claims to represent?

Without authentication, anyone could send a message that appears to come from your company. That is how phishing, spoofing, and brand impersonation work.

Authentication relies on DNS records. You publish records for your domain. Receiving mail servers check those records when they receive a message. If the message matches the rules you published, it passes. If not, it can fail authentication or fall into a risky bucket.

Email authentication is not the same as email verification.

Concept	What it checks	Example question
Email authentication	Whether your sending service can send for your domain	“Is this ESP allowed to send as example.com?”
Email verification	Whether an address is valid and likely deliverable	“Does jane@example.com exist?”
Content filtering	Whether the message looks wanted or spammy	“Does this email look like spam or abuse?”

You need all three areas under control.

Authentication helps providers trust the source. Verification helps you avoid sending to bad addresses. Content and engagement help providers decide where the message should land.

Authentication is now table stakes for outbound email deliverability. It also appears directly in bulk sender requirements from major mailbox providers. If you send meaningful volume, you should assume SPF, DKIM, and DMARC are required.

How SPF works

SPF checks whether the server sending the message is authorized to send mail for the domain.

SPF stands for Sender Policy Framework. It is a DNS TXT record on your domain. The record lists the systems that can send mail on your behalf.

A simple SPF record might look like this:

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

That record says:

• This is an SPF record.
• SendGrid can send for this domain.
• Google Workspace can send for this domain.
• Other senders should fail.

During delivery, the receiving server checks the sending IP address against your SPF record. If the IP is included, SPF passes. If not, SPF fails.

How SPF records authorize sending services

Most senders do not list raw IP addresses anymore. You usually include your provider’s SPF mechanism.

Common examples:

include:_spf.google.com
include:mailgun.org
include:sendgrid.net
include:spf.protection.outlook.com

Your email service provider will give you the exact value.

Add every legitimate sender. That includes:

• Marketing platforms
• Transactional email providers
• CRM or sales engagement tools
• Help desk software
• Billing systems
• Product notification systems
• Internal email platforms

If a tool sends mail using your domain, it needs to be represented in SPF or covered by DKIM and DMARC alignment.

Common SPF mistakes

SPF breaks more often than teams expect.

The most common issues are:

1. Too many DNS lookups
   SPF has a DNS lookup limit. Includes, redirects, a, mx, and similar mechanisms can count toward it. If you exceed the limit, SPF can return a permanent error.

2. Multiple SPF records
   A domain should have one SPF TXT record. Two separate SPF records can cause evaluation errors. Merge them into one.

3. Missing sending tools
   Teams often add the main ESP and forget the CRM, support platform, or billing tool.

4. Using +all or weak endings
   +all allows everyone. That defeats the purpose. Most domains should use ~all while testing and move toward -all when confident.

5. Authenticating the wrong domain
   Your visible From domain, envelope sender domain, and return-path domain can differ. SPF alone may pass for one domain while DMARC still fails alignment.

How DKIM works

DKIM signs each message with a cryptographic signature that receiving servers can verify in DNS.

DKIM stands for DomainKeys Identified Mail. It works differently from SPF. Instead of checking only the sending IP, DKIM attaches a signature to the message headers.

The sending provider creates the signature using a private key. You publish the matching public key in DNS. When the message arrives, the receiving server checks whether the signature is valid.

If the signed parts of the message changed in transit, DKIM fails.

A DKIM DNS record usually lives at a selector-specific hostname, such as:

selector1._domainkey.example.com. TXT "v=DKIM1; k=rsa; p=PUBLIC_KEY_HERE"

The selector tells the receiver which DNS record to query.

Why DKIM survives forwarding better than SPF

DKIM often survives forwarding better than SPF because it travels with the message.

SPF checks the server that hands the message to the receiver. When a message is forwarded, the forwarding server may become the sending server. That can cause SPF to fail, even though the original sender was legitimate.

DKIM does not depend on the forwarding server’s IP address. If the message headers and body were not modified in a way that breaks the signature, DKIM can still pass.

This is one reason DMARC allows either SPF alignment or DKIM alignment to pass. You do not need both to align for DMARC to pass, but you should configure both.

Common DKIM setup and rotation issues

DKIM problems usually come from DNS or provider changes.

Watch for these issues:

• Missing DKIM records after adding a new ESP.
• Old selectors left behind after migrating providers.
• Incorrect CNAME or TXT values copied from the provider dashboard.
• Keys that are too short for modern expectations.
• No rotation process for old or compromised keys.
• Messages modified after signing, especially by security gateways, footers, or link rewriting systems.

Use provider-specific instructions. DKIM setup varies. Some providers ask you to publish TXT records. Others ask for CNAME records that point to their managed keys.

After setup, send test messages and inspect authentication results in the message headers. Look for dkim=pass.

How DMARC works

DMARC uses SPF and DKIM alignment to decide whether a message should be trusted as coming from your domain.

DMARC stands for Domain-based Message Authentication, Reporting, and Conformance. It sits on top of SPF and DKIM.

DMARC checks two things:

1. Did SPF or DKIM pass?
2. Did the passing result align with the visible From domain?

The visible From domain is the domain users see in their inbox. DMARC cares about that domain because attackers often spoof it.

A basic DMARC record looks like this:

_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"

DMARC policies: none, quarantine, reject

DMARC gives you three main policy options.

Policy	What it means	Best use
none	Monitor only. Do not request enforcement.	Starting point and discovery
quarantine	Ask receivers to treat failures suspiciously, often spam placement.	Intermediate enforcement
reject	Ask receivers to reject failing mail.	Strong protection against spoofing

Start with p=none if you do not yet know every legitimate sending source. Review reports. Fix broken senders. Then move toward enforcement.

Do not jump straight to reject on a complex domain unless you have audited all senders. You may block real mail from your own systems.

Why DMARC reporting matters

DMARC reports show who is sending mail using your domain.

Aggregate reports can reveal:

• Legitimate tools you forgot to authenticate
• Old systems still sending mail
• Shadow IT platforms
• Spoofing attempts
• Forwarding patterns
• Broken SPF or DKIM alignment

This is where many dmarc updates should start. Do not change policy in isolation. Use reporting to understand your mail flow first.

DMARC reports are XML and not pleasant to read raw. Many teams use a DMARC reporting tool to parse them. Even if you do not, route reports to a mailbox or processor you control.

SPF, DKIM, and DMARC together

SPF, DKIM, and DMARC work together because they check different parts of sender identity.

You will often see this written as spf dkim dmarc. Treat them as a set, not as interchangeable records.

SPF answers:

• Is this sending server authorized?

DKIM answers:

• Was this message signed by a trusted domain?
• Did the signed content stay intact?

DMARC answers:

• Did SPF or DKIM pass for a domain aligned with the visible From domain?
• What should receivers do if alignment fails?

What alignment means in practical terms

Alignment means the authenticated domain matches, or is closely related to, the domain in the visible From address.

Example:

From: marketing@example.com
Return-Path: bounce@mail.example.com
DKIM domain: example.com

This can pass DMARC if SPF or DKIM aligns with example.com, depending on your configuration.

Now compare:

From: marketing@example.com
Return-Path: bounce.random-esp-domain.com
DKIM domain: random-esp-domain.com

SPF and DKIM might pass for the ESP’s domain. But DMARC can still fail because the authenticated domains do not align with example.com.

That is the mistake that surprises many teams. “SPF passed” does not always mean “DMARC passed.”

Minimum setup most legitimate senders should have

Most legitimate senders should have:

• SPF record that includes all approved sending platforms.
• DKIM enabled for every platform that supports it.
• DMARC record at least at p=none with reporting enabled.
• Aligned DKIM for marketing and transactional providers.
• A path to move DMARC from monitoring to enforcement.
• Separate subdomain strategy for different mail streams where needed.

For example:

• news.example.com for marketing campaigns.
• app.example.com for transactional mail.
• sales.example.com for outbound sales.
• example.com for corporate mail.

You do not always need this exact split. But you do need a clear domain strategy.

Authentication mistakes that hurt deliverability

Authentication mistakes hurt deliverability when they create inconsistent identity or make providers distrust your sending patterns.

The most common problem is sending from unauthenticated tools.

A marketer connects a new platform. A sales team starts outreach from a sequencing tool. A product team launches notification email from a new provider. Nobody updates DNS. Now some mail passes and some fails.

Mailbox providers notice inconsistent authentication. That can weaken trust, especially when volume rises.

Mixing mail streams without a domain strategy

Marketing, transactional, and cold outreach behave differently.

Transactional mail usually has high engagement. Password resets and receipts get opened.

Marketing mail varies. Some subscribers engage. Others ignore it.

Cold outreach carries more complaint and block risk.

If all three streams share the same domain and infrastructure, one bad stream can affect the others. This can hurt sender reputation and reduce outbound email deliverability.

Use subdomains when the risk profiles differ. Authenticate each one. Monitor them separately.

Authentication does not guarantee inbox placement

Authentication gets you through the identity check. It does not force inbox placement.

Providers still evaluate:

• Bounce rate
• Complaint rate
• Spam trap hits
• Engagement
• Sending volume changes
• Content patterns
• Link reputation
• Domain and IP history
• User-level filtering

This matters more as inbox placement updates and provider rules evolve. Authentication is necessary. It is not sufficient.

Email authentication and list quality

Authenticated mail can still bounce or land in spam when list quality is poor.

Authentication proves who you are. It does not prove that the recipient exists, wants your email, or trusts your domain.

Poor list quality creates signals that mailbox providers dislike:

• Hard bounces from invalid addresses
• Disposable or throwaway addresses
• Role accounts with low engagement
• Old addresses that no longer belong to the original user
• Spam traps from scraped or purchased lists
• Typos like gmial.com or hotnail.com
• Catch-all domains that accept mail but may not engage

These signals can damage sender reputation. They also make authentication work less useful. You proved your identity, then sent to addresses that made providers distrust that identity.

How verification supports authentication

Email deliverability validation should include both domain authentication and list hygiene.

Before you send, verify that addresses are likely deliverable. Remove invalid and undeliverable contacts. Segment risky addresses. Watch catch-all domains. Block disposable addresses on signup forms when they do not fit your use case.

This is where an email verification API helps. Bounceable can check addresses in real time, flag disposable domains, identify catch-all risk, suggest typo fixes, and return a deliverability verdict before you send.

Use verification at two points:

1. At collection
   Validate addresses on signup, checkout, lead forms, and account creation.

2. Before campaigns
   Clean older lists before sending, especially after long inactivity or provider migration.

Authentication protects your domain identity. Verification protects your sender reputation from bad recipients. You need both.

Email authentication checklist

Use this checklist before you send from a new domain, subdomain, or provider.

DNS records to confirm before sending

Check these records:

• SPF

  • One SPF TXT record per sending domain.
  • Includes every approved sending platform.
  • Stays within DNS lookup limits.
  • Uses a reasonable ending such as ~all or -all.

• DKIM

  • Enabled for every ESP and sending platform.
  • DNS records published exactly as provided.
  • Test messages show dkim=pass.
  • Selectors are documented.
  • Old keys are removed or rotated when no longer needed.

• DMARC

  • Record exists at _dmarc.yourdomain.com.
  • Policy starts with none if you are still auditing.
  • Aggregate reporting is enabled.
  • SPF or DKIM aligns with the visible From domain.
  • You have a plan to move toward quarantine or reject.

Monitoring steps after changing sending providers

After you add or migrate a provider:

1. Send test messages to major mailbox providers.
2. Inspect message headers for SPF, DKIM, and DMARC results.
3. Confirm visible From, return-path, and DKIM domains.
4. Watch DMARC aggregate reports.
5. Monitor bounces and complaints.
6. Ramp volume gradually when possible.
7. Check whether engagement changes by mailbox provider.
8. Review inbox placement updates from your ESP and postmaster tools.

Do not assume a provider migration is complete when DNS validates in the dashboard. Dashboard checks confirm record presence. Real messages confirm actual alignment.

When to pair authentication fixes with verification

Combine authentication fixes with list verification when:

• You are sending to an old or inactive list.
• You imported leads from multiple systems.
• You changed ESPs or sending domains.
• You plan a high-volume campaign.
• You collect emails through public forms.
• You see rising bounce rates.
• You are preparing for stricter bulk sender requirements.

Authentication tells providers, “This mail is really from us.”

List hygiene helps the next signal say, “And we send to people who can receive it.”

That combination is what protects deliverability over time.