Who maintains RFCs?

Two organizations do the work: the IETF writes the specs, and the RFC Editor publishes and preserves them. They are separate on purpose. One builds consensus, the other keeps the record.

The IETF (Internet Engineering Task Force) is where the technical fights happen. It is not a company or a government body. It is a volunteer-driven standards organization that runs on rough consensus and running code, which is their actual motto and not a joke. Engineers from Google, Microsoft, Yahoo, Cisco, universities, mailbox providers, and one-person shops all show up in the same working groups. If you want to know who shapes the rules for SMTP, DKIM, DMARC, and SPF, that is the room. For more on the wider cast, see What are IETF, M3AAWG, and CSA? and What organizations shape global email practices?.

The RFC Editor is the publishing arm. They handle the final editorial pass, assign the RFC number, archive the document, and never change it again. That last part matters. Once RFC 5321 is published, RFC 5321 is frozen. If the spec needs to change, a new RFC gets issued and the old one is marked obsoleted by the new number. That is why you sometimes see RFC 5321 referenced for SMTP today, because it obsoleted RFC 2821, which obsoleted RFC 821 from 1982. The trail is intentional.

Under the IETF umbrella sit a few moving parts you should know if you care about deliverability politics:

• Working Groups do the drafting. For email, the relevant ones over the years include DMARC, DKIM, EAI, and the older MARID group. Each WG has a charter, a mailing list, and meetings three times a year.
• The IESG (Internet Engineering Steering Group) approves documents for publication once a working group reaches consensus.
• The IAB (Internet Architecture Board) handles longer-term architectural direction.
• The IRTF runs research-side work that is not yet ready for standardization.

RFCs do not all carry the same weight. The track tells you how serious the document is:

• Standards Track (Proposed Standard, Internet Standard) is the real deal. DMARC, DKIM, SPF, and SMTP all sit here.
• Informational describes something without endorsing it as a standard. Useful, not binding.
• Experimental is a trial balloon. Some experimental RFCs eventually graduate, many do not.
• Best Current Practice (BCP) captures operational guidance that the community agrees on but is not a protocol spec.
• Historic means obsoleted or abandoned.

Can you participate? Yes, and that is not a marketing line. Anyone can join an IETF mailing list, file an Internet-Draft (the document format that becomes an RFC if it survives the process), and show up to meetings. There are no membership fees for individual contributors. What you do need is enough technical depth to defend your draft against people who have been doing this for decades, and the patience to absorb a lot of disagreement on a mailing list. Most drafts die. The ones that survive get sharpened by that process.

For email operators, the practical takeaway is this. When a vendor or a blog tells you something is "the standard," go find the RFC number. Read the abstract and the security considerations section. If it is on Standards Track and not marked obsoleted, you are looking at the actual rule. If it is Informational or a vendor blog post citing a draft, you are looking at an opinion. The distinction matters when you are arguing with a deliverability problem at 2am.

If you want to see how this plays out in practice, look at how DMARC went from a private industry spec (originally published by a coalition led by PayPal, Google, Yahoo, and Microsoft in 2012) to RFC 7489 as Informational in 2015, then to the current DMARCbis work moving it toward full Standards Track. That arc, private spec to community standard, is the typical path for email protocols. For the bigger picture on how documents move through that pipeline, see How do RFCs evolve and become deprecated?.