Set up a new Outlook signature after switching domains

Start with a short pre-flight checklist, build a resilient HTML plus plain-text signature, then update each Outlook client or your central signature system. This guide supplies the assets, ordered steps for New Outlook (Windows), Classic Outlook (Windows), Outlook for Mac, Outlook on the web (OWA), and Outlook mobile. It also includes admin ticket text, bulk find-and-replace options, a verification matrix, troubleshooting steps, and an escalation checklist for tenant/global admins.

Pre-flight checklist: what to gather and who must approve

Direct answer: Gather the exact addresses, hosted images, final legal text, approved links, test mailboxes, and the right admin contacts. Get branding, legal, and security approvals before you edit signatures.

Prerequisites — what you must have before changing signatures:

• Exact mailbox addresses and aliases (user@newdomain.com).
• Hosted image URLs on HTTPS on your domain or an approved CDN (logo, social icons). Filenames should be predictable.
• Final legal/disclaimer text in plain text and HTML; translations if required.
• Approved link targets on the new domain that resolve over HTTPS.
• Test mailboxes: internal tenant mailbox, external personal mailbox (Gmail/Outlook.com), external corporate mailbox, and a mobile test account.
• Admin contacts: tenant/global admin, Exchange Online admin, CDN/hosting owner.
• Knowledge of whether signatures are centrally managed and which tool is authoritative (Exchange transport rule, Microsoft 365 setting, or a third-party signature platform).

Approvals to collect before you edit anything:

• Branding approval for image assets and approved image hosting.
• Legal/compliance signoff for disclaimer copy and any mandatory notices.
• Security approval if images or assets will be publicly hosted on a CDN.

Build a resilient signature that survives client differences

Direct answer: Use simple table-based HTML with inline attributes, host images on HTTPS, include a plain-text fallback, and keep visible text short. Put long legal text behind a short summary and a link.

Design constraints and choices:

• Host images on HTTPS on your domain or a vetted CDN and use absolute URLs.

• Use simple table-based HTML and inline font attributes; many Outlook clients strip advanced CSS.

• Always include a plain-text fallback for clients that block HTML.

• Keep the visible signature compact so mobile clients don't hide it behind reply markers.

• Avoid base64-embedded images; some gateways strip them and they increase message size.

Practical template to start from (edit names and values):

<table cellpadding="0" cellspacing="0" border="0">
  <tr>
    <td style="padding-right:12px;vertical-align:middle;"><img src="https://newdomain.com/assets/logo.png" alt="Company" width="200"></td>
    <td style="vertical-align:middle;font-family:Arial, sans-serif;font-size:12px;color:#000;">
      <div><strong>First Last</strong></div>
      <div>Job Title</div>
      <div>Company Name</div>
      <div><a href="mailto:first.last@newdomain.com">first.last@newdomain.com</a> | +1 (555) 555-5555</div>
      <div><a href="https://newdomain.com">newdomain.com</a></div>
    </td>
  </tr>
</table>
<p style="font-size:10px;color:#666;margin:8px 0 0;">Short legal summary. Full text at https://newdomain.com/disclaimer</p>

Practical notes:

• Keep file names predictable so you can script find-and-replace later.

• Test the HTML by opening it in a browser and by pasting rendered content into each target editor; Outlook may still differ.

• If you must include long legal copy, place a one-line summary and link to the full text on your website to reduce truncation risk.

Step-by-step: update signatures in each Outlook client and mobile

Direct answer: Follow the steps for each client in order, then run the tests from the pre-flight checklist. If a client refuses HTML, fall back to plain text and open an admin ticket for central application.

New Outlook (Windows)

1. Open New Outlook and click the gear icon (Settings) at top right.
2. Select View all Outlook settings then Compose and reply.
3. Paste the HTML into the signature editor. If the editor strips HTML, open your HTML file in a browser, copy the rendered content, then paste.
4. Set defaults for New messages and Replies/forwards to the new signature.
5. Click Save.

Classic Outlook (Windows)

1. File > Options > Mail > Signatures.
2. Click New and give the signature a name.
3. If you have an .html signature file, open it in a browser, select all and copy, then paste into the editor.

%appdata%\Microsoft\Signatures

4. Alternatively, edit the files in %appdata%\Microsoft\Signatures including the .htm, .rtf, and image files.
5. Assign the signature to New messages and Replies/forwards and click OK.
6. Send test messages.

Outlook for Mac

1. Outlook > Preferences > Signatures.
2. Click + to create a new signature and name it.
3. Open your HTML in a browser, copy the rendered content, and paste into the Mac signature editor.
4. Drag the signature to the account and set it as default for New and Replies.
5. Send test messages.

Outlook on the web (OWA)

1. Settings (gear) > View all Outlook settings > Mail > Compose and reply.
2. Paste your HTML into the signature box, or paste rendered content from a browser if HTML is stripped.
3. Check the boxes to automatically include the signature on new messages and on replies/forwards if desired.
4. Save and send tests.

Outlook mobile (iOS/Android)

1. Open the Outlook app, tap your avatar > Settings > Signature.
2. Paste a plain-text or very simple HTML version (no tables). If the app strips HTML, fall back to plain text.
3. Save and send tests from the mobile device.

If your org controls signatures: admin updates and copy-ready ticket text

Direct answer: Decide whether to update client-side or server-side. Client-side preserves Sent Items exactly. Server-side gives consistent recipient view but may alter Sent Items. If you need tenant changes, open a ticket with the exact edits.

Decision point: client-side edit vs central server-side insertion.

• Client-side edits keep the signature in the user's Sent Items as composed.
• Server-side insertion (Exchange transport rule or third-party platform) applies signatures for recipients but may modify messages after send.

Exchange Online transport rule — fields to update:

• Condition: apply to messages from the affected users or group.
• Action: Append the disclaimer or replace the signature; paste updated HTML in the editor.
• Images must be hosted on HTTPS and accessible to recipient servers.
• Keep existing exceptions intact (internal-only, external-only rules).

Copy-ready admin ticket (edit before sending):

Subject: Update Exchange transport signature for newdomain.com

We switched primary email domain to newdomain.com. Please update the organization-wide signature/disclaimer:

1) Replace all occurrences of https://olddomain.com/assets/ with https://newdomain.com/assets/ in the Exchange transport rule that appends signatures.
2) Update the HTML body to the attached file signature-newdomain.html.
3) Ensure the rule applies to users in group: <security-group-or-OU> and keeps existing exceptions.
4) Confirm images at https://newdomain.com are accessible over HTTPS and not blocked by hotlink protections.

Please reply with the updated rule name and a timestamp when the change is complete.

When to involve tenant/global admins:

• You need transport-rule edits, tenant-wide signature settings, or DKIM/SPF configuration changes.
• You need DNS changes or a CNAME to permit CDN hosting or a third-party signature service.
• You need tenant-level logs or message traces to diagnose delivery or rule scope problems.

If you use a third-party signature platform, update templates there and test template application to outbound mail. Provide the vendor with the hosted-image URLs and final HTML.

How to find-and-replace old-domain links/images in existing signatures

Direct answer: Back up signature files, search for olddomain.com, then run a scripted find-and-replace or update the transport rule. Test with a small pilot first.

Mailbox-level (per-user) updates — Windows desktop approach:

1. Search signature files for olddomain.com in %appdata%\Microsoft\Signatures.

%appdata%\Microsoft\Signatures

2. Back up the signature folder for each user before editing.
3. Run a scripted find-and-replace to update URLs from olddomain.com to newdomain.com in .htm, .rtf, and .txt signature files.
4. Restart Outlook and send a test message.

Server/transport-level updates:

1. Edit the Exchange transport rule HTML and replace olddomain.com with newdomain.com.
2. Test with a small pilot group before changing the entire rule.

Bulk methods and notes:

• For many Windows users, a logon script or MDM policy can push updated signature files into %appdata%\Microsoft\Signatures.
• For Macs, update the signatures folder used by Outlook for Mac or deploy via MDM where supported.
• If you can't edit client files, prefer a transport-rule update and test carefully for duplication (both client and server signatures applied).

Verification checklist and test matrix

Direct answer: Send tests from a user with the new signature to each test mailbox. Check that recipients see updated branding, that message source uses the new URLs, and that no delivery errors appear.

Test matrix (expected results):

• Internal -> Internal: signature appears in the recipient inbox and in sender Sent Items if you used client-side edits.

• Internal -> External (Gmail/Outlook.com): images load and links point to newdomain.com. Plain-text fallback is readable if HTML is blocked.

• Internal -> External corporate Exchange: check the same items and inspect headers for transport-rule indicators.

• Mobile client: signature is readable and not clipped. Images load if the mobile device has network access.

• Text-only client: plain-text fallback is present and contact info legible.

Exact checks to run:

1. Open raw message source in an external mailbox and confirm image URLs use https://newdomain.com and not the old domain.
2. Check message headers for transport-rule stamps such as the transport rule name or a disclaimer header.
3. Confirm signature in Sent Items and in the recipient inbox.
4. Test image loading by viewing the message with images blocked and with images allowed.

Completion criteria — how you know it worked:

• Recipients see the updated branding and links.
• Message source shows newdomain.com URLs.
• No unexpected bounces or delivery errors after the change.

Troubleshooting common failures and escalation checklist

Direct answer: Reproduce failures with a test account, capture raw message source, inspect headers and URLs, and escalate with message traces and raw samples if needed. Roll back if bounces or broken links rise.

Common failures and ordered fixes:

• Images blocked or missing:

1. Verify the CDN or site serving images has a valid HTTPS certificate and allows external fetching.
2. Confirm images are publicly reachable with a browser and with curl from a non-tenant network.

• Old-domain links still appear:

1. Search user signature files and transport-rule HTML for olddomain.com and replace.
2. If many users are affected, deploy a scripted update or request the tenant admin update the transport rule.

• Duplicate signatures appended:

1. Check for both client-side signatures and a server-side transport rule; disable one method.

• Replies/forwards still show old signature:

1. Update the Replies/forwards default in each client or ensure the transport rule targets reply/forward messages as needed.

Diagnosis steps (ordered):

1. Reproduce the problem with a test account and capture the raw message source.
2. Inspect headers for rule application and the message body for correct URLs.
3. If a server-side rule didn't apply, request a message trace from the Exchange admin center and provide the message time and sender/recipient.
4. If DKIM/SPF/DMARC issues appear related, escalate to tenant admin to check DNS records and signing configuration.

Rollback triggers — stop and roll back if you see any of these:

• A sudden increase in bounces or delivery failures.
• Legal/disclaimer text removed or corrupted in outbound mail.
• Mass reports that links or branding are broken.

Escalation checklist — what to supply tenant/global admins:

• Message trace IDs and timestamps.
• Raw message source or a sliced copy showing headers and body.
• Examples of failing image URLs and the curl output or browser screenshot proving inaccessibility.
• Exact transport-rule name and the HTML attached for replacement.

Conclusion

Run the pre-flight checklist, build a simple HTML plus plain-text signature, update each client or your central system, then verify with the test matrix. If something breaks, follow the troubleshooting steps and escalate with raw message sources and message trace IDs.