Can I read the header of a message I sent, instead of asking the recipient?

Not usefully. The verdicts that matter, SPF, DKIM and DMARC results plus any spam annotations, are written by the server that received the message. A copy from your Sent folder never passed through those filters, so it carries none of them. Ask the person who received the failing message to export the full source from their mailbox.

The header says spf=pass and dkim=pass but dmarc=fail. What does that mean?

It means both checks passed for a domain other than the one in the visible From address, which DMARC calls an alignment failure. RFC 7489 requires the DKIM signing domain or the SPF domain to line up with the From domain. This is what happens when a third-party platform sends on your behalf without a sending domain and DKIM key configured under your own domain.

A forwarded message fails SPF. Do I need to change my SPF record?

Usually no. Forwarding sends the message from the forwarder IP while your domain stays in the From address, so SPF fails at the final receiver even when your record is correct. ARC, defined in RFC 8617, exists so an intermediary can record the authentication results it saw before forwarding. If you see ARC headers on the failing message, look at the forwarding path before touching DNS.

How to read email headers when mail goes to spam

Say a 14-person insurance broker calls on a Monday. Two clients swear the renewal notices never arrived, a third found them in junk, and everyone else got theirs. Somebody on their team sends over a screenshot of the message. A screenshot answers nothing. The only artifact that settles this is the raw header of a message that actually failed, taken from the mailbox that received it, not from the sender's Sent folder.

Headers look like noise the first time you open one. They are not. Nearly every case of good mail landing in spam resolves into one of four readings, and each lives in a specific line. This is the order we read them in, and what each line is allowed to prove.

Ask for the right message before you read anything

Most of the wasted hours in a deliverability case come from analysing the wrong artifact. Three rules we apply first:

The header must come from the receiving side. A copy out of the sender's Sent folder has never been through the receiver's filters, so it carries none of the verdicts we need. If the message went to a client at Gmail, we need that client to pull it.
It must be a message that actually failed. Not a test you sent yourself five minutes ago from the same network. A message that landed correctly is a useful control, but it will not explain the failure.
Take the whole thing. People tend to copy the first ten lines. The Received chain, the authentication verdict and the filter's annotations are scattered across the full block, and cutting it short removes the part that matters.

If the message bounced rather than landing in spam, the bounce text outranks the header. That is a different diagnostic path, and Gmail's reputation rejections in particular are covered in our guide to the 550 5.7.1 low reputation rejection.

Getting the raw source out of Gmail, Outlook and Yahoo

Each provider hides this in a different place, and the wording changes more often than the feature does.

Gmail. Open the message, click More next to Reply, and choose Show original. Google's help documents this as tracing an email with its full header, and the window that opens carries the complete source, with a copy button. Do this in Gmail on a computer: the desktop web client is where the full source view lives, so if the person who received the failing message only has a phone, have them open Gmail in a browser or forward the message to someone at a desk.

Outlook and Microsoft 365. Open the message, select More actions, then View, then View message details, which shows the internet message headers. Microsoft's own support page for viewing internet message headers in Outlook describes the header as the list of technical details about a message: who sent it, what composed it, and the mail servers it passed through.

Yahoo Mail. Open the message, open the More options menu and choose View Raw Message. Yahoo's help frames full headers as the way to find a delivery delay or an email's true sender, which is exactly the two jobs we are about to do with them.

Paste the block somewhere with a monospaced font. Line wrapping in a chat window folds a Received line through the middle of an IP address and costs you ten minutes.

The Received chain: where it went, and how long it sat

Read the Received lines from the bottom up. The oldest hop, the one closest to the sender, sits at the bottom, and each server that handled the message stamped a new line on top. Yahoo's help describes the same order: first delivery at the bottom, newest at the top.

Three things we take from the chain:

The real point of origin. The bottom-most hop, together with the envelope sender, is the honest answer to "where did this come from". The From: header is decoration by comparison, because anyone can write anything in it.
Hops that should not be there. A security gateway, a forwarding rule nobody documented, a relay at an old host that was supposed to be decommissioned. Every extra hop is another chance for a signature to break.
Time gaps. A message that took four hours to move between two hops was not filtered as spam, it was queued, and that is a different fix entirely. Google's Admin Toolbox Messageheader renders the hops with the delay at each one, so the slow link is obvious without arithmetic.

Authentication-Results: the line that settles most cases

This is the single most valuable line in the header. The receiving server writes it, in its own words, recording what it concluded about the message. A simplified example of what it looks like on a failing message:

Authentication-Results: mx.receiver-example.com;
       spf=pass smtp.mailfrom=bounces.quoting-platform.example;
       dkim=pass header.d=quoting-platform.example;
       dmarc=fail (p=NONE) header.from=broker-example.com

Read it field by field. spf=pass means the sending IP was authorised by the SPF record of the domain in the envelope sender, which is the smtp.mailfrom value, not necessarily the domain your recipient sees. dkim=pass means a signature verified, and header.d names whose key signed it. dmarc is the verdict that combines the two with the domain in the visible From: address, shown as header.from.

Gmail's help says it in fewer words: look for the Authentication-Results header, and if the message was authenticated you will see spf=pass or dkim=pass. The trap is assuming those two passes end the story.

When SPF and DKIM both pass and DMARC still fails

Look again at the example above. SPF passed. DKIM passed. DMARC failed anyway, and the reason is sitting in plain sight: every passing check belongs to quoting-platform.example, while the address the client actually sees belongs to broker-example.com. That mismatch is an alignment failure, and in our experience it is the most common finding in a header we are handed.

RFC 7489 defines alignment in two modes. In relaxed mode, the organizational domain of the DKIM signing domain, taken from the d= tag, must equal the organizational domain of the From: address, which is what lets subdomains of a verified domain still line up. In strict mode the domains must match exactly.

The practical version: a third-party platform sending on your behalf will pass its own SPF and sign with its own key, and none of that counts for your domain unless you configure the platform to use a sending domain and DKIM key under your own name. Most invoicing tools, CRMs, store platforms and marketing tools support this, under a name like custom sending domain or domain authentication. The record set differs per vendor, which is why we wrote up the exact fix for Mailchimp, HubSpot and Klaviyo.

When DKIM fails outright on mail sent through Google Workspace, the causes are a shorter list, and we walk them in order in the Workspace DKIM guide.

Forwarding and mailing lists: failures that are not your fault

Before you rip up a DNS record, check whether the message was forwarded. When a mailbox auto-forwards, the forwarding server sends from its own IP while the From: domain stays yours, so SPF fails at the final receiver through no error of yours. Mailing lists go further and modify the message, which breaks the DKIM signature as well.

ARC, defined in RFC 8617, exists for this case. An intermediary records the authentication results it observed before it touched anything, in an ARC-Authentication-Results header, signs that snapshot with ARC-Message-Signature and seals the chain with ARC-Seal. If you find ARC headers in a failing message, the story is usually forwarding, not a broken record.

The filter's own annotations

Some receivers show their work. On a message that passed through Microsoft 365 you will find an X-Forefront-Antispam-Report header made of field and value pairs separated by semicolons. Microsoft's documentation on anti-spam message headers explains the ones worth knowing: SCL, the spam confidence level, stamped as -1 or a value from 0 to 9, where 5 or higher generally indicates the message is considered bad; BCL, the bulk complaint level, which flags grey mail, with a higher value meaning more spam-like behaviour; and CAT, the category, which identifies what filtered the message. Microsoft also notes that in cloud organizations the SCL value no longer carries the weight it once did and does not by itself determine the spam verdict, so treat it as a hint. Gmail publishes no equivalent public score in the header: when the receiver is Gmail and the authentication all passes, the next place to look is reputation and volume, not DNS.

Spoofing or misconfiguration

Both produce dmarc=fail, and confusing the two sends you down the wrong road for a day. The header separates them.

Misconfiguration looks like a failure from infrastructure you recognise: your own mail platform, your invoicing tool, the store you know sends order confirmations. The sending host in the bottom Received line is something you pay for. Spoofing looks like a failure from infrastructure you have never heard of, often with a Reply-To that differs from the From:, and it typically arrives in bursts. One is a record to fix. The other is a reason to get your DMARC policy to enforcement, which we lay out step by step in moving DMARC from p=none to p=reject.

What one header cannot tell you

A header is one message, seen by one receiver, at one moment. It cannot tell you what share of your mail fails, which systems send as you across a month, or whether your complaint rate is the real problem. Gmail's sender guidelines set out thresholds that no single header exposes: senders above roughly 5,000 messages a day to personal Gmail accounts are treated as bulk senders, and Gmail asks those senders to keep the spam rate reported in Postmaster Tools below 0.3 percent, with 0.1 percent as the target to aim for.

For the cross-domain view, DMARC aggregate reports are the instrument, not headers. They cover every source at once with a result for each, and we read a few weeks of them before we change any policy. If you have never opened one, start with how to read a DMARC aggregate report. And if the failing check is SPF, confirm the record has not drifted past its ten-lookup budget, which is the subject of the SPF lookup limit guide.

How Guanacos Tech helps

We do this for small and mid-sized companies across North America and Latin America, in English and Spanish: read the headers from the receiving side, name the failing check, trace it to the system that caused it, fix the records, then watch DMARC reports until the picture holds. If you have a message that went to spam, paste its header into the analyzer above, or book a call and we will read it with you. The full engagement is described on our email deliverability page.

How to read email headers to find out why a message went to spam