SPF and DMARC: give your email an identity
An email has an envelope, a message and several possible identities. SPF, DKIM and DMARC help a receiving system connect those identities. Understanding that connection is the useful part.
Inventory first. Alignment next. Enforcement when ready.
Three checks, three different jobs
SPF checks whether a sending server is authorised for an envelope identity, usually the MAIL FROM domain. That can differ from the From address a person sees. A passing SPF result alone does not establish that the visible sender is authentic.
DKIM adds a signature over selected parts of the message using a signing domain. DMARC connects a passing SPF or DKIM identity to the visible From domain through alignment, and publishes a requested handling policy for failures. Receivers still make their own delivery decisions.
SPF
A DNS policy describing permitted senders. Includes and redirects can create dependencies; a record that looks simple may require more evaluation.
DKIM
A verifiable signature associated with a domain. It is not message encryption and does not make the content trustworthy.
DMARC
At least one authenticated identity must align with the visible From domain. Relaxed and strict alignment have different matching rules.
Follow the mail before changing the policy
Coordinate with your email administrator and sending providers. DNS records describe policy; real messages show whether it works.
Understand → test → change → recheckList every legitimate sender
Include your mailbox provider, transactional mail, marketing tools, support systems and less frequent senders. Record the visible From domain, envelope domain and DKIM signing domain for each.
Ready when Your inventory includes occasional as well as daily mail.
Authenticate and verify alignment
Follow each provider’s setup for SPF and DKIM, then inspect received test messages. Ensure a passing identity aligns with your From domain. Keep one SPF policy at a given name and review dependency limits rather than adding duplicate records.
Ready when Real messages from each service pass the intended aligned check.
Monitor and investigate
Use an initial DMARC monitoring policy and a reporting destination you control. Review aggregate reports alongside delivery evidence over a representative sending cycle. Protect report access and investigate legitimate failures, forwarding and mailing-list behaviour.
Ready when Known mail flows are understood; missing reports are not treated as success.
Tighten deliberately, then recheck
Choose stronger handling only after legitimate senders are ready. Use current provider guidance and a controlled rollout with delivery monitoring and a rollback plan. Review subdomain policy separately; receiver support and current standards affect rollout options.
Ready when You can detect and reverse unintended delivery problems.
What CVE Scanner can see
Public beta · validation ongoingWithin the lens
Bounded public DNS checks for supported SPF syntax, terminal policy and dependencies, plus supported DMARC parent-policy discovery. A direct record and a supported inherited policy are distinct observations.
Beyond the lens
No DKIM discovery or signature validation, mail sending, inbox access, private mail-server inspection or end-to-end delivery test. This is not a complete SPF evaluation.
Use the DNS evidence to find the relevant policy owner. Confirm the effective policy and alignment with your provider and actual received messages before increasing enforcement.
A couple of useful questions
Does a missing direct DMARC record mean there is no policy?
Not necessarily. A policy can apply through supported parent-domain discovery. Read the direct-record and effective-policy outcomes separately. DNS ambiguity or an unsupported discovery case is incomplete evidence, not a clean pass.
Will DMARC stop all phishing?
No. It helps with abuse of your domain identity, but does not stop lookalike domains, compromised legitimate accounts or every forwarding problem. Keep account security, filtering and user reporting in your wider plan.
Read a little deeper
Primary guidance for the next conversation with your developer or administrator. References open in a new tab.
- Google: Email sender guidelines
Authentication and alignment from a receiving provider’s perspective.
- IETF: SPF specification (RFC 7208)
Envelope identities, policy records and DNS evaluation limits.
- IETF: DMARC specification (RFC 9989)
Current protocol details for alignment, policy discovery and handling.