What a mail configuration can tell you
A domain's MX records show which servers are designated to accept mail for it, and its SPF and DMARC TXT records describe which senders are authorised and what receivers should do with messages that fail authentication. Together these describe how the domain intends to send and receive email; they do not describe the content or intent of any particular message.
Patterns worth noting
A domain with no MX records is not configured to receive mail at all, which is unusual for a domain actively corresponding with customers or victims by email. A domain using a free consumer webmail provider's MX records while presenting itself as a corporate sender is a mismatch worth investigating further, particularly when compared with the mail setup of the organisation it appears to represent.
On the authentication side, a missing SPF record, an overly permissive SPF record with many unrelated includes, or a DMARC policy of p=none with no reporting address configured, are all signs of weak protection that fraudsters can exploit, either on their own domain or by spoofing a legitimate one that lacks protection. A domain with p=reject and aligned SPF/DKIM is harder to spoof directly, which is why attackers impersonating such a domain usually register a lookalike instead.
Comparing against a known-good baseline
The most reliable signal comes from comparison. Look up the MX, SPF and DMARC records for the organisation the suspect domain claims to represent, and compare mail providers, included sending services and policy strength. A supplier that normally sends through a well-known business mail platform but is suddenly represented by a lookalike domain using a different, newly configured provider is a stronger indicator than either fact alone.
Limits of this evidence
These records describe configuration, not delivery of a specific message, and they can change at any time, so a lookup taken after an incident may not reflect the configuration at the time a message was sent. Where a specific message is in question, rely on the authentication results already computed by your own trusted receiving mail server, recorded in the Authentication-Results header of the preserved original message, rather than recomputing SPF or DMARC after records may have changed.
- List MX hosts and preferences, and identify the mail provider.
- Record SPF mechanisms and DMARC policy, pct and reporting tags.
- Compare against the mail setup of the organisation being impersonated.
- Use preserved Authentication-Results headers for a specific message.
- Record collection time, since mail records change.