Email Authentication Protocols: SPF, DKIM, and DMARC

Email authentication protocols are technical standards that let receiving mail servers verify whether an email is legitimately connected to the domain shown to the recipient. In modern sending, the core protocols are SPF, DKIM, and DMARC: SPF authorizes sending infrastructure, DKIM signs message content, and DMARC checks whether either result aligns with the visible From domain.

What are email authentication protocols?

Email authentication protocols are not a single setting or a score. They are a coordinated set of DNS records, cryptographic signatures, and receiver-side checks that answer a basic question: is this message really allowed to represent this domain?

That question matters because SMTP, the protocol used to transfer email, was designed in an era when sender identity was easy to forge. A sender can technically place nearly any address in a visible From: header unless the receiving system has a way to test whether that domain authorized the message.

The three protocols that matter most for outbound email are:

• SPF (Sender Policy Framework): publishes which hosts or services may send mail using a domain in the SMTP envelope sender or HELO/EHLO identity.
• DKIM (DomainKeys Identified Mail): adds a cryptographic signature to selected message headers and the message body, allowing receivers to validate that a domain signed the message and that covered content was not changed afterward.
• DMARC (Domain-based Message Authentication, Reporting, and Conformance): uses SPF and DKIM results, checks alignment with the visible From: domain, publishes a requested policy for failures, and enables reporting.

Together, they establish a domain-level identity signal. They do not guarantee that content is useful, that a recipient opted in, or that a campaign will reach the inbox. A fully authenticated message can still be filtered for poor reputation, high complaint rates, suspicious content, or weak engagement. But unauthenticated or misaligned mail starts at a major disadvantage because recipients cannot reliably associate it with the domain it claims to represent.

Why email authentication protocols matter for deliverability

Authentication is foundational to deliverability because mailbox providers need dependable identity signals before they can build a reputation for a sender. If a domain can be spoofed freely, a provider cannot safely treat a message using that domain as trustworthy merely because the visible From: address looks familiar.

For legitimate senders, properly configured authentication has three practical benefits:

1. It makes legitimate traffic easier to identify. A receiver can validate that a message came from approved infrastructure or carries a valid domain signature.
2. It reduces impersonation risk. DMARC gives domain owners a way to instruct recipients how to handle mail that fails aligned authentication.
3. It supports consistent reputation. When transactional mail, product updates, receipts, password resets, and campaigns use stable, aligned domains, receiver systems have a clearer identity to evaluate over time.

Major mailbox providers also treat authentication as a baseline sending requirement. Google’s sender guidelines require all senders to Gmail accounts to configure SPF or DKIM, while bulk senders must use SPF, DKIM, and DMARC. Google defines a bulk sender as one that sends close to 5,000 or more messages to personal Gmail accounts in a 24-hour period, and that classification does not expire once assigned.

This is why authentication should be part of the initial domain setup, not a cleanup task after messages begin landing in spam. The longer an organization sends with fragmented domains, unaligned third-party tools, or missing signatures, the harder it can be to understand which systems are sending on its behalf and what reputation each stream has accumulated.

Authentication is necessary, not sufficient

It is tempting to treat SPF, DKIM, and DMARC as a deliverability switch. They are not. Authentication proves or supports identity; it does not create recipient consent or positive engagement.

For example, a password-reset email sent to a real user from an aligned, authenticated domain is likely to have a strong purpose and expected engagement. A promotional campaign sent to stale addresses may authenticate perfectly but still generate complaints, low engagement, and negative reputation signals. Deliverability work therefore combines authentication with list quality, complaint prevention, content discipline, predictable sending patterns, and monitoring.

SPF: authorizing your sending infrastructure

SPF is a DNS-based authorization system. A domain owner publishes an SPF policy as a DNS TXT record. When a recipient receives a message, it can look at the SMTP envelope sender domain—often called the MAIL FROM, return-path, or bounce domain—and check whether the connecting sending host is authorized by that domain’s SPF record.

An illustrative SPF record could look like this:

example.com. TXT "v=spf1 include:spf.email-service.example -all"

The components are meaningful:

• v=spf1 identifies the record as SPF version 1.
• include:spf.email-service.example asks the receiver to evaluate another domain’s SPF policy, commonly used when a sending provider publishes its own authorized infrastructure.
• -all says that hosts not matched by a previous mechanism should fail SPF.

SPF can also authorize fixed IP addresses and IP ranges. For example:

example.com. TXT "v=spf1 ip4:198.51.100.24 ip6:2001:db8:1234::/48 -all"

The values above use documentation-only example addresses. In production, use the exact values supplied by your sending platform or maintained by your mail infrastructure team.

SPF checks the envelope identity, not necessarily the visible From address

This distinction is one of the most common sources of confusion. A recipient normally sees the address in the message’s From: header, such as:

From: Acme Billing <receipts@example.com>

But an SPF check often evaluates the domain used during the SMTP transaction, such as:

MAIL FROM:<bounces@send.example.net>

If send.example.net passes SPF but the visible From: domain is example.com, SPF has passed at the protocol level. However, it may not pass DMARC alignment for example.com. DMARC makes that distinction important because it ties authentication to the domain recipients actually see.

A common and healthy setup is to use a custom bounce subdomain, such as mail.example.com, and authorize the sending provider through that subdomain’s SPF record. That lets SPF align with the organizational domain of example.com under relaxed DMARC alignment, while still separating operational mail streams.

SPF operational limits and pitfalls

SPF is simple in concept but can become fragile when too many vendors are added over time. The SPF specification limits an evaluation to 10 DNS lookups for lookup-causing mechanisms and modifiers. Nested include statements can consume that budget quickly.

A typical failure pattern looks like this:

• Marketing adds one email platform.
• Product adds a transactional provider.
• Support adds a help desk.
• Finance adds an invoicing system.
• Each tool asks for an include record.
• Some included records themselves include several more domains.

Eventually, a recipient can hit the SPF lookup limit and return a permerror rather than a clean pass. The problem is not merely that the TXT record looks long; it is the number of DNS queries needed to evaluate it.

Other SPF problems include publishing more than one SPF TXT record for a single domain, authorizing an obsolete provider, using an incorrect IP range, or changing the envelope sender without updating the matching SPF policy. A domain should publish one coherent SPF policy, even if the DNS provider displays it as multiple quoted strings for technical length handling.

DKIM: signing messages with your domain

DKIM adds a cryptographic signature to an outbound message. The sending system uses a private key to create the signature. The public key is published in DNS, allowing the receiving server to retrieve it and validate the signature.

A DKIM-signed message includes a header similar to this simplified example:

DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=s2026;
 h=from:to:subject:date; bh=...; b=...

The most important tags are:

• d=: the signing domain, such as example.com.
• s=: the selector, such as s2026.
• a=: the signing and hashing algorithm.
• h=: the headers covered by the signature.
• bh=: the hash of the signed body content.
• b=: the signature itself.

The receiver queries DNS at a name built from the selector and domain:

s2026._domainkey.example.com

An illustrative public-key record might look like this:

s2026._domainkey.example.com. TXT "v=DKIM1; k=rsa; p=BASE64_PUBLIC_KEY_MATERIAL"

The actual p= value is a long public key generated by your sending platform or mail server. Do not alter it, add spaces inside it, or reuse a key from another environment unless your provider explicitly instructs you to do so.

What a DKIM pass means

A passing DKIM result means the recipient was able to retrieve the public key, validate the signature, and confirm that the signed portions of the message were intact. It lets the signing domain take responsibility for that message.

DKIM does not, by itself, prove that the signer is the same entity as the visible From: domain. A mailing service could sign with mailer.example.net while the message displays From: updates@example.com. That can be a valid DKIM signature, but it will not satisfy DMARC for example.com unless the DKIM signing domain aligns with the visible From domain.

This is why domain alignment matters more than a dashboard that simply reports “DKIM enabled.” The question is not only whether a signature exists. The question is whether a valid signature uses a domain that DMARC can associate with the brand domain shown to the recipient.

DKIM key and signature failures

Common DKIM failure causes include:

• The selector in the outbound signature does not match a published DNS record.
• The public key record was copied incorrectly, truncated, or published at the wrong hostname.
• DNS has not propagated to the authoritative nameservers a recipient queries.
• The sender signs with an unexpected provider-owned domain rather than the intended custom domain.
• A downstream system modifies a header or body content covered by the signature.
• An old selector is removed before all active sending systems stop using it.
• A sending system has a key mismatch after key rotation.

Message changes are especially important for complex email flows. A mailing list might add a footer. A security gateway might rewrite URLs. A forwarder might add headers or modify body content. Depending on what the original signature covered and how the message changed, DKIM can fail after it leaves the original sender.

Use selectors deliberately. A selector is not a secret, and it does not need to describe a campaign. It is an operational label that helps you publish and rotate keys safely. Names such as s1, mail, prod2026, or provider-specific selectors are common. What matters is that you know which sender uses which selector and can keep an old key published until no message path relies on it.

DMARC: aligning authentication with the visible From domain

DMARC is the policy and alignment layer above SPF and DKIM. It evaluates the domain in the visible RFC 5322 From: header, then determines whether SPF or DKIM passed and whether the authenticated domain aligns with that From domain.

A basic DMARC record is published at _dmarc under the domain:

_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; adkim=r; aspf=r; pct=100"

In this example:

• v=DMARC1 identifies the record.
• p=none asks receivers to monitor failures without requesting enforcement.
• rua= provides an address for aggregate reports.
• adkim=r uses relaxed DKIM alignment.
• aspf=r uses relaxed SPF alignment.
• pct=100 applies the published policy request to all relevant messages.

DMARC passes when either of these conditions is true:

1. SPF passes and the SPF-authenticated domain aligns with the visible From domain.
2. DKIM passes and the DKIM d= domain aligns with the visible From domain.

Both do not need to align for DMARC to pass, although operating with aligned SPF and aligned DKIM creates useful resilience. SPF can break when forwarding changes the path, while DKIM can break when an intermediary changes signed content. Having both correctly configured reduces dependence on a single mechanism.

Relaxed versus strict alignment

Under relaxed alignment, related subdomains may align based on their shared organizational domain. For example, a visible From domain of example.com and a DKIM signing domain of mail.example.com can align under relaxed DKIM alignment.

Under strict alignment, the domains must match exactly. With a visible From domain of example.com, a signing domain of mail.example.com would not strictly align.

Relaxed alignment is the common starting point because it supports practical subdomain architecture. Strict alignment can be appropriate for organizations that need tighter control, but it should be deployed only after mapping every legitimate sender and testing real mail flows. Changing alignment rules without an inventory can cause legitimate traffic to fail DMARC.

DMARC policy is an enforcement request, not a magic blocklist

DMARC policies are usually introduced in stages:

1. p=none: monitor legitimate and unauthorized use of the domain through reports.
2. p=quarantine: request that failing messages receive suspicious or spam-like handling.
3. p=reject: request that receivers reject failing messages.

Receivers make their own final delivery decisions. A p=reject policy is a strong and valuable signal, but it does not force every recipient system to behave identically. Conversely, p=none does not mean DMARC is disabled; receivers can still evaluate DMARC and use the result in their filtering decisions. It simply means the domain owner is not yet asking for quarantine or rejection through its published policy.

How authentication is measured and monitored

Email authentication protocols are not themselves a rate or a campaign metric. You do not calculate “SPF” the way you calculate open rate or bounce rate. Instead, you measure the percentage and volume of messages that produce particular authentication results across sending sources and recipient domains.

Useful authentication monitoring questions include:

• What percentage of messages pass SPF?
• What percentage pass DKIM?
• What percentage pass DMARC?
• Which source IPs and third-party platforms send using the domain?
• Which visible From domains appear in mail streams?
• Which DKIM signing domains and selectors are active?
• Are failures concentrated in one service, subdomain, country, or recipient provider?
• Are unauthorized sources attempting to use the domain?

A simple DMARC pass rate calculation is:

DMARC pass rate = (messages that pass DMARC / messages evaluated for DMARC) × 100

For example, suppose aggregate reports show that 96,800 of 100,000 evaluated messages passed DMARC during a week:

(96,800 / 100,000) × 100 = 96.8%

That 96.8% figure is not automatically good or bad in isolation. The remaining 3.2% may include legitimate forwarded messages, untracked vendor mail, misconfigured applications, malicious spoofing attempts, or a mixture of all four. The purpose of monitoring is to classify those failures before strengthening a DMARC policy.

Read results by source, not only in aggregate

An overall pass rate can hide a serious operational problem. Imagine an organization sends 900,000 authenticated product emails and 100,000 recruiting emails through a separate system. If product email passes at 100% but recruiting email fails DMARC entirely, the total pass rate still appears to be 90%.

That aggregate number is not enough to fix the issue. You need source-level visibility: the IP addresses, domains, selectors, and volume associated with the failing recruiting system. The corrective action may be as small as enabling custom DKIM signing there, or as large as redesigning the domain architecture and return-path configuration.

Authentication reports should also be interpreted alongside delivery, spam complaints, deferrals, and bounce diagnostics. Authentication failures can contribute to poor placement, but an authentication pass does not explain every delivery problem.

Common causes of email authentication failures

Authentication failures are usually configuration or architecture problems, not random recipient-server behavior. The fastest path to resolution is to identify whether SPF, DKIM, DMARC alignment, or all three are failing, then map the result back to the exact sending source.

SPF failures

SPF commonly fails when the actual sending IP is not represented by the envelope domain’s SPF policy. This happens after switching providers, adding a new platform, using a custom SMTP relay, or sending from an application that bypasses the expected infrastructure.

Forwarding can also break SPF. The original message may leave an authorized sender and then be relayed through another server, whose IP address is not in the original domain’s SPF record. That does not make the original message fraudulent; it illustrates that SPF validates the sending path seen by the recipient, not a durable signature on the message.

An SPF softfail, fail, neutral, none, temperror, or permerror result calls for different troubleshooting. A temperror often indicates a transient DNS issue. A permerror can indicate a permanent record problem, including excessive DNS lookup complexity. Treat them differently rather than placing every failure into one generic “SPF broken” bucket.

DKIM failures

DKIM failures often trace to DNS publication, selector mismatch, or message modification. If an application begins signing with s=newkey but DNS only publishes oldkey._domainkey.example.com, recipients cannot fetch the correct public key.

A signed message can also fail after a legitimate intermediary modifies it. Footer insertion, mailing-list handling, and aggressive content rewriting are common examples. This is one reason to check a message’s final delivered headers rather than relying only on an original copy generated by the sending application.

DMARC failures

DMARC failures often surprise teams because SPF and DKIM can both show a pass while DMARC still fails. The missing element is alignment.

For example:

Visible From: offers@example.com
SPF domain: bounce.provider-mail.example
SPF result: pass
DKIM d= domain: provider-mail.example
DKIM result: pass
DMARC result: fail

Both lower-level checks passed, but neither authenticated domain aligns with example.com, the domain the recipient sees in the From header. The fix is usually to configure a custom aligned bounce domain, a custom DKIM signing domain, or both.

Another common cause is a mismatch between business ownership and technical ownership. Marketing may control the visible From domain, engineering may operate transactional email, support may use a SaaS platform, and an agency may send campaigns. Without a shared register of authorized services and domains, DMARC reporting exposes a fragmented system rather than a single coherent sending identity.

How to improve your authentication setup

The right fix is rarely “add more records.” It is to establish a clear relationship among the visible From domain, the envelope sender domain, the DKIM signing domain, and every platform that generates mail.

1. Inventory every mail source

List every service that can send using your organization’s domains, including:

• Transactional email APIs and SMTP relays
• Marketing campaign platforms
• Customer support and help desk tools
• Billing, invoicing, and subscription systems
• Recruiting and applicant-tracking systems
• Authentication, password-reset, and identity tools
• Internal applications, scanners, and printers that send alerts
• Agencies or consultants using your domain

For each source, document the visible From domain, return-path domain, DKIM d= domain, selector, sending IPs or provider, purpose, owner, and approximate monthly volume. This is the practical basis for diagnosing reports and deciding which senders require dedicated subdomains.

2. Establish a clean domain architecture

A simple architecture might use example.com for corporate mail and purpose-specific subdomains for automated sending, such as notify.example.com, mail.example.com, or news.example.com. The best choice depends on your brand and operational needs, but consistency matters more than any one naming convention.

Use domains in ways that make ownership understandable. A password reset from security@example.com should not quietly use unrelated infrastructure that signs only as a provider-owned domain. A campaign from news.example.com should have aligned authentication appropriate to that domain.

Subdomains can also help isolate different mail streams. Transactional messages often deserve a separate sending identity from high-volume marketing mail because their recipient expectations, engagement patterns, and delivery priorities differ. Isolation is not a substitute for good practices, but it can make monitoring and remediation more precise.

3. Configure SPF carefully

Publish one SPF policy for each envelope-sender domain you use. Add only the mechanisms required for active senders. Remove obsolete authorizations after migrations are complete.

Before adding another include, examine the resulting DNS lookup chain. A provider’s setup guide may be technically correct for that provider alone but still push your existing domain over SPF evaluation limits when combined with several other tools.

If multiple applications need independent sending paths, using separate envelope subdomains can be easier to manage than continually expanding one parent-domain SPF record. This approach can reduce coupling, clarify ownership, and make future provider changes safer.

4. Enable aligned DKIM for every source

For each sending platform, set up a custom DKIM domain when available. Confirm that the message’s actual d= value is your domain or an aligned subdomain—not only that the provider dashboard says “DKIM active.”

Use key rotation as an operational process rather than an emergency event. Publish a new selector, switch the sender to it, observe successful signatures, and keep the previous selector available long enough for any remaining mail path or queued mail to complete. Avoid deleting an old record immediately after changing a setting.

Your team can use the email API reference and setup guides to configure a verified sending domain and confirm the records required by the sending platform. Regardless of the provider, validate the final delivered message headers after setup rather than assuming a DNS entry alone proves successful signing.

5. Start DMARC in monitoring mode, then enforce deliberately

Begin with p=none and aggregate reporting. Review the data long enough to identify known traffic, unexpected traffic, and messages that are failing due to forwarding or legitimate intermediary behavior.

Do not treat every failing report row as an attack. First determine whether the source belongs to your organization or a vendor. Then decide whether it should be authorized, moved to an aligned domain, retired, or left unauthorized. This classification work is what makes a transition to quarantine and eventually reject safe.

A practical staged approach is:

1. Publish p=none with an aggregate report address.
2. Inventory and authenticate known senders.
3. Fix alignment for legitimate sources.
4. Investigate persistent unknown sources.
5. Move to p=quarantine after the remaining failures are understood.
6. Move to p=reject when legitimate aligned traffic is stable and exceptions are addressed.

Avoid copying a production DMARC policy from another organization. Your domain inventory, email forwarding patterns, vendor landscape, and tolerance for risk are specific to your business.

Complementary technologies: TLS, MTA-STS, and ARC

SPF, DKIM, and DMARC are the core domain-authentication stack, but they are not the only protocols relevant to secure email delivery.

TLS encrypts SMTP connections when both servers support it. It protects mail in transit between servers, but it does not establish that the visible From domain authorized the message. A TLS-protected message can still be spoofed if it lacks domain authentication.

MTA-STS lets a receiving domain publish a policy declaring its support for secure SMTP delivery and specifying that sending servers should refuse delivery to MX hosts that do not present a trusted TLS certificate. It is primarily a receiving-domain transport security control, not a replacement for SPF, DKIM, or DMARC.

ARC (Authenticated Received Chain) was designed to preserve authentication assessments across intermediaries. It can be relevant for mailing lists and forwarding scenarios where original authentication may break during legitimate handling. ARC is not a substitute for configuring aligned SPF, DKIM, and DMARC on mail you originate, and recipients decide how much weight to give ARC information.

These technologies address different layers:

The key operational lesson is to avoid treating any single protocol as complete email security or complete deliverability. Strong sending programs layer identity controls, transport security, recipient consent, and reputation management.

Authentication troubleshooting workflow

When a message is unexpectedly filtered, deferred, or rejected, begin with evidence from the delivered message headers or recipient-side diagnostic. Do not troubleshoot from the visible From address alone.

A disciplined workflow looks like this:

1. Capture the complete headers from a delivered copy or a mailbox test.
2. Locate Authentication-Results and record SPF, DKIM, and DMARC outcomes.
3. Compare identities: visible From domain, return-path domain, DKIM d= domain, and DKIM selector.
4. Inspect DNS records at the exact domain and hostname being evaluated.
5. Identify the sending source by IP address, platform, or application logs.
6. Test a new message after making one controlled change.
7. Monitor reports and delivery behavior before changing DMARC enforcement.

This method separates a protocol failure from a reputation problem. If SPF, DKIM, and DMARC all pass with alignment, but the campaign still performs poorly, the next investigation should focus on list quality, complaint rates, content, volume changes, and recipient engagement—not repeatedly editing DNS records.

It is also worth validating destination addresses before sending important campaigns. Authentication proves your identity, but it cannot make a nonexistent, typoed, or risky recipient address deliverable. Use a free email address verification tool as part of list hygiene, especially before a large campaign or after importing new contacts.

The practical standard for senders

A mature authentication setup has a few recognizable characteristics. Every mail stream has an owner. Every owner knows which domain appears in the From header, which service sends the message, which DKIM selector signs it, and where SPF authorization lives.

The organization also has a process for onboarding and offboarding vendors. Adding a new tool triggers a review of alignment and DNS requirements. Removing a tool triggers removal of old keys, includes, return-path records, and credentials after mail has stopped. This keeps the authentication footprint small enough to understand.

Most importantly, authentication is verified continuously. DNS records can drift, vendors can change sending paths, keys can rotate, and a new application can begin mailing without the deliverability team’s knowledge. Reports, header inspection, and source inventories turn authentication from a one-time project into an operating control.

Conclusion

Email authentication protocols are the identity layer of modern email sending. SPF tells recipients which infrastructure may send for an envelope domain. DKIM proves that a domain signed the message and that protected content remains intact. DMARC connects those results to the visible From domain, provides reporting, and lets a domain owner request action against failed authentication.

For deliverability, the goal is not simply to see three green checks in a setup screen. The goal is to ensure that every legitimate sending source uses aligned identities that recipients can verify, while unauthorized mail using your domain is visible and increasingly difficult to deliver. Start with an inventory, configure SPF and DKIM carefully, use DMARC reporting to understand real traffic, and move toward enforcement only when the data supports it.

FAQ

What are the main email authentication protocols?

The main email authentication protocols are SPF, DKIM, and DMARC. SPF authorizes sending hosts, DKIM cryptographically signs messages, and DMARC evaluates aligned SPF or DKIM against the visible From domain while publishing policy and reporting preferences.

Do SPF and DKIM both need to pass for DMARC to pass?

No. DMARC can pass when either SPF or DKIM passes and the passing identifier aligns with the visible From domain. Configuring both is still recommended because it provides resilience when forwarding affects SPF or message modification affects DKIM.

Why does DMARC fail when SPF and DKIM pass?

Usually because neither passing domain aligns with the visible From domain. For example, SPF may pass for a provider-owned bounce domain and DKIM may pass for a provider-owned signing domain, while the visible From address uses your company domain.

Does a DMARC policy of p=none protect my domain?

It provides visibility through reporting and allows receivers to evaluate DMARC, but it does not request quarantine or rejection of failing mail. It is typically the first stage before stronger enforcement policies are adopted.

Can email authentication guarantee inbox placement?

No. Authentication is a baseline identity and anti-spoofing control, not an inbox-placement guarantee. Mailbox providers also evaluate reputation, complaints, recipient engagement, content, sending patterns, and list quality.