SMTP answers a transport question: which server accepts this message and relays it toward its destination? It does not, by itself, prove that the address displayed in the message’s From: header belongs to the system that opened the SMTP connection.
That distinction explains a common surprise. A mail client can connect to an external SMTP service, authenticate successfully, and submit a syntactically valid message with From: user@gmail.com. The SMTP login proves that the client may use that service. It does not give the service authority over gmail.com.
Modern mail systems separate message transport, visible authorship, and domain authentication. SPF, DKIM, and DMARC connect those layers closely enough for receiving servers to decide whether a sender is authorized.
SMTP has an envelope and a message
An SMTP transaction carries an envelope around the message:
MAIL FROM:<bounce@example.com>
RCPT TO:<recipient@example.net>
From: Alice <alice@example.com>
To: recipient@example.net
Subject: ExampleMAIL FROM belongs to the SMTP envelope. It is used for delivery status and is commonly called the envelope sender or return path. The From: field belongs to the message format defined by RFC 5322 and identifies the author presented to the recipient.
These addresses can legitimately differ. Mailing lists, transactional platforms, forwarding systems, and bounce-processing infrastructure often need that separation.
The separation also means that changing From: is not proof of identity. A client can construct a header containing almost any syntactically valid mailbox. Authorization is evaluated separately.
SMTP authentication authenticates an account to a relay
Submission servers commonly require credentials before accepting mail:
client
|
| SMTP AUTH + TLS
v
submission server
|
| SMTP relay
v
recipient MXSuccessful SMTP AUTH means the submission server accepted the credentials according to its own policy. The policy may restrict which From: addresses that account can use, but that restriction is a service feature, not a general property of SMTP.
This is why an SMTP username and a visible sender address should not be treated as the same identity.
A provider such as Resend can authorize a customer to send for a domain the customer has verified. That authorization does not extend to unrelated domains such as gmail.com, because the customer cannot publish the required authentication records for Google’s domain.
SPF authenticates the envelope domain
SPF publishes a DNS policy describing which systems may send mail for a domain. In normal SMTP processing, SPF is evaluated against the domain associated with the envelope sender, not simply against the visible From: header.
A simplified flow is:
MAIL FROM:<bounce@mailer.example.com>
|
v
SPF policy for mailer.example.com
|
v
sending IP authorized?An SPF pass therefore does not automatically prove that a different visible author domain is authorized.
For example, a third-party service could pass SPF for its own bounce domain while a message displays another domain in From:. DMARC exists partly to require a meaningful relationship between the authenticated domain and the visible author domain.
DKIM authenticates a signed domain
DKIM adds a cryptographic signature to selected message headers and body content. A DKIM signature identifies its signing domain with the d= parameter:
DKIM-Signature: ...; d=example.com; s=selector1; ...The receiving server retrieves the public key from DNS and verifies the signature. A valid signature shows that a holder of the corresponding private key signed the message for that DKIM domain and that the signed content survived verification.
A mail provider can sign for a customer’s verified domain because the customer delegates the necessary DKIM DNS record. It cannot independently create an aligned gmail.com DKIM identity: the relevant DNS namespace is controlled by Google.
DMARC connects authentication to the visible From domain
DMARC evaluates the domain in the RFC 5322 From: field and asks whether it aligns with an authenticated SPF or DKIM domain.
Conceptually:
visible From domain
example.com
|
+------------+------------+
| |
v v
SPF-authenticated domain DKIM signing domain
| |
+------------+------------+
|
DMARC alignmentPassing SPF somewhere in the delivery path is not enough if the SPF identity is unrelated to the visible From: domain. Likewise, a valid DKIM signature from an unrelated provider domain does not establish alignment with the author’s domain.
For direct mail to personal Gmail accounts, Google’s sender guidance requires the organizational domain in the visible From: header to align with either the SPF or DKIM organizational domain for bulk senders. Google also explicitly warns senders not to impersonate Gmail From: headers.
External SMTP cannot acquire authority over gmail.com
Suppose a client submits this message through an external SMTP provider:
SMTP server: smtp.provider.example
Authenticated account: customer-account
From: Person <person@gmail.com>
To: recipient@example.netThe external provider may be perfectly capable of transporting the message. The identity problem appears later.
The provider can normally authenticate domains it controls or domains delegated to it by customers. It cannot add itself to the SPF policy for gmail.com, publish a DKIM public key under Google’s DNS, or change Google’s DMARC policy.
The resulting message can therefore be syntactically valid SMTP mail while still failing the authentication or alignment expected for the visible Gmail identity.
This is a DNS authority boundary, not a limitation of a particular Linux client, Thunderbird, swaks, or another SMTP tool.
A custom domain changes the authority boundary
The situation is different for a domain you control:
From: alerts@example.com
SMTP provider: external service
example.com DNS
|
+-- SPF authorization
+-- DKIM public key
+-- DMARC policyThe domain owner can authorize the provider through the DNS records required by that provider. The service can then send mail with authentication identities aligned to example.com.
This is the normal architecture for transactional mail services. The application does not need to operate its own internet-facing mail transfer agent, but the domain owner still retains control over which service is authorized to represent the domain.
Gmail as a client is different from Gmail as an identity
A Gmail web interface or desktop mail client is an application layer. SMTP is a transport mechanism. The address in From: is an identity presented inside the message.
Those roles should be kept separate:
mail client / UI
|
v
SMTP submission service
|
v
SPF / DKIM authentication
|
v
DMARC alignment with From:
|
v
receiving mail systemUsing Gmail to compose a message does not automatically authorize every external SMTP provider to represent gmail.com. Conversely, using an external SMTP provider is normal when the visible sender belongs to a domain that has been configured to authorize that provider.
Testing from Linux exposes the layers clearly
A tool such as swaks is useful because it shows the SMTP transaction rather than hiding it behind a full mail client:
swaks \
--server smtp.example.com \
--port 587 \
--tls \
--auth LOGIN \
--auth-user user@example.com \
--auth-password 'APP_PASSWORD' \
--from sender@example.com \
--to recipient@example.netThe command can confirm that TLS negotiation, SMTP authentication, envelope submission, and relay acceptance work. It cannot by itself prove that SPF, DKIM, and DMARC will pass at the recipient.
That evidence is available after delivery in authentication results added by receiving infrastructure, commonly including Authentication-Results: with SPF, DKIM, and DMARC outcomes.
Transport success and identity success are separate results
A server returning 250 OK after message submission means it accepted responsibility for the message at that SMTP stage. It is not a universal certificate that the visible sender identity is authentic or that every downstream receiver will accept the message.
The useful model is therefore two separate questions:
Can this SMTP server transport the message?
|
v
SMTP acceptance
Is the visible From domain authorized?
|
v
SPF / DKIM / DMARCFor an address under a domain you control, an external SMTP provider can be authorized through DNS and produce aligned authentication. For an @gmail.com identity, that authority remains with Google’s domain infrastructure. Changing the SMTP relay does not transfer control of the sender domain.