# Email server authentication methods explained

> Email server authentication methods use SPF, DKIM, and DMARC to verify sending domains, while SMTP AUTH controls client access to mail servers.

An email server authentication method usually means domain authentication: SPF identifies hosts authorized to send for a domain, DKIM verifies a signed message, and DMARC evaluates aligned SPF or DKIM results for the visible From domain. This is separate from SMTP AUTH, which authenticates a mail client to its outbound server. The controls work at different points in mail delivery and are normally used together.

## Quick takeaways

- SPF publishes the hosts authorized to use a domain in SMTP `HELO` and `MAIL FROM` identities.
- DKIM lets a receiver verify that signed parts of a message were not altered after signing.
- DMARC evaluates SPF or DKIM results against the message's visible From domain.
- SMTP AUTH is a client-to-server login protocol, not a replacement for SPF, DKIM, or DMARC.
- RFC 9989 is the current DMARC specification and obsoletes RFC 7489.
- A published DNS record does not prove that a production message uses the intended sending path.

## Who is affected?

Domain authentication affects organizations that send mail using their own domain, including mail sent through a company mail system, a marketing platform, a support platform, or a transactional application. Receiving systems use the resulting authentication evidence when they process a message.

The most useful distinction is between domain authentication and client authentication:

- SPF, DKIM, and DMARC help a receiving server assess whether mail is authorized to use a domain.
- SMTP AUTH allows a mail client or application to authenticate to its own outbound SMTP server before submitting mail.

[SMTP AUTH in RFC 4954](https://www.rfc-editor.org/rfc/rfc4954.txt) defines an SMTP service extension for authentication between a client and server. It does not publish authorization to the public DNS and does not tell an external receiver whether a domain authorized a message.

For the domain-authentication layer, [RFC 9989 defines DMARC](https://www.rfc-editor.org/rfc/rfc9989.txt) as a policy and reporting mechanism that consumes authenticated identifiers produced by SPF and DKIM. Read the broader explanation of [what email authentication is and why it matters](/learning/what-is-email-authentication-and-why-does-it-matter) if you need the business and delivery context.

## What are the requirements?

### SPF authorizes SMTP sending hosts

[SPF, defined by RFC 7208](https://www.rfc-editor.org/rfc/rfc7208.txt), uses a DNS record to declare which hosts are and are not authorized to use a domain in the SMTP `HELO` and `MAIL FROM` identities. The receiver evaluates the SPF record for the identity used by the message, not automatically the visible From address.

An illustrative SPF record shape looks like this:

```text
yourdomain.com. IN TXT "v=spf1 ip4:192.0.2.10 -all"
```

> Do not publish this example unchanged. Your SPF record must reflect the actual hosts and services authorized to send mail for your domain.

SPF therefore answers the question, "Which MTA email servers are authorized to send email for this domain?" It identifies sending hosts for the SMTP envelope identity. It does not, by itself, prove alignment with the domain a recipient sees in the From header.

### DKIM signs the message and publishes a public key

[DKIM, defined by RFC 6376](https://www.rfc-editor.org/rfc/rfc6376.txt), lets a sending system add a cryptographic signature to a message. The receiving system retrieves the associated public key from DNS and verifies the signature.

A DKIM public-key record is published below a selector chosen by the sending system:

```text
selector1._domainkey.yourdomain.com. IN TXT "v=DKIM1; k=rsa; p=PUBLIC_KEY_MATERIAL"
```

> This is illustrative only. Do not reuse a selector or key from an example. Your sending platform generates the selector and public key values for your account.

A valid DKIM result means the receiver could validate the signature using the published key and the signed message data. It does not mean every message from the domain will pass. Each production sending path must be configured to sign mail with the expected domain and selector.

### DMARC evaluates aligned SPF or DKIM evidence

[RFC 9989](https://www.rfc-editor.org/rfc/rfc9989.txt) defines DMARC and states that SPF and DKIM produce the Authenticated Identifiers that DMARC evaluates. DMARC uses the visible `From:` domain as its organizing identity. For DMARC to pass, either SPF or DKIM must pass and align with that domain under the applicable alignment rules.

A DMARC record is a DNS TXT record at `_dmarc.<domain>`:

```text
_dmarc.yourdomain.com. IN TXT "v=DMARC1; p=none"
```

The `p=none` example is a monitoring policy shape. It is not a universal starting point or a safe policy for every domain. Policy changes affect mail handling, so review aggregate-report evidence and all known sending sources before changing enforcement.

![Checklist showing SPF host authorization, DKIM message signing, and DMARC alignment for yourdomain.com](/images/editorial/email-server-authentication-method/email-server-authentication-method-checklist.webp "1200x524")

*Source: Palisade.*

DMARC is not a third authentication mechanism in the same sense as SPF and DKIM. SPF and DKIM provide authentication results. DMARC applies policy and alignment rules to those results.

### SMTP AUTH controls access to an outbound server

SMTP AUTH is relevant when an email client, application, or device needs permission to submit mail through an SMTP server. RFC 4954 specifies the `AUTH` SMTP extension and its authentication exchange.

```text
C: AUTH mechanism initial-response
S: 235 2.7.0 Authentication successful
```

SMTP AUTH can stop an unauthenticated client from using a submission service. It does not create an SPF record, add a DKIM signature, or establish DMARC alignment at the receiving server. Treat SMTP AUTH as an access control for message submission, then configure the server's outbound path to apply the domain-authentication controls described above.

## When does the requirement take effect?

There is no single effective date for all email server authentication. SPF was published as [RFC 7208 in April 2014](https://www.rfc-editor.org/rfc/rfc7208.txt), DKIM as [RFC 6376 in September 2011](https://www.rfc-editor.org/rfc/rfc6376.txt), and SMTP AUTH as [RFC 4954 in July 2007](https://www.rfc-editor.org/rfc/rfc4954.txt).

DMARC's current controlling specification is [RFC 9989, published in October 2025](https://www.rfc-editor.org/rfc/rfc9989.txt). It obsoletes RFC 7489. DMARC reporting was separated into RFC 9990 and RFC 9991, so implementation work should use the current RFC series rather than relying on an older DMARC draft or RFC 7489 alone.

Mailbox providers may set their own operational requirements. For example, Google's sender rules are separate from the RFC publication dates and can change independently. Keep transport encryption distinct from authentication by reviewing [email transport security](/learning/email-transport-security).

## How do I implement the requirement?

### 1. Inventory every system that sends as the domain

List each production system that sends mail using the domain, including corporate mail, applications, support tools, and marketing systems. Record the SMTP envelope domain, visible From domain, DKIM signing domain, and the system that controls DNS.

This inventory is implementation guidance. The RFCs define protocol behavior, but they cannot identify undisclosed sending systems in your environment.

### 2. Publish SPF authorization for the actual envelope senders

Publish an SPF TXT record for the domains used in `HELO` and `MAIL FROM`. Include only the sending hosts and authorized service mechanisms that your organization actually uses.

Check DNS lookup limits and the record's full evaluated structure before adding multiple service includes. A record that omits a legitimate sender can cause SPF failure. A record that authorizes an unintended sender expands who can use the envelope domain.

### 3. Configure DKIM signing for every sending path

Generate the DKIM selector and public key in each sending system, then publish the generated public key at the required selector name. Send a test message through each production path and inspect its delivered headers for a DKIM result.

Do not assume a platform's configuration page proves live signing. The delivered message is the evidence that the production path added a signature and that a receiver could validate it.

### 4. Publish DMARC and check alignment

Publish the DMARC TXT record at `_dmarc.<domain>`. Compare the visible From domain with the SPF-authenticated domain and DKIM signing domain in messages from every sending path.

Start with evidence, not a policy guess. DMARC aggregate reports can show sources and authentication or alignment issues once reports accumulate. [DMARC and DKIM implementation guidance](/resources-post/in-depth-guide-to-understanding-and-implementing-dmarc-and-dkim) can help with the adjacent configuration task.

## How do I validate compliance?

Validate each layer independently:

- DNS: query the authoritative DNS service and at least one public resolver for SPF, DKIM, and DMARC records. Use the [DNS lookup tool](/tools/dns-lookup) to inspect public DNS responses.
- Sender configuration: confirm each platform reports that it has verified the DNS records or activated signing, where the platform provides that status.
- Delivered message: send a real message through the exact production path and inspect its `Authentication-Results` header. RFC 8601 defines the syntax and trust model for that field.
- DMARC: review aggregate reports after they accumulate to identify sources and alignment outcomes across the domain.

A public DNS lookup can show a currently resolvable record. It cannot prove that a specific application signed the message, that a receiver accepted the message, or how a receiver will make a private reputation or placement decision.

Gmail documents the following SMTP error for unauthenticated sending:

```text
550 5.7.26 This email has been blocked because the sender is unauthenticated. Gmail requires all senders to authenticate with either SPF or DKIM.
```

Use [Google's Gmail SMTP error documentation](https://knowledge.workspace.google.com/admin/support/troubleshooting/gmail-smtp-errors-and-codes) with the message headers to determine whether the failure concerns SPF, DKIM, or the actual sending path.

## Check the authentication records, then separate transport security

Inspect the public SPF, DKIM, and DMARC records for the sending domain before changing a record. Then compare those records with a message sent through the affected production path.

[Read the email transport security guide](/learning/email-transport-security) to assess TLS and transport controls separately. A DNS check cannot prove message behavior, monitor later DNS changes, or guarantee how a receiving provider will treat a future message.

If you need ongoing visibility into authentication results and sending sources, [sign up for Palisade](https://app.palisade.email/signup) to monitor your domain's email authentication.

## Sources and further reading

- [RFC 9989: Domain-based Message Authentication, Reporting, and Conformance](https://www.rfc-editor.org/rfc/rfc9989.txt)
- [RFC 7208: Sender Policy Framework](https://www.rfc-editor.org/rfc/rfc7208.txt)
- [RFC 6376: DomainKeys Identified Mail Signatures](https://www.rfc-editor.org/rfc/rfc6376.txt)
- [RFC 4954: SMTP Service Extension for Authentication](https://www.rfc-editor.org/rfc/rfc4954.txt)
- [Google Workspace Gmail SMTP errors and codes](https://knowledge.workspace.google.com/admin/support/troubleshooting/gmail-smtp-errors-and-codes)

## Frequently asked questions

### How do I fix email server authentication?

Publish SPF authorization for the actual sending hosts, configure each sending system to sign with DKIM and publish its public key, then publish DMARC at `_dmarc.<domain>`. Confirm on a delivered production message that SPF or DKIM passes and aligns with the visible From domain. A DNS record alone does not prove the sending application is using it.

### Which email authentication method identifies who the MTA email servers are that have been authorized to send email for a domain?

SPF. RFC 7208 defines an SPF record as a DNS record that declares which hosts are authorized to use a domain name for the SMTP `HELO` and `MAIL FROM` identities.

### What are the three types of authentication methods?

No email RFC defines SPF, DKIM, and DMARC as three equivalent authentication methods. SPF and DKIM are authentication mechanisms. DMARC is the policy and alignment layer that evaluates their authenticated identifiers for the visible From domain.

### What are the different types of email authentication?

SPF authorizes SMTP sending hosts, DKIM verifies a message signature, and DMARC evaluates aligned SPF or DKIM results. SMTP AUTH is separate because it authenticates a client to its outbound SMTP server rather than authenticating the domain to a receiving server.

### Does SMTP AUTH replace SPF, DKIM, or DMARC?

No. SMTP AUTH controls whether a client can submit mail through an SMTP server. SPF, DKIM, and DMARC provide domain-authentication evidence to receiving systems after the server sends the message.