Klytic

Home›Guides›Email security

Email security · Understand

SPF, DKIM and DMARC: what they protect, and what they do not

SPF states which servers may send for a domain, DKIM signs the message, and DMARC checks that one of the two matches the domain shown in “From” and says what to do if the check fails. Together, they prevent a stranger from using your exact domain. They do not read the text: a cousin domain, a misleading display name or a compromised account all get through.

Updated October 20266 minOfficial sources cited

SPF: who is allowed to send

RFC 7208 starts from an observation: nothing in the email protocol prevents a server from claiming any sender address. SPF lets a domain owner publish in DNS the list of servers authorized to send on its behalf, and lets the receiving server check that authorization.

Two details change everything:

  • SPF checks the envelope address (the one used in the dialogue between servers, known as “MAIL FROM”) and the name announced by the server, not the address the recipient reads in “From.”
  • SPF judges the last server that handed over the message. When a message is forwarded by another server, it is no longer a server authorized by the original domain that delivers it: the check can fail even though the message is legitimate.

A domain publishes only one SPF record. Every sending source must be listed in it: email service, invoicing software, newsletter tool, CRM, copier that scans to email.

DKIM: the message is signed

According to RFC 6376, DKIM allows the owner of a signing domain to claim some responsibility for a message, by means of a cryptographic signature. The public key is in DNS. Verifying the signature establishes that the signed parts have not changed since signing.

The signature travels with the message. It therefore survives a relay or forwarding better than SPF does, as long as that relay does not modify the subject or the body. A mailing list that adds a footer to the message breaks it.

What DKIM does not do, according to the same RFC: it does not encrypt the message, a failure does not require rejection, and the signing domain does not have to be the one shown in “From.” That is precisely the gap DMARC fills.

DMARC: alignment and policy

RFC 7489 defines DMARC as a way for a domain owner to express a domain-level policy. The mechanism relies on alignment: the domain of the address shown in “From” must match the domain validated by SPF or by DKIM. If neither is aligned, DMARC fails.

The domain then publishes what it wants:

  • none: no action requested, monitoring only;
  • quarantine: treat the message as suspicious;
  • reject: reject the message.

DMARC also provides for reports: aggregate reports, which summarize which servers sent on behalf of the domain and with what result, and failure reports, message by message. These are what let you discover a forgotten tool sending on your behalf, or someone spoofing your domain.

MechanismWhat it checksWhat it does not look at
SPFThe server delivering the message is authorized for the envelope domainThe displayed address, the content
DKIMThe signed message has not been altered; a domain takes responsibility for itThe displayed address, the honesty of the content
DMARCThe displayed domain is aligned with SPF or DKIM; policy in case of failureLookalike domains, the display name, the text

Does DMARC block phishing?

It blocks part of domain spoofing, not phishing in general. RFC 7489 says so explicitly: DMARC does not address visually similar domain names or display-name abuse, and content analysis is outside its scope. It does not attempt to solve every problem of fraudulent email.

In practice, DMARC does not see:

  • a cousin domain: the fraudster perfectly authenticates their own domain, which looks like yours;
  • a spoofed display name: “Accounting Department” writing from an unrelated address;
  • a compromised account that signs correctly, since it is the real server that sends;
  • a message unrelated to your domain: a fake carrier alert arrives from a domain that has nothing to do with yours;
  • a domain without a policy: if the imitated domain publishes “none,” the recipient has no instruction to reject.

These cases call for other analyses: domain similarity, reputation, content, behavior. See spam, phishing, malware and compromised accounts.

Forwarding and mailing lists: ARC

Forwarding often breaks SPF, a list that modifies the message breaks DKIM, and DMARC then fails on a legitimate message. ARC, described in RFC 8617 (experimental status), lets each intermediary attest to the authentication result it observed. The final server may choose to take it into account.

Protecting your domain vs. filtering what comes in

These are two topics that are often confused.

  • Protecting the sending domain: publishing SPF, DKIM and DMARC for your domain, so that others can refuse messages that spoof it. You publish; recipients enforce.
  • Filtering what comes in: checking other domains’ records on the mail you receive, then applying all the other analyses.

Phased deployment

  1. Inventory everything that sends on behalf of the domain.
  2. A single SPF record that authorizes them; a DKIM signature for each service capable of signing.
  3. DMARC set to “none,” with an address to receive reports.
  4. Review the reports for several weeks; fix forgotten sources.
  5. Move to “quarantine,” then to “reject” once all legitimate sending is aligned.

An example, for illustration. A firm publishes DMARC at “none” and reads its first reports. It discovers three sources: its email service, properly aligned; its invoicing software, which sends invoices with the firm’s domain without a DKIM signature; and an unknown server abroad sending hundreds of messages in its name. It fixes the invoicing software, waits for a clean report cycle, then moves to “quarantine”: recipients that enforce DMARC now treat messages from the unknown server as suspicious.

When you change email services, these records are prepared before the MX change. The guide migrating email without interruption describes that moment; it is not repeated here.

Frequently asked questions

Does a DMARC “none” policy protect?

No. It allows monitoring through reports. Protection starts with “quarantine” or “reject.”

Why does a legitimate message fail DMARC?

Most often: forwarding, a mailing list, or a service sending on your behalf without being declared in SPF or signing with DKIM.

Our email service does not DKIM-sign: what should we do?

A gateway placed on the outbound path can sign in its place. See Protecting the email system you already have.

Where can I read the result of these checks on a received message?

In the message headers. For Klytic MTA, see Reading and exporting a filter decision.

Where Klytic stands

Klytic MTA handles both topics, in front of any email service:

  • Essential and Advanced: SPF, DKIM and MX checks; DMARC verification, including for forwarded messages thanks to ARC; DKIM signing of outgoing mail, even if your email service does not do it.
  • Advanced: DMARC console, with your domains’ reports, alerts and suggested fixes, to manage the gradual move to “reject.”

DMARC is only one layer: Klytic MTA adds detection of lookalike domains, display names and fraud scenarios, described in impersonation and CEO fraud.

If you use Klytic Mail, SPF, DKIM and DMARC are configured for your domain: that is protection of the sending domain. Klytic MTA can be subscribed to with or without Klytic Mail.

Sources

Consulted in October 2026.

  • RFC 7208, SPF: the domain owner publishes the hosts authorized to use its domain in the “MAIL FROM” or “HELO” identity, and the receiver checks that authorization. rfc-editor.org
  • RFC 6376, DKIM: a domain claims responsibility for a message through a cryptographic signature; no encryption, no mandatory rejection, the signing domain may differ from the displayed author. rfc-editor.org
  • RFC 7489, DMARC: alignment of the “From” domain with SPF or DKIM, none, quarantine and reject policies, aggregate and failure reports; visually similar domains, display name and content analysis out of scope. rfc-editor.org
  • RFC 9989 (May 2026), which obsoletes RFC 7489: same policy values and same exclusions (lookalike domains, display name). rfc-editor.org
  • RFC 8617, ARC (experimental): authenticated received chain; a DMARC receiver may accept the evaluations carried by a valid ARC chain. rfc-editor.org
  • Klytic, Klytic MTA page: authentication checks, outbound DKIM signing and DMARC console in the Essential and Advanced plans, options, deployment modes, activation via the MX record. klytic.com

Verify and sign, in front of your email service

Klytic MTA checks SPF, DKIM and DMARC on arrival and signs your outgoing mail.

Talk to an advisor →

Discover Klytic MTA

Further reading

GuidesHow do you migrate a business email service without downtime?Coexistence, second pass, MX TTL, SPF, DKIM, DMARC and test sends: switching email services without losing mail, and what remains visible.GuidesRead →Understand · Email securitySpam, phishing, malware and compromised accountsFour threats come through the same door and are not handled the same way. What gives each one away, what stops it, and why anti-spam alone is no longer enough.6 min readRead →Understand · Email securityProtecting the email system you already haveMicrosoft 365, Google Workspace, Exchange: you can add a security gateway without changing email services. What changes, who sets it up, the limits.7 min readRead →

Welcome offer

30-day free trial, assisted migration

No-commitment trial offer. An advisor will call you back to understand your needs and prepare your Klytic space.

🚀 Start free trial See pricing