What this RFC defines
RFC 5518 defines VBR (Vouch By Reference), a mechanism where a trusted third-party voucher certifies that a particular sending domain has a good reputation. The sender publishes a VBR-Info: header in outgoing messages naming the voucher, and the receiving server queries the voucher’s DNS record to verify the endorsement.
Where you see it in practice
VBR was designed to allow trusted certification bodies to vouch for their members’ sending practices. A receiver that trusts a particular voucher can use VBR to whitelist certified senders regardless of their IP reputation. In practice VBR saw very limited adoption compared to DKIM and DMARC, which provide direct cryptographic authentication without relying on third-party vouchers.
How it connects to other RFCs
RFC 5518 works alongside RFC 5321 (SMTP) and RFC 5322 (message format). It is independent of DKIM/SPF/DMARC but overlaps in purpose, attempting to solve the sender reputation problem through third-party certification rather than cryptographic authentication. Its limited adoption means it is rarely encountered in modern deployments.
Current status
RFC 5518 is a current standard, published April 2009. Despite being a published standard, VBR has seen minimal real-world adoption. DKIM and DMARC have become the dominant authentication mechanisms, making VBR largely obsolete in practice even though the RFC remains active.
The Vouch By Reference concept
RFC 5518 defined Vouch By Reference (VBR) in April 2009 as a mechanism for third-party sender reputation. The idea was that mail senders would include a VBR-Info header naming one or more reputation services (vouchers) that had certified them as legitimate, and receivers would query the vouchers via DNS to confirm. If a trusted voucher confirmed the sender, the receiver could use that signal as positive input to filtering decisions. VBR was designed to complement DKIM, providing “not just authentic but also reputable” verification.
Why VBR never scaled
VBR faced two structural problems. First, there was no natural business model for vouchers: certifying senders is expensive (requires ongoing monitoring), but receivers cannot easily be charged for using the service. Second, major mailbox providers (Gmail, Outlook.com, Yahoo) built their own reputation systems that were more accurate than any third-party voucher could be. VBR was implemented by a handful of niche services (Return Path was the most prominent) but never achieved wide deployment. It remains a formally-defined standard with almost no traffic.
Status and modern alternatives
VBR is not deprecated but is effectively dormant. Modern equivalents include the BIMI (Brand Indicators for Message Identification) framework, which allows verified senders to display a logo in the recipient inbox, and industry-specific reputation networks operated by security vendors. If you encounter VBR-Info headers in mail archives, they are historical artifacts. New implementations should not add VBR support unless integrating with a specific legacy voucher service.
RFC 5518 (April 2009) defines VBR (Vouch By Reference): a reputation vouching system where third-party services attest to a sending domain’s trustworthiness. The sender embeds a VBR-Info header naming vouchers; the receiver queries the voucher via DNS to confirm the sender is endorsed. Early attempt at solving reputation problems that DKIM+DMARC+ARC ultimately addressed differently. Never widely deployed; ecosystem moved to reputation-tracking services (Sender Score, Google Postmaster, Cisco Talos) that operate outside the mail path rather than in-band vouchers.
RFC 5518 at a glance
| Aspect | Detail |
|---|---|
| Purpose | Third-party in-band vouching for sender trustworthiness |
| Header | VBR-Info naming vouching parties and message type |
| Verification | DNS lookup at voucher’s zone confirms endorsement |
| Status | Standardized but never widely adopted |
| Modern alternative | Out-of-band reputation services (Sender Score, Postmaster Tools) |
| Published | April 2009 |
VBR mechanism
Common mistakes when discussing VBR
Related standards and further reading
- DMARC Record Guide: policy-based reputation gateway
- DKIM Record Guide: cryptographic authentication
Frequently asked questions
Should I deploy VBR for my mail?
No. VBR was never widely adopted; receivers do not honor it in practice. Modern reputation management uses out-of-band services (Google Postmaster Tools, Microsoft SNDS, Sender Score, Cisco Talos) rather than in-band vouchers. Focus deliverability efforts on SPF/DKIM/DMARC/ARC and reputation monitoring via these services.
Why did VBR not succeed?
Several factors. First, vouchers need business models; who runs the voucher zone and profits? Second, receivers face trust decisions about which vouchers to honor; ecosystem coordination was difficult. Third, reputation quality assessment happens outside the mail path anyway (behavioral analysis, engagement data); putting it in-band offered no additional data. Fourth, DMARC + ARC + reputation services satisfied the need without VBR. If you encounter VBR-Info headers in mail archives, they are historical artifacts.
Is there a modern equivalent to VBR?
Reputation tracking services perform a similar role but out-of-band. Google Postmaster Tools reports sender reputation for Gmail. Microsoft SNDS reports for Outlook/Hotmail. Sender Score is a third-party industry service. These services assess senders based on behavior (complaint rates, engagement, spam trap hits) rather than voucher endorsements. Modern deliverability practice uses these services for reputation management.
Does removing VBR-Info from my templates hurt?
No. Modern receivers do not act on VBR-Info. Removing it eliminates useless header overhead. If your ESP or MTA has an option to disable VBR, disable it. If VBR-Info appears in templates, remove the header emission.
Where can I read about modern deliverability practice?
Reference the modern authentication triad (SPF, DKIM, DMARC), the ARC extension for mailing list handling, and reputation-service documentation from Google (Postmaster Tools), Microsoft (SNDS, JMRP), and industry reports from services like Sender Score. Also, gmail.com/postmaster and postmaster.microsoft.com host detailed guidance from the major providers.
About the Author
Alaa · LinkedIn
Email infrastructure specialist with 8+ years of hands-on experience in SMTP, deliverability, and email verification. I’ve configured and troubleshot mail systems across Postfix, Exchange, and cloud relays, managed IP reputation and warmup campaigns, and built verification pipelines processing millions of addresses. My work spans DNS authentication (SPF, DKIM, DMARC, BIMI), bounce handling, blocklist monitoring, and compliance frameworks including CAN-SPAM and GDPR. I write every article on SMTPedia to give email professionals, developers, and marketers the accurate, RFC-grounded reference they need.
About SMTPedia
SMTPedia is an independent email industry reference covering SMTP, IMAP, POP3, email deliverability, marketing platforms, DNS authentication, and email verification. Every article is researched from official provider documentation, IETF RFCs, and industry best practices. Settings and configurations are verified quarterly.
We are cited as a source by ChatGPT, Microsoft Copilot, and thousands of email professionals worldwide. Learn more about our editorial process.
