An authentication code is not a mood

Answer An authentication code is not a mood. RFC 7372 registers enhanced status codes so a receiver can say, in the bounce or the SMTP reply, that an email authentication check failed or otherwise mattered. The code is a short machine report. It is not the reader's feeling, and it is not the percentage of people who hit the spam button.

The note that started this: RFC 7372, Email Authentication Status Codes, RFC 7372.

Sellers narrate bounces the way people narrate weather. They were in a mood. The domain was tired. The copy was too strong. Sometimes the bounce already said the thing, in a code this document helped standardize, and the narration walked past it. If a price is being justified by bounce stories, treat solo ad pricing as a question about evidence. Ask for the status text.

Enhanced status codes are a general system for making reply codes more specific. Authentication is one family of reasons inside that system. This note will not list the numbers. Lists of numbers go stale in a buyer's memory and get applied to the wrong reply. The habit that does not go stale is to read the text that came back with the code and to keep it next to the message it describes.

What is an email authentication status code?

RFC 7372 registers enhanced status codes for email authentication results. A code is a machine's short report about a check. It is not a mood, and it is not a complaint rate.

A check has a subject. The subject might be SPF, or DKIM, or DMARC, or another authentication result the receiver cared about. The code says the check did not come out the way the receiver required, or it classifies the failure so a program can branch. A human still has to connect the code to a fix. The fix might be a DNS record. The fix might be a signature that broke because a relay rewrote a header. The fix is not a new adjective in the subject line until the code says something about content, and these codes are about authentication.

Mood is what a person writes in a chat after a bad morning. It can be useful as a hint. It cannot replace the reply. When the two disagree, keep the reply.

• The bounce is saved with its status text.
• The seller names the check that failed.
• Complaints are counted in a different column.
• The offer is edited only after the check is understood.

Should a buyer treat an authentication code as a complaint?

No. A complaint is a person saying they did not want the mail. An authentication code is a result of a check on the message. Ask which one the seller is quoting.

Both can be bad news. They ask for different work. A failed authentication check asks for a configuration change and a resend of a test. A complaint asks whether the person had a reason to get the mail, and whether the creative kept the promise of the subject. Mixing them produces a seller who rewrites copy to cure a DNS problem, or a seller who changes DNS and leaves a hostile offer in place.

Ask the seller to label the evidence. This row is a bounce code. This row is a feedback report. This row is a guess. You can pay a fair price for a send that includes some bounces. You should not pay a fantasy price for a guess.

What should you do when a bounce mentions authentication?

Ask for the status text and the authentication results on that message. Read them as a failed or passed check. Do not translate the code into a story about the offer until you have seen it.

The authentication results header on a received copy, when you have one, is the receiver's longer account of SPF, DKIM, and DMARC. The status code is the short version in the refusal. Read them together if you can. If the seller will not show either, the mention of authentication in the sales chat is decorative. Decorative technical words are a common wallpaper in this market. Peel one corner up.

RFC 7372 gave authentication failures a place to stand in the status system. Let them stand there. A code is a code. Your offer is your offer. Look at the one the bounce actually named.