#rfc 6068 #mailto #email #standards #ietf

RFC 6068: The Complete Guide to the Mailto URI Scheme Standard

MailtoMaker Team

Verified Compatibility

Gmail Outlook Apple Mail Thunderbird

RFC 6068: The Complete Guide to the Mailto URI Scheme Standard

If you’ve ever wondered what rules govern mailto links, the answer lies in RFC 6068. This document, published by the Internet Engineering Task Force (IETF), is the official specification that defines how email links work on the web.

In this guide, we’ll break down RFC 6068 in plain English, explaining what it allows, what it prohibits, and how to create compliant mailto links.


What is RFC 6068?

RFC 6068 is an Internet Standard published in October 2010. It formally defines the mailto: URI scheme—the protocol that allows web pages to create clickable links that open email clients.

SpecificationDetails
Full TitleThe ‘mailto’ URI Scheme
AuthorsM. Duerst, L. Masinter, J. Zawinski
StatusProposed Standard
ObsoletesRFC 2368
PublishedOctober 2010
Official LinkRFC 6068

The History of Mailto Standards

The mailto scheme has evolved over time:

EraStandardKey Changes
1998RFC 2368Original mailto specification
2010RFC 6068Current standard; added IRI support, security considerations

RFC 6068 was created to address ambiguities in the original specification and to improve internationalization support.


RFC 6068 Structure Breakdown

1. Basic Syntax

The basic structure of a mailto URI is:

mailto:addr-spec?header=value&header2=value2

Components:

  • mailto: — The URI scheme (required)
  • addr-spec — One or more email addresses (comma-separated)
  • ? — Delimiter before query parameters
  • header=value — Key-value pairs for email headers

2. Allowed Headers

RFC 6068 explicitly defines which email headers can be included:

HeaderDescriptionExample
toAdditional recipients[email protected]
ccCarbon copy[email protected]
bccBlind carbon copy[email protected]
subjectEmail subject line?subject=Hello%20World
bodyPre-filled message content?body=Hi%20there
in-reply-toMessage-ID for threading?in-reply-to=<msg-id>
keywordsKeywords for the message?keywords=urgent

3. Prohibited Headers

For security reasons, RFC 6068 prohibits certain headers:

HeaderReason for Prohibition
fromCould be used for spoofing
dateShould be set by the email client
receivedInternal routing header
content-typeCould inject malicious content
content-transfer-encodingInternal encoding header
Any X- headerUnpredictable behavior

4. No Attachment Support

Critical: RFC 6068 does not support file attachments.

“The ‘mailto’ URI scheme is designed for simple message composition… It does not provide a mechanism for including attachments.”

This is a security feature. If mailto links could attach files, malicious websites could:

  • Distribute malware
  • Exfiltrate local files
  • Bypass security scanners

Learn more: Why Mailto Links Cannot Have Attachments


Character Encoding

RFC 6068 requires proper URL encoding (percent-encoding) for special characters:

CharacterEncodedMust Encode?
Space%20Yes
Line break%0AYes
Tab%09Yes
&%26Yes (in body text)
=%3DYes (in body text)
?%3FYes (in body text)
#%23Yes
@%40No (in addresses)
,,No (between addresses)

Example: Properly Encoded Mailto

<a href="mailto:[email protected]?subject=Bug%20Report%3A%20Login%20Issue&body=Steps%20to%20reproduce%3A%0A1.%20Go%20to%20login%20page%0A2.%20Enter%20credentials%0A3.%20Click%20submit">
  Report Bug
</a>

Security Considerations

RFC 6068 Section 4 addresses security:

1. Header Injection

Attackers cannot inject arbitrary headers because:

  • Only allowed headers are processed
  • Values are URL-decoded, not executed

2. Phishing Prevention

Email clients should:

  • Display the recipient address before sending
  • Not automatically send emails from mailto links
  • Allow users to edit the pre-filled content

3. User Awareness

The specification recommends that:

  • Users should always review the email before sending
  • Email clients should clearly show all recipients
  • BCC recipients should be visible to the sender

Internationalization (IRI Support)

RFC 6068 supports Internationalized Resource Identifiers (IRIs), allowing non-ASCII characters:

<!-- Unicode characters in email addresses -->
<a href="mailto:用户@例子.中国">联系我们</a>

However, for maximum compatibility, ASCII encoding is recommended:

<!-- Percent-encoded version -->
<a href="mailto:%E7%94%A8%E6%88%B7@%E4%BE%8B%E5%AD%90.%E4%B8%AD%E5%9B%BD">联系我们</a>

Real-World Implementation

Compliant Example

<a href="mailto:[email protected],[email protected][email protected]&[email protected]&subject=Partnership%20Inquiry&body=Hello%2C%0A%0AI%20am%20interested%20in%20discussing%20a%20partnership.%0A%0ABest%20regards">
  Contact Us
</a>

This is RFC 6068 compliant because:

  • ✅ Uses allowed headers only (cc, bcc, subject, body)
  • ✅ Properly percent-encodes special characters
  • ✅ Multiple recipients separated by commas
  • ✅ No prohibited headers

Non-Compliant Examples

<!-- ❌ Trying to set 'from' (prohibited) -->
<a href="mailto:[email protected][email protected]">Click Me</a>

<!-- ❌ Trying to attach a file (not supported) -->
<a href="mailto:[email protected]?attach=/path/to/file.pdf">Send Resume</a>

<!-- ❌ Content-type injection attempt (prohibited) -->
<a href="mailto:[email protected]?content-type=text/html">Send HTML</a>

Email Client Compliance

How well do popular email clients follow RFC 6068?

ClienttoccbccsubjectbodyNotes
Gmail (Web)Full compliance
Outlook (Desktop)2000 char limit
Apple MailFull compliance
ThunderbirdFull compliance
Yahoo Mail⚠️BCC sometimes ignored

Tools for RFC 6068 Compliance

Creating compliant mailto links manually is error-prone. Use our tools:

  • ✅ Automatic percent-encoding
  • ✅ Character counter (for Outlook limit)
  • ✅ Validates against RFC 6068
  • ✅ Generates QR codes

Summary

TopicRFC 6068 Position
Allowed headersto, cc, bcc, subject, body, in-reply-to, keywords
Prohibited headersfrom, date, content-type, X-headers
AttachmentsNot supported
EncodingPercent-encoding required
IRI supportYes (internationalized addresses)
SecurityUser must review before sending


Last Updated: December 2025

Have feedback? We'd love to hear it!