Skip to main content

Removing Auto-Linked Blue Text in Outlook and iOS Mail

Stop clients auto-linking phone numbers, dates and addresses into blue underlined text: the x-apple-data-detectors override, MSO link colour, and the wrapper technique.

A carefully styled order confirmation arrives with the order number, the delivery date and the support phone number rendered as blue underlined links you never wrote. This guide covers which clients do that, why overriding it needs more than a colour declaration, and the wrapper technique that works everywhere.

Root Cause: Clients Scan Text and Insert Their Own Anchors

Several clients run a data-detection pass over the message body, looking for strings that resemble phone numbers, dates, times, addresses and tracking numbers. When they find one they wrap it in their own anchor element and apply their own styling — typically blue and underlined on iOS, and the system link colour in Outlook.

Two properties of this make it hard to override. The client injects the anchor after your CSS has been applied, so a rule targeting a in your style block may not reach an element that did not exist when the block was evaluated. And the injected element carries platform-specific attributes rather than a class you can target, so a generic selector does not match it.

The practical consequence is that the text is not only the wrong colour — it is interactive. A delivery date becomes a link that opens a calendar, and an order number that happens to look like a phone number becomes a dial prompt. On a transactional message, that is a usability failure as much as a visual one.

Auto-detected string types by client iOS Mail detects dates, times, phone numbers and addresses, Outlook applies its own link colour, and Android clients detect phone numbers and addresses. Text You Wrote, Links You Did Not iOS Mail, Apple Mail dates, times, addresses phone and tracking numbers Injects an anchor with its own data-detector attributes. Outlook 2016-2021 your own anchors, recoloured system link colour wins Overrides your colour on links that you did write. Android clients phone numbers postal addresses Behaviour varies by app and device manufacturer.
Two different mechanisms produce the same symptom: injected anchors on Apple and Android, and colour override on Outlook's own links.

The Exact Fix

Three layers, because the mechanisms differ.

<style>
  /* Layer 1 — Apple's data detectors. The injected anchor carries the
     x-apple-data-detectors attribute, which is the only reliable hook.
     Colour must be !important AND inherit, because the client's own rule
     is applied to the element it created. */
  a[x-apple-data-detectors] {
    color: inherit !important;
    text-decoration: none !important;
    font-size: inherit !important;
    font-family: inherit !important;
    font-weight: inherit !important;
    line-height: inherit !important;
  }

  /* Layer 2 — Android and Samsung wrap detected strings in a span with a
     class the client generates. Targeting the anchor inside the wrapper
     covers the variants. */
  .unstyle-auto-detected-links a,
  .aBn { border-bottom: 0 !important; text-decoration: none !important; }
  .aBn { color: inherit !important; }
</style>

<!--[if mso]>
<style>
  /* Layer 3 — the Word engine applies the system link colour to your own
     anchors, ignoring the inline colour. A conditional rule reclaims it.
     Affects Outlook 2016, 2019 and 2021 on Windows. -->
  a { color: #a53860 !important; text-decoration: underline !important; }
  span.MsoHyperlink { color: #a53860 !important; mso-style-priority: 99 !important; }
  span.MsoHyperlinkFollowed { color: #a53860 !important; mso-style-priority: 99 !important; }
</style>
<![endif]-->

The MsoHyperlink and MsoHyperlinkFollowed rules are the ones people miss. Outlook applies those classes to link text independently of the anchor's own styling, so overriding a alone leaves a visited link rendering in the system purple. Both classes need mso-style-priority: 99 to outrank the built-in style.

The Wrapper Technique for Stubborn Strings

Where the override is not enough — and the awkward cases are dates and tracking numbers — the reliable approach is to make the string undetectable by breaking it up with a zero-impact element.

<!-- Splitting the string with an empty span defeats the pattern matcher
     without changing what the reader sees or what a screen reader reads.
     Use sparingly: it is a last resort, not a default. -->
<span style="color:#334155;">Arriving <span></span>Friday <span></span>14 August</span>

<!-- For a phone number that must stay tappable, do it deliberately instead:
     write the anchor yourself so you control the colour and the target. -->
<a href="tel:+441234567890"
   style="color:#a53860;text-decoration:underline;">+44 1234 567890</a>

Writing the anchor yourself is the better answer whenever the string genuinely should be actionable. A phone number in a support footer should be tappable on a phone; what you want is control over its appearance, not the removal of its behaviour. Suppressing the detector and then providing your own anchor gives both.

Choosing a response by intent Suppress styling for strings that should not be links, author your own anchor for those that should, and break the pattern only where suppression fails. Decide by What the String Is For should not be a link order number, date suppress with the CSS layers covers most cases should be a link support phone number author the anchor yourself you control colour and target suppression failed tracking number break the pattern last resort — keep it rare
Suppression and authoring your own anchor cover almost everything; pattern-breaking is reserved for the strings that resist both.

Variant: Dark Mode Makes It Worse

In dark mode the injected link colour is chosen by the client against its own background, not yours, so a detected string can render in a blue that has poor contrast against the dark surface you specified. The suppression rules above use color: inherit, which is what makes them work in both schemes — a hard-coded override colour would need a dark variant of its own and would still leave the client's underline.

This is one of the cases where inherit is genuinely better than a specific value. The surrounding text already has a correct colour for the active scheme, so inheriting it is correct by construction in both.

Which Strings Are Worth Protecting

Not every detected string is a problem, and applying pattern-breaking everywhere costs readability for no gain. Three categories are worth deliberate attention.

Order and reference numbers are the highest priority, because they are the strings most likely to be misdetected as something else. A twelve-digit order number can match a phone-number pattern, and a reference formatted as 2026-08-14-0042 matches a date. In both cases the client turns a piece of reference data into an interactive element that does something unrelated to the message, which is confusing rather than merely ugly.

Delivery and expiry dates are the most visually disruptive, because they appear in body copy where a sudden blue underline breaks the reading line. They are also the strings customers read most carefully, so a rendering artefact there attracts disproportionate attention. Suppression is almost always sufficient; pattern-breaking is rarely needed.

Monetary amounts and quantities are usually safe and need no intervention. They are not detected as anything by mainstream clients, and adding defensive markup around them is effort spent on a problem that does not exist.

The prioritisation matters because the CSS suppression is free and global while pattern-breaking is manual and per-string. Applying the first everywhere and the second only to the first category keeps the template readable and the effort bounded. A useful heuristic: if the string is a number a human would never dial, write or look up on a map, it needs protecting; if it is prose, it does not.

Protection needed by string category Reference numbers need the most protection, dates need suppression only, and monetary amounts need none. Protect the Numbers Nobody Would Dial reference numbers suppress + break pattern Misdetected as phone numbers or dates. dates and times suppress only Visually disruptive in the middle of body copy. amounts, quantities no action needed Not detected by any mainstream client.
Global suppression is free; pattern-breaking is manual, so it belongs only on the strings that resist suppression.

Pipeline Integration

Put all three layers in the shared layout rather than per template. They are message-independent, they cost nothing when no string is detected, and their absence is invisible until a specific customer's order number happens to match a pattern — which makes it exactly the kind of fix that should not depend on anyone remembering it.

Add the check to your rendering QA pass: send a fixture containing a date, a time, a phone-shaped number and a postal address, and confirm none of them render as links. That fixture is worth keeping permanently, because the detectors' patterns change between platform releases and a template that was clean last year may not be now.

Validation and Deployment Checklist

Frequently Asked Questions

Why does color: #334155 !important on the anchor not work?

Because on Apple platforms the client's own stylesheet is applied to the element it injected, and it competes at a level your author styles do not reliably outrank. Targeting the x-apple-data-detectors attribute matches the injected element specifically, and inherit avoids fighting over a value at all by taking whatever the parent already resolved to.

Can data detection be disabled entirely?

There is a format-detection meta tag that some platforms historically honoured, but support is inconsistent and it is not reliable in current clients. The CSS suppression is the approach that works, and it has the advantage of degrading gracefully — where a client ignores it, the text is still readable, just styled by the client.

Does this affect the plain-text part?

The plain-text part is not styled, so there is no colour problem, but detection still happens — a phone number in plain text is still tappable on a phone. That is generally desirable there and there is no mechanism to prevent it, so it needs no action.

Usually yes, but yours rather than the client's. A tracking number auto-detected by the client links to whatever the platform guesses; an anchor you author links to your own order-status page, where you control what the customer sees. That is a better experience and it removes the styling problem at the same time.

← Back to Outlook Rendering Fixes