SMTP AUTH vs SPF, DKIM, and DMARC: What Each Proves

SMTP AUTH proves that a client authenticated to one mail submission server and was allowed to use that server. It does not prove that the visible From: domain authorized the message. SPF, DKIM, and DMARC supply that separate domain evidence when another server receives the mail.

That is why a message can have auth=pass and dmarc=fail at the same time. Nothing is contradictory. The two results describe different checks, different identities, and different points in the route.

Which identity did each check authenticate?

My rule for any mail log that says “authenticated” is to fill in four coordinates: who performed the check, which identity it evaluated, what scope the result covers, and what still needs separate evidence.

The first row controls access to a submission service. The other rows describe evidence a receiving system can evaluate after the message leaves that service.

How can SMTP AUTH pass while DMARC fails?

Follow one hypothetical submission. The names use reserved .example domains, and the credential response is deliberately redacted.

C: EHLO app.customer.example
S: 250-STARTTLS
S: 250 AUTH PLAIN
C: STARTTLS
S: 220 Ready to start TLS
... TLS negotiation ...
C: EHLO app.customer.example
S: 250 AUTH PLAIN
C: AUTH PLAIN [REDACTED]
S: 235 2.7.0 Authentication successful
C: MAIL FROM:<bounce@mailer.example>
S: 250 2.1.0 Sender OK
C: RCPT TO:<reader@receiver.example>
S: 250 2.1.5 Recipient OK
C: DATA

From: Billing <billing@brand.example>
To: Reader <reader@receiver.example>
Subject: Your receipt

...

The 235 reply says the client completed the AUTH exchange with this submission server. RFC 4954 defines that reply as successful authentication. It does not say that brand.example matches the authenticated account, the envelope sender, or a DKIM signing domain.

Assume the submission service now sends the message from an authorized IP and signs it as mailer.example. The final receiver could record this:

Authentication-Results: mx.receiver.example;
  auth=pass smtp.auth=app-account@mailer.example;
  spf=pass smtp.mailfrom=mailer.example;
  dkim=pass header.d=mailer.example;
  dmarc=fail header.from=brand.example

SMTP AUTH passed for the application account. SPF and DKIM passed for mailer.example. DMARC failed because neither authenticated domain aligned with the visible author domain, brand.example.

RFC 8601 keeps the SMTP AUTH result and its smtp.auth identity separate. The same standard reports SPF against smtp.mailfrom or HELO and DKIM against signature properties. The labels are separate because the evidence is separate.

What does SMTP AUTH actually authorize?

SMTP AUTH is an extension to SMTP submission. After EHLO, the server can advertise supported authentication mechanisms. The client selects one with the AUTH command, and the server decides whether the resulting identity may submit mail.

Submission and relay are different roles. RFC 6409 describes authenticated SMTP as one way for a Message Submission Agent to establish an authorization identity. It also says an MSA should reject an unauthenticated session by default unless it has independently established authorization, such as a protected network.

That authorization can drive useful local policy:

• which envelope sender or visible From: domains the account may use;
• which recipients, rate limits, or message sizes are allowed;
• whether the service adds DKIM after accepting the message;
• which account should appear in audit logs when abuse occurs.

Those controls belong to the submission provider. AUTH itself does not require every server to bind the login identity to every address inside the message. A provider can add that restriction, but the receiving server cannot infer it from a successful login that happened upstream.

If the provider knows the account, why is that not enough?

The strongest fair objection is that the submission provider knows who logged in, so the mail should already be trustworthy.

It is useful evidence for that provider. It is not public authorization from every domain named in the message. An account can be compromised. A legitimate account can be misconfigured. A multi-tenant service can allow a customer to choose a From: domain before ownership is established. Authentication answers whether the client proved possession of an accepted credential. Authorization policy decides what that client may send.

The remote receiver also did not participate in the login. It needs evidence that survives or can be recomputed at its own boundary. SPF uses the connection and envelope domain. DKIM uses a signature and DNS key. DMARC connects one of those results to the domain readers see.

Why must SMTP AUTH run inside TLS?

AUTH mechanisms and transport encryption are separate. A Base64-encoded AUTH PLAIN response is not encrypted merely because it looks unreadable.

RFC 8314 recommends implicit TLS for submission and applies the Message Submission Agent requirements, including SMTP AUTH, to that service. It also requires modern submission servers to support TLS. Port 465 starts inside TLS; port 587 normally discovers and negotiates STARTTLS before credentials are sent. The SMTP ports guide traces those handshakes.

After STARTTLS, send EHLO again. Capabilities advertised before TLS can change, including the available AUTH mechanisms. Never copy a real AUTH blob into a ticket or log. With the PLAIN mechanism, the response carries an authorization identity, authentication identity, and password, then SMTP represents the response in reversible Base64.

Do SPF, DKIM, and DMARC replace SMTP AUTH?

No. Domain authentication does not decide whether an application may use your submission server.

SPF tells a receiver whether the connecting IP is authorized for the SMTP envelope identity. DKIM tells it whether a signature validates for the domain in d= and whether the signed content survived. DMARC asks whether at least one passed identity aligns with the domain in the visible From: field.

The SPF, DKIM, and DMARC guide owns that receiver-side relationship. The practical boundary here is simpler: SMTP AUTH gets a client into the submission system; domain authentication gives later receivers evidence about the message and its claimed domains.

How should a production sender connect the two planes?

Make the submission identity and the domain identities meet in policy, even though the protocols keep them separate.

1. Encrypt submission before authenticating. Use implicit TLS on port 465 or STARTTLS on 587, verify the server certificate, and fail closed if the configured secure mode is unavailable.
2. Give each application its own credential or token. Scope it to the smallest useful sender set. A shared account makes revocation and attribution harder.
3. Restrict allowed sender identities. Bind the authenticated account to approved envelope and visible From domains. Reject a mismatch instead of silently sending it.
4. Align the public evidence. Use an SPF-authorized custom return-path domain and sign with an aligned DKIM domain. Publish and monitor DMARC for the visible author domain.
5. Read results by identity, not by the word pass. Confirm which smtp.auth, smtp.mailfrom, header.d, and header.from values produced each result. Trust only Authentication-Results fields added inside your receiver's boundary.

One subtle failure deserves a test: authenticate as account A, then attempt to submit a message using account B's approved From: domain. The safe outcome is a rejection at submission. If it succeeds, AUTH worked but sender authorization is too broad.

Does any of this verify the recipient?

No. SMTP AUTH, SPF, DKIM, and DMARC concern the sending path and sending-domain identities. They do not prove that a signup address belongs to a person, that its mailbox exists, or that a message will reach the inbox.

Email verification evaluates recipient-side evidence such as address format, mail routing, provider risk, and available mailbox signals. Confirmation tests whether someone can act through the destination inbox. The validation, verification, and confirmation guide keeps those questions separate.

When a log says “authenticated,” ask for the four coordinates before acting: which system checked, which identity it checked, what scope the result covers, and what evidence is still missing. A 235 SMTP reply can authorize one client session. It cannot carry another domain's approval all the way to the recipient.