Introduction

The name shown in the From field of an email is the display name attached to the sender address. To set it correctly, you send a From header in the form Display Name <[email protected]> and make sure your mail provider allows that address and domain to send authenticated mail.

Understand the Two Parts of the From Header

The visible sender line normally contains:

• a display name, such as Support Team
• an email address, such as [email protected]

In raw header form, that looks like this:

From: Support Team <[email protected]>

Most email APIs and SMTP libraries expose these as either one formatted string or separate name and email fields. The exact syntax depends on the tool, but the concept is the same.

The display name is presentation. The email address and domain are what authentication systems such as SPF, DKIM, and DMARC actually care about.

Set the Sender Name in Python

Python's standard library makes this straightforward:

1from email.message import EmailMessage
2from email.utils import formataddr
3import smtplib
4
5message = EmailMessage()
6message["Subject"] = "Welcome"
7message["From"] = formataddr(("Support Team", "[email protected]"))
8message["To"] = "[email protected]"
9message.set_content("Your account is ready.")
10
11with smtplib.SMTP("localhost", 25) as smtp:
12    smtp.send_message(message)

formataddr() handles the proper header formatting, which is safer than building the string manually. If the display name contains spaces or non-ASCII characters, that helper is especially useful.

The recipient will usually see Support Team as the sender name, assuming the client does not replace it with a contact name from the user's address book.

Provider APIs Usually Have Explicit Name Fields

Many transactional email providers use structured JSON instead of raw headers. A typical payload looks like this:

1{
2  "from": {
3    "email": "[email protected]",
4    "name": "Support Team"
5  },
6  "personalizations": [
7    {
8      "to": [
9        {
10          "email": "[email protected]"
11        }
12      ]
13    }
14  ],
15  "subject": "Welcome",
16  "content": [
17    {
18      "type": "text/plain",
19      "value": "Your account is ready."
20    }
21  ]
22}

Even though the API format changes, the result is still the same From header concept. If your provider supports separate source, from, or sender fields, read the documentation carefully because those fields can have different meanings.

From, Sender, and Reply-To Are Not the Same

A lot of confusion comes from mixing these headers:

• 'From is the visible author of the message'
• 'Sender identifies who actually sent the message on behalf of the author'
• 'Reply-To controls where replies go'

If you only want to change the visible name, set the From display name. Do not use Reply-To as a substitute. It changes reply behavior, not sender presentation.

This is common in support tools where the visible sender should be Billing Team, but replies should go to [email protected]. In that case, set both headers explicitly and intentionally.

Delivery Rules Still Apply

You cannot reliably send as any display name with any arbitrary address. Mail providers and receiving servers check whether the address and domain are authorized. If you send From: CEO <[email protected]> through a domain you do not control, the message may fail authentication, land in spam, or be rewritten by the provider.

The display name also is not guaranteed to appear exactly as sent. Some clients show the user's saved contact name instead. Others show only the email address on narrow screens. That is a client behavior issue, not a header-format bug.

Common Pitfalls

The biggest mistake is setting only the display name and forgetting that the address still must be valid and authenticated. A correct-looking From header does not override SPF, DKIM, or DMARC checks.

Another common issue is confusing From with Reply-To. If replies go to the wrong inbox, check which header you changed.

Do not manually concatenate complicated names without using your library's helper functions. Quoting and character encoding become error-prone quickly, especially with names that contain commas or non-English characters.

Finally, test in real clients. Gmail, Outlook, Apple Mail, and mobile clients do not always render the sender line in exactly the same way.

Summary

• The visible sender name comes from the display name in the From header.
• Use the form Display Name <[email protected]> or the equivalent structured API fields.
• Keep From, Sender, and Reply-To separate in your design.
• Make sure the sending address and domain are authenticated.
• Test the final rendering in the email clients your users actually use.