What are RFCs and how do they govern email protocols?

Still have a question, spotted an error, or have a better explanation or a source we should cite?

You've probably heard of SPF, DKIM, and DMARC as things you need to set up. But where did those rules come from, and who decided what they mean? That's where RFCs come in.

RFC stands for Request for Comments. It's the official format used to publish internet standards, and yes, the name sounds casual for something that runs the entire internet. An RFC is the written spec that defines exactly how a protocol must behave. When two email servers talk to each other, they both follow the same RFCs, and that's why your Gmail message arrives correctly in Outlook.

The key email RFCs you'll encounter are these:

  • RFC 5321 defines SMTP, the protocol that actually moves email between servers. It governs how servers connect, introduce themselves, hand off messages, and handle errors.
  • RFC 5322 defines email message format. Things like how the From, To, Subject, and Date headers must be structured. If your message doesn't follow this, receiving servers may reject it or display it incorrectly.
  • RFC 7208 defines SPF (Sender Policy Framework). SPF lets you publish a DNS record that says which servers are allowed to send mail from your domain. The receiving server checks that record and confirms your sending IP is on the list.
  • RFC 6376 defines DKIM (DomainKeys Identified Mail). DKIM works differently from SPF. Instead of checking the IP, it attaches a cryptographic signature to the message itself. The receiving server looks up your public key in DNS and verifies the signature hasn't been tampered with in transit.
  • RFC 7489 defines DMARC. DMARC sits on top of SPF and DKIM. It tells receiving servers what to do when those checks fail, quarantine, reject, or do nothing, and it sends you reports so you can see who's sending mail claiming to be from your domain.

SPF and DKIM do different jobs, so you genuinely need both. SPF verifies the sending server. DKIM verifies the message content. If you only have SPF, a forwarder can break your authentication because the forwarding server's IP won't match your SPF record. DKIM survives forwarding because the signature travels with the message.

All three authentication standards affect your deliverability directly. Missing or broken SPF and DKIM will cause receiving servers to distrust your mail. No DMARC means there's no policy protecting your domain from impersonation, and mailbox providers like Gmail and Outlook increasingly use DMARC alignment as a signal when deciding where to place your email.

You can check whether your SPF record is set up correctly with our free SPF checker. If you're not sure where to start with DMARC, our DMARC generator builds the record for you.

Contributors

Who worked on this answer

Every name links to their profile. Every company links to their site. Real people, real accountability.

Ask an AI · tailored to your setup

Check my authentication priorities

I've learned that SPF, DKIM, and DMARC each come from their own RFC and do different jobs. Based on my setup below, can you tell me which of these authentication standards I'm likely missing or misconfigured, and rank what I should fix first for the biggest deliverability impact? My sending domain: your domain Current SPF record (if known): paste or leave blank Current DKIM status: configured yes/no/unknown Current DMARC policy: none/quarantine/reject/unknown ESP I'm sending through: name of platform

Edit the yellow boxes, then send to the AI of your choice.