SPF, DKIM and DMARC: How the Three Email Authentication Records Work Together

SPF, DKIM and DMARC are three DNS records that answer three different questions about a message claiming to come from a domain: SPF says which servers may send it, DKIM proves the domain signed it, and DMARC says what to do when neither result lines up with the From address the recipient reads. A domain needs all three, aligned to that visible From domain, before From-header spoofing stops working; SPF or DKIM alone authenticate a domain the recipient never sees.

Why SPF, DKIM and DMARC are needed together: each record covers a gap the other two leave

SPF, DKIM and DMARC are needed together because a phishing message can pass SPF and DKIM while showing a different domain in the From header, and only DMARC checks that header. Nothing in RFC 7208 or RFC 6376 requires the domain they authenticate to match the one a recipient sees. An attacker can send from a domain they control, with valid SPF and DKIM for that domain, and put a bank's name in the From field.

DMARC closes that gap with identifier alignment: the domain that passed SPF (the envelope sender) or the domain that passed DKIM (the d= tag) must match the From header domain. DMARC passes when either aligned SPF or aligned DKIM passes; both are not required. On failure, the receiver applies the policy the domain owner published.

The dependency also works in the other direction: DMARC has nothing to evaluate without an SPF or DKIM result, so a DMARC record on a domain with neither fails every message.

SPF lists the servers allowed to send mail for a domain, and authenticates a field recipients never see

SPF (Sender Policy Framework, RFC 7208, April 2014) is a single TXT record at the domain that lists the IP addresses and services permitted to send mail using that domain in the SMTP envelope sender. A receiving server compares the connecting IP against the record and returns pass, fail, softfail or neutral. The final mechanism decides what an unlisted sender gets: -all (hard fail), ~all (soft fail) or ?all (neutral).

example.com.  IN  TXT  "v=spf1 include:_spf.google.com include:spf.protection.outlook.com ip4:203.0.113.10 -all"

SPF authenticates the RFC5321.MailFrom address, the envelope sender used in the server-to-server handshake, and the sending server's HELO name; DMARC uses only the MailFrom result. Neither is the From header. The two often differ by design: a marketing platform sends with its own bounce domain in the envelope while the customer's domain appears in From. SPF alone says nothing about the address a recipient reads.

Two limits shape every SPF record. Forwarding breaks it, because the forwarding server's IP is not on the list. And RFC 7208 section 4.6.4 caps the include, a, mx, ptr, exists and redirect mechanisms at 10 DNS lookups per evaluation; a record over the cap returns a permanent error (permerror), which receivers handle as a broken record rather than a pass, so the domain gets no SPF protection. Domains that accumulate SaaS senders often reach this limit without noticing.

The SPF checker reads a domain's TXT records over DNS and reports which services the record authorizes, how it ends and how many lookups it consumes, without sending any mail. The companion post on what an SPF record is covers the syntax mechanism by mechanism.

DKIM signs the message with a key the domain published, so the signature survives forwarding

DKIM (DomainKeys Identified Mail, RFC 6376, September 2011) attaches a cryptographic signature to an outbound message, computed over selected headers and the body with a private key the sending system holds. The matching public key is published in DNS at selector._domainkey.domain; the selector, named in the signature's s= tag, lets one domain publish several keys at once.

A receiving server fetches the key and verifies the signature, which proves a system holding the domain's key signed the message and the signed parts were not altered.

DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=google; h=from:to:subject:date; bh=...; b=...

DKIM's identifier is the domain in the d= tag, and DKIM says nothing about which servers are allowed to send: any system holding the key can sign. DKIM survives forwarding because the signature travels with the message rather than depending on the sending IP, which is why a domain at DMARC reject usually relies on DKIM to carry forwarded mail through. It does break when an intermediary rewrites signed content, as some mailing lists do.

The DKIM checker looks up the public key for a domain and selector, confirms it is a real RSA or Ed25519 key, measures its length and flags an empty p tag (revoked), keys under the 2048 bits RFC 8301 recommends, and the t=y test flag. The companion post on what DKIM is covers key rotation and selector management.

DMARC aligns SPF or DKIM with the From header and publishes the policy for failures

DMARC (Domain-based Message Authentication, Reporting and Conformance) is a TXT record at _dmarc.domain that tells receivers how to handle a message that claims the domain in its From header but fails aligned SPF and aligned DKIM, and where to send reports. It was defined in RFC 7489 in March 2015 and is now specified by RFC 9989, published as a Proposed Standard in May 2026, which obsoletes RFC 7489 and RFC 9091. The v=DMARC1 record format is unchanged, though pct is dropped and np, psd and t are added.

_dmarc.example.com.  IN  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com"

The policy tag p= takes one of three values. none delivers failing mail normally and only sends reports, so it is a monitoring mode with no protection. quarantine asks receivers to treat failing mail as suspicious, which usually means the spam folder. reject asks receivers to refuse the message, typically during the SMTP transaction, so it never reaches a mailbox; receivers still apply their own local policy.

Alignment has a relaxed mode (default), where the authenticated domain and the From domain share an organizational domain, and a strict mode where they must match exactly. The companion post on what DMARC is covers every tag, the alignment rules, the report formats and the staged rollout from none to reject.

How a receiving server applies SPF, DKIM and DMARC to one message, in order

A receiving mail server evaluates SPF, DKIM and DMARC in sequence, and each step feeds the next.

1. Connection and envelope. The sending server connects and states the envelope sender (MAIL FROM). The receiver looks up the SPF record for that domain and checks the connecting IP against it. Result: pass, fail, softfail, neutral or an error.
2. Message headers and body. The receiver reads the DKIM-Signature header, fetches the public key at the selector and d= domain named in the signature, and verifies the signature. Result: pass or fail, with the d= domain attached to a pass.
3. Alignment. The receiver extracts the From header domain, looks up _dmarc. for it, and asks whether the SPF-authenticated domain or the DKIM-authenticated domain aligns with the From domain. Either aligned pass means DMARC passes and the message is delivered normally.
4. Policy. If neither identifier aligns, the receiver applies the published p= policy: deliver (none), treat as suspicious (quarantine) or refuse (reject). If the domain publishes a rua address, the result goes into the aggregate report the receiver sends, typically daily.

Two cases make the ordering concrete. A forwarded message fails SPF at step 1, but its DKIM signature still verifies and aligns, so DMARC passes at step 3. A spoofed message has valid SPF and DKIM for the attacker's own domain, neither of which aligns with the victim domain in From, so step 4 applies the victim's policy.

MX and MTA-STS govern where inbound mail goes and whether the connection is encrypted

MX records and MTA-STS control the inbound and transport side of a domain's mail, which SPF, DKIM and DMARC do not touch. A domain can have all three authentication records enforced and still receive mail over an unencrypted connection.

MX records list the hostnames that accept mail for the domain, each with a priority number; lower numbers are tried first. MX answers one question: where should mail addressed to this domain be delivered? A scan that flags an MX finding is raising a routing or availability question, not a spoofing one.

MTA-STS (SMTP MTA Strict Transport Security, RFC 8461, September 2018) lets a receiving domain declare that mail sent to it must arrive over TLS with a certificate that matches its MX hosts. Without it, SMTP encryption is opportunistic: an attacker on the path can strip the STARTTLS offer and the sender falls back to plaintext. MTA-STS protects the hop between two mail servers for senders that check the policy; it is not end-to-end encryption.

The record is a TXT entry at _mta-sts.domain carrying v=STSv1 and a policy id, paired with a policy file at https://mta-sts.domain/.well-known/mta-sts.txt that lists the MX hosts and a mode of testing, enforce or none (used to retire a policy).

BIMI is the optional payoff once DMARC is enforced

BIMI (Brand Indicators for Message Identification) lets a participating mailbox provider display a verified brand logo next to authenticated mail, and it requires a DMARC policy of quarantine or reject before a provider shows the logo; quarantine with pct below 100 or a subdomain policy of none does not qualify. BIMI is specified in an IETF draft rather than an RFC. It is a recognition signal rather than an authentication control: BIMI adds no check to the message flow and stops nothing. The companion post on what BIMI is covers the record, the logo format and the Verified Mark Certificate some providers require.

What a domain security scan of truvocyber.com showed, as a snapshot from 2026-09-20

Truvo's own domain, scanned with the domain security scan on 2026-09-20, scored 77 out of 100 across the five email controls, with SPF and DMARC enforced and the transport and branding records not yet published. The scan reads public DNS records and sends no mail. DNS records change, so the result below is a dated snapshot, not a standing description of the domain.

A valid SPF record with hard fail and a DMARC policy at quarantine put the domain ahead of one with no DMARC record at all. Three gaps remain: no MTA-STS policy, a DMARC policy one step short of reject, and a single published MX hostname not yet documented as intentional.

The Review flag on MX is easy to overstate. One published hostname is concentration on a single DNS name; it does not mean one physical server, and managed providers such as Google Workspace typically operate redundant infrastructure behind one name. The finding is a prompt to confirm and document the configuration, not a claim that inbound mail is fragile.

The deployment order for SPF, DKIM, DMARC, MTA-STS and BIMI that avoids breaking mail

The order below moves from lowest delivery risk to highest impact, and each step depends on the one before it.

1. Publish SPF and DKIM for every legitimate sender. The mail platform, marketing tool, help desk, billing system and any application that sends email all count. Keep SPF under 10 lookups and sign with a d= on the organizational domain.
2. Publish DMARC at p=none with a rua address. Delivery does not change; reports list every source sending as the domain.
3. Read the reports until every legitimate source passes aligned SPF or DKIM, covering a full cycle of monthly and quarterly sending.
4. Move DMARC to quarantine, then to reject. Each step follows clean reports, since reject blocks a misaligned legitimate sender outright.
5. Confirm and document the MX configuration. Verify the provider's hosts match what the domain publishes.
6. Deploy MTA-STS in testing mode with TLSRPT, then enforce once every MX host presents a valid certificate and the reports show no failures.
7. Add BIMI last, once DMARC is at quarantine or reject and stable.

Truvo's checkers map each email finding to SOC 2 CC6.1, CC6.7 and CC7.2 and to ISO 27001:2022 A.5.14 and A.8.20, so an enforcing record is evidence and a missing one is a gap an auditor is likely to ask about. The guide to SOC 2 CC6.6 on boundary protection covers the criterion for threats from outside the system boundary, and the SOC 2 compliance hub collects the guides for the other criteria.

Every check referenced above is passive and free. The free security tools hub collects the SPF, DKIM, DMARC, MX and MTA-STS lookups, so a domain owner can compare results against the order here before changing production DNS.

Frequently asked questions about SPF, DKIM and DMARC

What is the difference between SPF and DMARC?

SPF authorizes which mail servers may send using a domain in the envelope sender, a field recipients do not see. DMARC checks whether that authorized sender, or a valid DKIM signature, aligns with the domain in the From header, and tells receivers what to do when it does not. SPF alone leaves the visible From address unprotected.

Does SPF alone stop email spoofing?

No. SPF authenticates the envelope address and never checks the From header. A domain with a valid SPF record ending in -all can still be spoofed in the address a recipient reads if DMARC is absent or set to p=none.

Do SPF and DKIM both have to pass for DMARC to pass?

No. A message passes DMARC when either SPF or DKIM passes and the domain it authenticated aligns with the From header domain. Publishing both is still the norm, because SPF fails on forwarded mail and DKIM depends on every sender signing correctly.

Is DMARC quarantine the same as DMARC reject?

No. Quarantine asks receivers to treat failing mail as suspicious, typically by placing it in spam, but each receiver decides how to apply that and some spoofed mail still reaches inboxes. Reject asks receivers to refuse failing mail, typically during the SMTP transaction. The move to reject follows aggregate reports showing every legitimate sender authenticating correctly.

What does MTA-STS protect that SPF, DKIM and DMARC do not?

SPF, DKIM and DMARC authenticate who sent a message. MTA-STS (RFC 8461) protects the connection the message travels over, requiring TLS with a valid certificate to the domain's listed MX hosts for senders that check the policy. It covers the hop between two mail servers, not the message end to end.