---
title: "SPF vs DMARC: Read Email DNS Records Correctly | Emvero"
description: "Understand SPF vs DMARC, why SPF can pass while DMARC fails, and how to read MX and authentication records in a Domain Intelligence profile."
url: https://emvero.io/blog/spf-vs-dmarc/
language: en
updated: 2026-10-07
---

Blog

# SPF vs DMARC: what a domain's DNS records tell you

SPF authorises sending hosts. DMARC checks alignment with the visible From domain. Learn what those records establish alongside MX, and where DNS evidence ends.

Published 2026-09-27

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](https://www.rfc-editor.org/rfc/rfc7208.html#section-2) and [DMARC’s validation model](https://www.rfc-editor.org/rfc/rfc9989.html#section-4.1).

For the receiving side, SMTP looks up MX destinations when choosing a route. The [SMTP routing rules](https://www.rfc-editor.org/rfc/rfc5321.html#section-5.1) and our [MX record glossary](https://emvero.io/glossary/mx-record/) 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](https://emvero.io/blog/how-to-find-email-provider/) 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](https://www.rfc-editor.org/rfc/rfc7208.html#section-5).

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](https://www.rfc-editor.org/rfc/rfc9989.html#section-4.4).

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](https://www.rfc-editor.org/rfc/rfc9989.html#section-4.7).

## 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](https://knowledge.workspace.google.com/admin/security/set-up-dmarc).

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](https://www.rfc-editor.org/rfc/rfc6376.html#section-3.5) and [Google’s explanation of DMARC alignment](https://knowledge.workspace.google.com/admin/security/set-up-dmarc).

## 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](https://docs.emvero.io/using/domain-intelligence/) 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](https://emvero.io/blog/domain-without-mx-record/): SMTP can use implicit routing in that case. A [null MX declaration](https://www.rfc-editor.org/rfc/rfc7505.html#section-3) explicitly says the domain accepts no mail.

For a question about a particular email address, choose the appropriate [full check or domain check](https://emvero.io/compare/full-check-vs-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](https://emvero.io/domain-intelligence/) in your Emvero account. Read the route first, then the SPF and DMARC observations with their individual status and freshness.

## Terms used here

### MX record

An MX record is a DNS record that names a domain’s incoming mail server and its preference; it does not establish a mailbox.

### DNS failure

A DNS problem prevents a usable domain or routing answer; a missing domain and a failed lookup have different consequences.

[All articles](https://emvero.io/blog/)

## Choose what to check next.

Run a check from your account and inspect the evidence in its result.

Start for free