SPF, DKIM, and DMARC: Authenticating an Email Domain

SPF, DKIM, and DMARC solve related but distinct problems. SPF lists the systems permitted to send for the technical envelope domain. DKIM adds a cryptographic signature to selected headers and message content. DMARC connects those results to the domain people see in the From field and publishes a policy for messages that fail authentication.

None of these mechanisms alone proves that a message is useful or wanted. Successful authentication means the receiving system could verify the asserted relationship between the message and a domain. The recipient still decides whether to place it in the inbox, spam folder, or reject it, taking reputation, complaints, volume, content, and local policy into account.

SPF checks the sending path

SPF is published as a DNS TXT record. It describes which IP addresses or external services may send using a particular domain in the SMTP MAIL FROM command. This address is also called the envelope-from or return path. It can differ from the From address visible in the email client, which is the source of many incorrect SPF interpretations.

A simplified example:

example.uz.  IN  TXT  "v=spf1 ip4:192.0.2.10 -all"

This record permits the stated IPv4 address and produces SPF fail for other sources. The receiving system decides how to use that result. It is an example of syntax, not a template to copy: a real policy must include every legitimate domain sender—the main SMTP server, CRM, notification service, newsletter platform, and any other systems.

Each domain name must have one SPF policy. Two separate TXT records beginning with v=spf1 are not combined and cause an evaluation error. Multiple sources belong in a single policy. The standard also limits the DNS lookups triggered by mechanisms such as include, a, mx, exists, and redirect. A long chain of external includes can end in permerror even when each service is listed correctly on its own.

SPF is sensitive to ordinary forwarding. A forwarder can preserve the original envelope-from while retransmitting from an IP absent from the original domain's policy. That is why SPF does not replace DKIM, and why forwarding infrastructure sometimes needs the Sender Rewriting Scheme. Inspect the final Authentication-Results header instead of predicting the result from the visible From address.

DKIM verifies a message signature

With DKIM, the sending server hashes selected headers and the message body, signs the result with a private key, and adds a DKIM-Signature header. The receiver reads the d= domain and s= selector, then retrieves the public key from a name such as:

selector1._domainkey.example.uz

The private key remains with the sending system; only the public part is published in DNS. A successful verification shows that the signed elements were not silently modified after signing and that the sender possessed the corresponding private key.

Selectors allow keys to be rotated without stopping all sending at once. Publish a new key under a new selector, switch signing to it, verify real traffic, and remove the old record only after a transition period. This is safer than using one key indefinitely or replacing a value under the same name without accounting for DNS caches.

DKIM is not a “not spam” seal. A legitimate newsletter, unwanted message, or compromised account can all carry a valid signature. Forwarders and mail gateways may also change the subject, body, or attachments; modifying a signed element can break verification. This is why DMARC needs aligned success from at least one path—SPF or DKIM—not necessarily both.

DMARC connects authentication to the visible From address

Users normally trust the domain shown in From. DMARC checks whether that domain aligns with the domain that passed SPF or with the domain in a valid DKIM signature. This relationship is called domain alignment.

Relaxed alignment allows organizationally related subdomains. Strict alignment requires a more exact match. DMARC passes when at least one aligned mechanism passes: SPF or DKIM. A message can therefore pass DMARC after SPF fails if an aligned DKIM signature remains valid, and vice versa.

The policy is published as a TXT record at _dmarc.example.uz:

_dmarc.example.uz.  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.uz"

p=none does not ask the receiver to quarantine or reject solely because of DMARC. The rua parameter supplies an address for aggregate reports. p=quarantine asks receivers to treat failures as suspicious, while p=reject asks them to reject. “Asks” is important: the receiving system makes the final decision under its local policy.

The rua address receives aggregate reports. They reveal sources sending on behalf of the domain, SPF and DKIM results, and alignment failures. Prepare a mailbox or specialized processor for them: XML files are inconvenient to inspect manually, their volume can be significant, and reports contain technical metadata about mail flow.

Why all three mechanisms are needed

SPF without DMARC checks a technical envelope address that the user may never see. DKIM without DMARC verifies a signing domain that need not match the visible From address. DMARC establishes that connection but depends on SPF and DKIM results; it does not create them.

A practical model is:

These records authenticate outgoing messages. MX has another purpose: it specifies the server for incoming delivery. If you are changing the inbound route, start with “Email MX Records: Pointing Messages to the Right Server”.

A safe implementation sequence

First map every sender—not only employees, but also the website, password-recovery system, invoices, CRM, support, monitoring, and newsletter service. For each source, determine its envelope-from, the DKIM signing domain, and whether it can use your domain instead of the provider's shared one.

Then proceed in stages:

1. Build one SPF policy for all confirmed sources and check its DNS lookup count.
2. Enable DKIM on every service, keeping private keys out of DNS and public repositories.
3. Inspect Authentication-Results for several real messages in different external mail systems.
4. Publish DMARC with a monitoring policy and a working aggregate-report address.
5. Find forgotten legitimate sources, correct alignment, and stop unauthorized sending.
6. Consider quarantine or reject only after a sufficient observation period.
7. After every change, test real messages again instead of checking only that TXT exists.

Moving immediately to a strict policy can block legitimate notifications when the inventory is incomplete. The opposite mistake is leaving p=none for years and treating the domain as protected. Monitoring supplies the evidence; anti-spoofing protection becomes stronger once sources have been corrected and a stricter policy is enabled deliberately.

A Mailcore specialist prepares and validates MX, SPF, DKIM, and DMARC for the actual sending architecture. The client identifies the website, CRM, and other sources so Mailcore can account for them before switchover and policy enforcement. See how Mailcore connects a domain from request to first message for the step-by-step context.

What to inspect in message headers

Send a test message to an external mailbox and open the original or technical headers. Find Authentication-Results and check:

• the SPF result and the domain to which it applies;
• the DKIM result, d= domain, and selector;
• the DMARC result and header From domain;
• whether the actual outgoing server is the expected one;
• whether an intermediate gateway changed the message.

A pass for all three creates an important technical foundation for deliverability. If the recipient rejects or filters the message, diagnosis also needs the SMTP response code, source reputation, traffic pattern, and content. Our article on why messages go to spam and what to check gives the full sequence.

Common configuration mistakes

The most visible SPF error is multiple policies on one name. Other frequent problems include old IP addresses, forgotten include mechanisms, and exceeding the DNS lookup limit. With DKIM, administrators often confuse selectors, truncate long TXT values when moving between control panels, or publish the key under one domain while signing with another. DMARC problems commonly include a non-working report address, premature reject, and third-party services that are not aligned.

Copying records from someone else's instructions without understanding your own architecture is equally dangerous. SPF must describe your sources, the DKIM key comes from your sending system, and DMARC policy should follow observation of your traffic. Query authoritative DNS, account for TTL, and document every change so a future failure has a traceable cause instead of becoming a mystery.

Sources

• RFC 7208: Sender Policy Framework
• RFC 6376: DomainKeys Identified Mail
• RFC 9989: Domain-based Message Authentication, Reporting, and Conformance
• Google: Email sender guidelines
• Microsoft Learn: Email authentication in Microsoft 365
• Cloudflare: Email security DNS records