Do not cite the old authentication header spec

Answer RFC 7601 is the older specification for the Authentication-Results header. A later document replaced it. A pasted header that a blog explains with the old text is not the current specification. Read the header in front of you as one receiver's note, and do not let a seller cite the retired writeup as if it were this year's rule.

The note that started this: RFC 7601, Authentication-Results Header Field, RFC 7601.

The header itself is useful. It is also easy to fake in a screenshot and easy to over-read. Safe solo ads sellers show you a result from a mailbox you can name. They do not send you a cropped image from a tutorial and call it the audit of your drop.

RFC 7601, from 2015, described a header field that receiving systems add after they evaluate a message. The field records what that system concluded about authentication methods it ran. The Internet Engineering Task Force later published a replacement for that specification. If a seller's help article still walks through the old RFC number as the living standard, the article is stale. You can say that without pretending the header stopped existing. The header is still the idea. The document number they are quoting is the part that aged out.

What did RFC 7601 define?

It defined the Authentication-Results header, a field a receiver adds to record authentication results. A later specification replaced it. The old document is not the current one.

Replaced does not mean the old paper was never true. It means you should not debug today's mail with yesterday's page numbers if a current page exists. On a sales call this shows up as confidence. The seller knows a header name. They quote a blog that quotes 7601. The blog has not been edited since the replacement. You are now three copies away from the specification, and the first copy is the one that was retired.

You do not have to recite the newer number to win the point. Ask them to open the header on a message you received this week and read the method, the domain, and the result. The bytes in that header are the evidence. The blog is commentary. Commentary that names a replaced document is commentary to set aside.

• The message is one you received, or one the seller received in your presence.
• The header names a receiving system.
• The result names a method and a domain.
• A tutorial screenshot is not accepted as the test.

Who adds the Authentication-Results header?

The receiver adds it, not the sender. A seller cannot honestly paste a result they invented. The field describes what that receiving system decided.

This is the fact that makes the header worth reading and also the fact that limits it. Your Gmail account and the seller's Yahoo test address are different receivers. They can disagree. A pass at one and a missing header at the other does not mean the second receiver failed. It may mean that receiver did not add the field, or added it where your view is hiding it. Ask for the full header, which is a later note this month. Today, remember the author of the field. The sender does not get to grade their own homework inside this header.

A forged header is possible in a message the sender composed, which is why verifiers are supposed to handle existing fields with care. You are not the verifier. You are the buyer. Your defense is to look at a header added by a mailbox you control, on a test sent to you, rather than a header the seller exported from a tool and pasted under their logo.

How should a buyer treat a screenshot of authentication results?

Treat it as one receiver's note about one message. Check the date, the receiving host, and the domain. Do not treat a blog's old explanation of RFC 7601 as the live specification.

Check three things before you let the screenshot near the invoice. The date is recent. The host that added the header is a real receiver, not the sending platform congratulating itself. The domain in the result is the domain on the quote. If any of the three is missing, the screenshot is decoration.

Then close the old tab. RFC 7601 explained the idea in its year. Citing it in July 2026 as the current specification is a tell. The tell is not that the seller is a villain. The tell is that the seller's documentation has not been read since the document was replaced. Hire the shop that can read a header from this week.