SPF, DKIM and DMARC help receivers assess the identities used by email. Their DNS records are useful starting points for diagnosis, but a published record is not the same as a successfully authenticated message. A practical review combines public DNS with the headers and delivery results of real mail.
SPF: authorization for a sending identity
SPF lets a domain publish which sources are authorized to use it in SMTP identities such as MAIL FROM. A record lookup can show the policy string; evaluating it needs the actual sending IP and relevant identity.
A common operational mistake is adding a second SPF record when introducing a new sender. Review and maintain one coherent SPF policy rather than accumulating separate policies. SecuraWall’s SPF Lookup reports the matching records, but does not recursively expand includes or provide a full evaluation.
DKIM: a signature and a selector
DKIM associates a cryptographic signature with a signing domain. The receiver uses a selector to locate the public key in DNS. For a lookup, take d= and s= from a real message’s DKIM-Signature header rather than guessing a provider’s default selector.
Finding a key does not verify that the message was signed with it or that the signature survived delivery. If a lookup finds nothing, first confirm that the signing domain and selector match the message being investigated.
DMARC: authentication aligned with the visible From domain
DMARC connects authentication results with the visible From domain through alignment. A policy is published under _dmarc and can describe preferred handling and reporting. Do not assume that a strict policy is safe until all legitimate sending systems have been considered.
The DMARC Lookup here checks the exact domain entered. It does not perform organizational-domain inheritance, validate reporting permissions or determine whether a particular email passed DMARC.
Use the right question for each tool
- MX Lookup: Where does this domain publish incoming mail routes?
- SPF Lookup: What SPF policy does this exact domain publish?
- DKIM Lookup: Is a public key published for this known selector and signing domain?
- DMARC Lookup: What policy is published at this exact _dmarc name?
A short investigation workflow
Start with a real message from the affected sending system. Record its envelope sender, visible From domain and DKIM signing details. Look up the corresponding DNS records, then compare them with the receiver’s authentication results. If forwarding or another service changed the mail path, include that path in the review.
Keep a list of business senders such as mailbox platforms, invoicing systems, CRM services and approved SMTP devices. Review one source at a time before making a domain-wide policy change. A DNS adjustment can affect several systems that do not share the same administrator.
Authentication and incoming protection work together
Authenticated mail can still contain unwanted or harmful content. Incoming security checks, quarantine and continuity remain separate requirements. Equally, passing authentication does not guarantee inbox placement.
Inspect the published records with SPF Lookup, DKIM Lookup and DMARC Lookup. For incoming inspection and quarantine, review SecuraWall Email Security.
Technical references
The protocol references are SPF (RFC 7208), DKIM (RFC 6376) and DMARC (RFC 7489). Check their current status and updates when designing production authentication policies.