SPF (Sender Policy Framework) describes which hosts may send using a domain in the SMTP envelope. DMARC (Domain-based Message Authentication, Reporting, and Conformance) checks whether a passing SPF or DKIM identity aligns with the domain in the visible From address, and publishes a policy for messages that fail that check. MX answers a separate question: where incoming mail for the domain should go.
When you inspect a customer domain in Domain Intelligence, start with the question you need to answer. Use MX for the incoming route and SPF/DMARC for sending configuration. A question about a particular mailbox needs address-level evidence.
The difference between SPF, DMARC and MX
| Record | Main question | What publication alone cannot establish |
|---|---|---|
| MX | Where should mail addressed to this domain go? | Whether a named mailbox exists or a server will accept a message |
| SPF | Is the sending host authorised for the SMTP domain identity? | Whether the visible From domain is authenticated |
| DMARC | Does a passing SPF or DKIM identity align with the visible From domain? |
Whether any particular message passed authentication or reached an inbox |
SPF uses the SMTP MAIL FROM identity and can also check HELO. DMARC uses the visible From domain. The standards define these roles in SPF’s operational overview and DMARC’s validation model.
For the receiving side, SMTP looks up MX destinations when choosing a route. The SMTP routing rules and our MX record glossary explain that process.
Read one domain’s records without merging their meanings
Consider this synthetic DNS configuration. Every name uses the reserved .example namespace; this is an illustration, not a production setup to copy.
atelier.example. IN MX 10 inbound.gateway.example.
atelier.example. IN TXT "v=spf1 include:_spf.sender.example -all"
_dmarc.atelier.example. IN TXT "v=DMARC1; p=reject; aspf=s; adkim=s"
The MX names an incoming destination. It may be a filtering gateway in front of another mailbox platform. The sending service named by SPF can be different from that incoming service; finding the email provider from MX explains the attribution limit.
The SPF include asks an evaluator to consult another domain’s SPF policy. The trailing -all supplies an SPF fail result if evaluation reaches it without an earlier match. You need the sending IP and SMTP identity, plus the referenced policy, to evaluate a real transaction. Seeing the record is only the starting point. RFC 7208 defines these mechanisms.
The DMARC record publishes p=reject and chooses strict alignment with aspf=s and adkim=s. Strict alignment requires identical domains; relaxed alignment permits domains sharing the same organisational domain. The policy concerns mail using atelier.example in its visible From, not mail addressed to atelier.example. DMARC defines alignment and policy separately.
The other policy values are none, which expresses no handling preference for DMARC failures, and quarantine, which treats such mail as suspicious. A receiver also applies its own handling rules; the published value is not a delivery guarantee. DMARC policy values.
SPF can pass while DMARC fails
Suppose a sending service submits a message with these identities:
Visible From: hello@atelier.example
SMTP MAIL FROM: bounce@sender.example
SPF result for sender.example: pass
DKIM: no passing aligned signature
This is a synthetic message scenario, not a result returned by Domain Intelligence. Assume the receiver has established the SPF pass for sender.example. That domain differs from atelier.example, so the SPF result does not satisfy DMARC alignment. With no passing aligned DKIM signature, the message fails DMARC. Google’s DMARC guide explains this SPF alignment requirement.
Adding a service to atelier.example’s SPF include list does not change a message’s MAIL FROM identity. Check which envelope domain the service actually uses.
DKIM (DomainKeys Identified Mail) authenticates a signing domain through a message signature. If this message has a valid DKIM signature whose d= domain is atelier.example, that aligned result can satisfy DMARC even when the SPF identity remains unaligned. One passing aligned mechanism is enough. See the DKIM signature specification and Google’s explanation of DMARC alignment.
What Domain Intelligence establishes
Emvero’s Domain Intelligence reads mail routing and MX records, matches a visible incoming provider when possible, and reports supported fields from published SPF and DMARC records. It does not open an SMTP session or authenticate a message.
| Profile field | How to read it |
|---|---|
mail_routing.status |
routable means DNS provides a mail route; recipient acceptance has not been tested |
SPF present and syntax |
Whether the record was observed and its publication syntax could be checked |
SPF includes, redirect, all_qualifier |
Extracted parts of the published record; referenced SPF policies are not recursively evaluated |
DMARC policy_domain and inherited |
Where the discovered policy came from and whether it was inherited |
DMARC published_policy and effective_policy |
The published policy and the applicable policy after supported discovery and policy rules; neither is a message verdict |
SPF/DMARC evaluation |
not_performed: no sender or message authentication test ran |
A partial profile may retain a known route while another observation is unavailable. Read the affected field’s metadata and its observed_at, expires_at and stale values. A stale observation describes an earlier finding; an unknown value leaves the question unsettled. Neither should become a negative finding in your application.
The Domain Intelligence response guide documents those fields. The profile provides no DKIM check, DMARC monitoring, sending-reputation assessment or inbox-placement test.
Choose the evidence for the decision you need
If you need to know whether a domain has an incoming mail route, start with routing. Missing SPF or DMARC records do not establish that it cannot receive mail. A published p=reject policy does not close its mailboxes.
If MX is absent, check the domain without an MX record explanation: SMTP can use implicit routing in that case. A null MX declaration explicitly says the domain accepts no mail.
For a question about a particular email address, choose the appropriate full check or domain check. Domain evidence stops before the mailbox; a full check may collect recipient-level evidence when the destination permits it.
For a sending-authentication problem, inspect a real message through the receiving system you control. Compare its envelope domain, visible From, DKIM signing domain and authentication results. DNS publication alone cannot supply those results.
To inspect the domain configuration, open Domain Intelligence in your Emvero account. Read the route first, then the SPF and DMARC observations with their individual status and freshness.