Logo files for email signatures: a light and dark mode handoff

1. Agree who will install the signature

A client asks for “the logo for our email signatures.” Before exporting, find out whether they will insert it into Gmail, configure Outlook on each computer, or use an organization-wide signature tool. These are different delivery workflows, even when the artwork is identical.

Ask who owns installation and which sending applications employees actually use. Record the important recipient applications separately. A signature composed in Outlook may be read in Gmail or Apple Mail; its appearance in the sender’s settings panel is not acceptance evidence.

Keep the scope explicit: supplying a logo image and its specification is not the same service as coding an HTML signature, hosting images, deploying it to every employee or maintaining it after email-client updates.

• ✓Sending application and signature editor identified.
• ✓Person responsible for installation and rollout named.
• ✓Priority receiving applications and devices agreed.
• ✓Linked-image or embedded-image method agreed with the implementer.
• ✓Artwork delivery separated from HTML, hosting and maintenance responsibilities.

2. Approve one fallback treatment before making variants

Use PNG as a conservative starting deliverable when the chosen signature editor accepts it. Keep the vector master separately; do not assume that support for an SVG on a website proves that the signature workflow handles it in the same way. Email-format support changes, and linked SVG is not the same case as SVG markup embedded in a message.

Place the actual exported PNG on both a pale and a dark canvas. Check the complete mark, including thin strokes, counters and a small tagline. This is an artwork check, not a simulation of every inbox. A dark transparent wordmark can lose contrast on a dark background; a white transparent version can disappear on a pale one.

If the identity allows it, compare a version on an opaque pale tile whose background is part of the image itself. Preserve the approved clear space. This gives the artwork a defined background without depending only on the HTML surrounding it, but the received result still needs testing. The visible tile may be a deliberate compromise, not an error to hide.

Do not add a white outline, glow or different logo color simply because a tutorial calls it a dark-mode fix. Those are changes to the identity. Obtain approval for the treatment and keep the approved master unchanged.

Continue with: Prepare approved one-color and reversed artwork

Further reading: Can I Email: PNG tests · Can I Email: linked SVG tests

3. Do not confuse two assets with automatic switching

You can deliver approved light-background and dark-background versions when the implementation needs them. Label their intended use. Do not promise that the email application will choose the right file merely because both exist in the folder.

Automatic swapping is an implementation feature that must work in the particular signature editor and recipient clients. A website’s dark-mode CSS is not a portable signature recipe. Gmail documents a limited set of supported CSS and media-query features; unsupported rules can be ignored. A signature fragment also cannot be assumed to control the <head> element of the complete email HTML.

Ask the implementer to demonstrate the switching with received test messages. If that cannot be demonstrated across the agreed targets, choose the approved fallback treatment rather than delivering an invisible logo and calling the second file a solution.

Further reading: Google: supported Gmail CSS

4. Put the display specification beside the file

Exported pixel dimensions and displayed dimensions are different instructions. For example, a 360 × 90 PNG intended to appear at 180 × 45 needs the installation to constrain its display size. Otherwise, the larger file may simply appear larger. These numbers illustrate the relationship; they are not a universal email-signature standard.

Keep the aspect ratio intact, and include any built-in clear space in the specification. If a signature tool resizes or recompresses the upload, inspect the received image before exporting yet another size. Google’s Gmail troubleshooting guidance is useful for that editor, but it should not be treated as the specification for every client.

Asset: FORM_Email_PaleTile_360x90.png
Exported image: 360 × 90 px
Intended display: 180 × 45 px, proportional
Treatment: approved dark mark on an opaque pale tile
Clear space: included inside the image
Suggested alt text: FORM
Installation owner: client IT / signature implementer
Acceptance: received-message checks below

Example values only. Confirm against the actual editor.

Continue with: Calculate export and display dimensions

Further reading: Google: troubleshoot Gmail signatures

5. Keep essential information outside the image

Do not make the employee’s entire signature a single flattened picture. Keep the name, role, email address, phone number and website as text where the signature editor supports it. Give the implementer a concise suggested alternative text for the logo, and verify how their editor handles it.

Remote images may not load because of recipient settings, an inaccessible hosted file or a changed image URL. Microsoft documents blocked picture downloads in classic Outlook, and Apple documents remote-content privacy controls. An empty image area does not by itself prove that the logo export is defective.

If the installation uses a hosted image, the implementer should confirm that recipients can retrieve it without signing into the designer’s private file storage. Agree who maintains that location. Do not solve a missing logo by telling recipients to weaken their privacy settings.

Further reading: Microsoft: picture downloads in classic Outlook · Apple: Mail privacy settings

6. Approve a received message, not the editor preview

Install the candidate through the same workflow the client will use. Send a real test to controlled test inboxes, then inspect the received message. Include the priority clients agreed at the start, not a claim of universal coverage. Gmail web and mobile, relevant Outlook versions and Apple Mail can be useful targets when the client’s audience uses them.

Check light and dark message backgrounds where available. Outlook’s interface theme and message background can be adjusted separately, so “Outlook dark mode” is not a complete test description. Record the application, version or build where available, platform, relevant settings and date.

Inspect a reply and a forward as well as the first message. Confirm that the logo remains recognizable at its displayed size, does not stretch or dominate the signature, and does not become the only source of essential contact information when images are blocked.

Keep a few received screenshots and a short issue list with the handoff. Record what was actually tested. If a client or signature platform changes later, repeat the affected checks rather than assuming an old approval covers every future version.

Further reading: Microsoft: dark mode and message backgrounds in Outlook

7. Separate artwork problems from installation problems

If the downloaded PNG is already clipped, has the wrong background or uses an unapproved logo version, return to the artwork and export settings. If the file is correct but the received message stretches it, investigate the signature’s sizing. If it disappears only when remote images are blocked, investigate loading and fallback behavior.

This distinction prevents an endless loop of “please send a bigger logo” when the real problem is installation. Hand over the approved asset, the intended dimensions, the tested configurations and any known limitation together.

• Designer: approved artwork, background treatment, exported pixels and file naming.
• Implementer: insertion method, display sizing, image delivery and rollout.
• Client: priority environments, brand approval and acceptance of documented limitations.

8. Package the approved assets, then keep email QA separate

Once the artwork and background treatment are approved, logopack.app can help assemble the available exports from an existing SVG into an organized logo package. Review the actual PNG you plan to use and its dimensions. Check the current plan and available export options before promising a particular delivery.

The package is not an email-signature installer, hosted-image service or inbox compatibility test. Keep the email-specific note and received-message evidence alongside the delivered assets, and let the person responsible for the signature validate the installation.

For the wider identity handoff, include only the approved variants and a short explanation of where each belongs. A useful package reduces guessing; it does not remove the need to test the final destination.

Continue with: Build the wider client handoff

Further reading: Prepare the approved logo package · Review the current plans