RFC 5322 laid down email security specifications for Sender Policy Framework 

Compliance is driving a lot of the DMARC adoption we see, says Vasile Diaconu, Operations Lead at DuoCircle. PCI DSS v4.0, Google’s sender requirements, Microsoft’s May 2025 enforcement — our support team fields questions about these mandates daily. The organizations that moved early are already at p=reject. The rest are scrambling.

The three core email authentication standards — SPF (RFC 7208), DKIM (RFC 6376), and DMARC (RFC 7489) — work together to verify that an email genuinely originates from the domain it claims to represent. Since February 2024, Google and Yahoo require all three for bulk senders. DMARC Report

RFC 5322 laid down email security specifications for Sender Policy Framework 

					<button title="Play" aria-label="Play Episode" aria-pressed="false" class="play-btn">
						

Play Episode

					</button>
					<button title="Pause" aria-label="Pause Episode" aria-pressed="false" class="pause-btn hide">
						

Pause Episode

					</button>
					


				

				

					<audio preload="none" class="clip clip-20895">
						<source src="/images/wp/2025/02/RFC-5322-laid-down-email-security-specifications-for-Sender-Policy-Framework.mp3">
					</audio>
					

						

					

					

						

							<button class="player-btn player-btn__volume" title="Mute/Unmute">
								

Mute/Unmute Episode

							</button>
							<button data-skip="-10" class="player-btn player-btn__rwd" title="Rewind 10 seconds">
								

Rewind 10 Seconds

							</button>
							<button data-speed="1" class="player-btn player-btn__speed" title="Playback Speed" aria-label="Playback Speed">1x</button>
							<button data-skip="30" class="player-btn player-btn__fwd" title="Fast Forward 30 seconds">
								

Fast Forward 30 seconds

							</button>
						

						

							<time class="ssp-timer">00:00</time>
							

/

							<!-- We need actual duration here from the server -->
							<time class="ssp-duration" datetime="PT0H2M10S">2:10</time>
						

					

				

			

								<nav class="player-panels-nav">
												<button class="subscribe-btn" id="subscribe-btn-20895" title="Subscribe">Subscribe</button>
																		<button class="share-btn" id="share-btn-20895" title="Share">Share</button>
										</nav>
						

	



		

						

				

					

					

				

				

					

																																																																								

					

						

RSS Feed

							<input value="https://dmarcreport.com/feed/podcast/dmarc-report" class="input-rss input-rss-20895" title="RSS Feed URL" readonly />
						

						<button class="copy-rss copy-rss-20895" title="Copy RSS Feed URL" aria-label="Copy RSS Feed URL"></button>
					

				

			

									

				

					

					

				

				

					

						Share						

					

						<a href="https://www.facebook.com/sharer/sharer.php?u=https://dmarcreport.com/blog/podcast/rfc-5322-laid-down-email-security-specifications-for-sender-policy-framework/&t=RFC 5322 laid down email security specifications for Sender Policy Framework " target="blank" rel="noopener noreferrer" class="share-icon facebook" title="Share on Facebook">
							

						</a>
						<a href="https://twitter.com/intent/tweet?text=https://dmarcreport.com/blog/podcast/rfc-5322-laid-down-email-security-specifications-for-sender-policy-framework/&url=RFC 5322 laid down email security specifications for Sender Policy Framework " target="blank" rel="noopener noreferrer" class="share-icon twitter" title="Share on Twitter">
							

						</a>
						<a href="/images/wp/2025/02/RFC-5322-laid-down-email-security-specifications-for-Sender-Policy-Framework.mp3" target="blank" rel="noopener noreferrer" class="share-icon download" title="Download" download>
							

						</a>
					

				

				

					

						Link						

					

						<input value="https://dmarcreport.com/blog/podcast/rfc-5322-laid-down-email-security-specifications-for-sender-policy-framework/" class="input-link input-link-20895" title="Episode URL" readonly />
					

					<button class="copy-link copy-link-20895" title="Copy Episode URL" aria-label="Copy Episode URL" readonly=""></button>
				

				

					

						Embed						

					

						<input type="text" value='<blockquote class="wp-embedded-content" data-secret="OF8mlQqN3H"><a href="https://dmarcreport.com/blog/podcast/rfc-5322-laid-down-email-security-specifications-for-sender-policy-framework/">RFC 5322 laid down email security specifications for Sender Policy Framework </a></blockquote><iframe sandbox="allow-scripts" security="restricted" src="https://dmarcreport.com/blog/podcast/rfc-5322-laid-down-email-security-specifications-for-sender-policy-framework/embed/#?secret=OF8mlQqN3H" width="500" height="350" title=""RFC 5322 laid down email security specifications for Sender Policy Framework " — DMARC Report" data-secret="OF8mlQqN3H" frameborder="0" marginwidth="0" marginheight="0" scrolling="no" class="wp-embedded-content"></iframe><script>

/*! This file is auto-generated / !function(d,l){“use strict”;l.querySelector&&d.addEventListener&&“undefined”!=typeof URL&&(d.wp=d.wp||{},d.wp.receiveEmbedMessage||(d.wp.receiveEmbedMessage=function(e){var t=e.data;if((t||t.secret||t.message||t.value)&&!/[^a-zA-Z0-9]/.test(t.secret)){for(var s,r,n,a=l.querySelectorAll(‘iframe[data-secret=”‘+t.secret+’”]’),o=l.querySelectorAll(‘blockquote[data-secret=”‘+t.secret+’”]’),c=new RegExp(“^https?:$”,“i”),i=0;i<o.length;i++)o[i].style.display=“none”;for(i=0;i<a.length;i++)s=a[i],e.source===s.contentWindow&&(s.removeAttribute(“style”),“height”===t.message?(1e3<(r=parseInt(t.value,10))?r=1e3:~~r<200&&(r=200),s.height=r):“link”===t.message&&(r=new URL(s.getAttribute(“src”)),n=new URL(t.value),c.test(n.protocol))&&n.host===r.host&&l.activeElement===s&&(d.top.location.href=t.value))}},d.addEventListener(“message”,d.wp.receiveEmbedMessage,!1),l.addEventListener(“DOMContentLoaded”,function(){for(var e,t,s=l.querySelectorAll(“iframe.wp-embedded-content”),r=0;r<s.length;r++)(t=(e=s[r]).getAttribute(“data-secret”))||(t=Math.random().toString(36).substring(2,12),e.src+=”#?secret=“+t,e.setAttribute(“data-secret”,t)),e.contentWindow.postMessage({message:“ready”,secret:t},"")},!1)))}(window,document); //# sourceURL=https://dmarcreport.com/wp-includes/js/wp-embed.min.js ’ title=“Embed Code” class=“input-embed input-embed-20895” readonly/>

					<button class="copy-embed copy-embed-20895" title="Copy Embed Code" aria-label="Copy Embed Code"></button>
				

			

				

RFC 5322 defines the syntax for Internet email headers. SPF, DKIM, and DMARC rely on these headers to authenticate emails and prevent phishing. Published in October 2008 as an update to RFC 2822, RFC 5322 is widely used for formatting email headers and bodies.

RFC 5322 doesn’t say anything about how SPF should be set up. However, since SPF works in conjunction with the email headers defined in **RFC 5322 **(particularly MAIL FROM and Return-path), it’s important to consider it.

While SPF is only responsible for verifying whether an authorized sender has sent the email, it’s based on a complicated structure that requires interaction with the email headers defined in RFC 5322. This blog attempts to **explain these structures in an easier manner.

How does SPF function?

SPF uses DNS TXT records in which the domain owner mentions all the approved mail servers that can be used to send emails on behalf of the brand. When a recipient’s mail server gets an email from your domain, it retrieves the **SPF record corresponding to the sender’s domain to determine whether the sending server is authorized.

If the sending server’s **IP matches an entry in the SPF record, the email passes SPF authentication . However, if the sending server’s IP is not listed in the SPF record:

• The email is rejected if -all is used.

• The email is marked as suspicious but still delivered if ~all is used.

• No action is taken if ?all is used.

The **receiving mail server logs the SPF result and may use it along with other factors (such as DKIM and DMARC) to decide whether to accept, reject, or mark the email as spam.

SPF and RFC 5322 headers

The MAIL FROM address of an email is also called the SMTP address. This address is recorded in the Return-Path header of the final email. On the other hand, the From field is the address that’s visible to the receiver when they get your email.

When both these addresses aren’t the same, a vulnerability arises that allows threat actors to take advantage and send phishing emails on your behalf. Usually, recipients don’t notice this mismatch in the **MAIL FROM and From fields and get duped.

For example, SPF may authenticate the MAIL FROM address email1@example.com while the recipient sees the From header as email2@example.com. If there is no additional protocol like DKIM and DMARC to ensure alignment, cybercriminals can exploit this mismatch and send potentially fraudulent emails in the name of your business.

Return-path header

The receiving server adds the Return-path header that includes the MAIL FROM address. When the email is received, the receiving server checks this address to verify if the message has been sent from an authorized server. If the sending server’s IP is not listed in the domain’s SPF record, the check fails. Depending on the SPF settings, the email may be marked as suspicious (Softfail) or rejected (Hardfail).

Pair SPF with DKIM and DMARC

SPF alone is not enough. It has limitations like-

• It only checks the MAIL FROM and not the From header.

• It breaks with email forwarding.

• It is limited to 10 DNS lookups.

• It can’t validate email content or message integrity.

If you pair SPF with DKIM and DMARC, the shortcomings are compensated. DKIM helps verify whether the email content was altered in transit, while **DMARC ascertains alignment between the MAIL FROM and From headers.

Sources

• RFC 7208 — Sender Policy Framework (SPF)
• RFC 7489 — Domain-based Message Authentication, Reporting, and Conformance (DMARC)