MYTHOSAI

Email and domains / PRACTICAL GUIDE

Read an email authentication result without overtrusting it

Use trusted message headers to understand SPF, DKIM and DMARC while still checking the request.

Before you start

A received message in your own mailbox and access to its original headers.

Separate delivery evidence from trust

An authentication result describes how a receiving mail system evaluated a message. It does not say that the sender is honest or that an attachment is safe. A criminal can send authenticated mail from a domain they own, and a compromised legitimate mailbox can also send messages that pass checks.

Use a harmless message already in your mailbox. Full headers can expose addresses and routing details, so keep them private and sanitise any troubleshooting extract.

Inspect the receiver's evidence

  1. Open the provider's original-message or full-header view. In Gmail, the message menu offers Show original. Other applications use different labels; consult their current help.
  2. Identify the authentication summary supplied by your receiving provider. Arbitrary header text inside a message can be forged, so do not trust a line merely because it contains Authentication-Results.
  3. Note the SPF, DKIM and DMARC outcomes that are actually displayed. Compare the visible From domain with the authenticated domains instead of assuming that a pass in one field covers all identities.
  4. Assess the requested action independently. For a payment change or credential request, verify through a known separate channel even if authentication passed.

Make a useful interpretation

SPF concerns authorised sending infrastructure for an envelope identity. DKIM verifies a signature associated with a signing domain. DMARC evaluates alignment with the visible From domain and the domain's policy. These are related checks with different questions, not three interchangeable safety ratings.

A failure needs context. Forwarding, mailing-list changes and configuration errors can complicate delivery. Record the specific result and ask the mail administrator to investigate rather than declaring every failed message malicious.

Verify with a known message

Compare the suspicious request with an expected message from the same service, while remembering that services can use multiple sending domains. Look for differences worth explaining, not a single magic header that proves innocence.

Avoid unsafe sharing

Do not upload a confidential business email to a public analyser just to obtain a colourful score. Use your provider's built-in view or an approved support channel. The final decision should combine reliable header evidence, the account context and independent verification of the action the sender wants you to take.

Official references

Consult the current vendor documentation if your version or screen differs.

Documentation-based draft. Commands have not all been executed against the named products in a lab. Validate configuration examples against your installed version before changing a working system.