SPF, DKIM, and DMARC explained: how email authentication works

SPF, DKIM, and DMARC are complementary email-authentication mechanisms published through DNS. They help a receiving mail system evaluate whether a message is associated with the domain it claims to use. They can reduce successful spoofing and provide better evidence for filtering decisions, but they do not make every message safe or guarantee inbox placement.

The three controls solve different parts of the problem: SPF authorises sending infrastructure, DKIM adds a cryptographic signature, and DMARC checks alignment with the visible From domain while defining policy and reporting.

SPF: which servers may send for the domain?

Sender Policy Framework is a TXT record that describes authorised sending sources. During delivery, the receiver checks the connecting server and evaluates the SPF policy for the relevant envelope domain. A result can pass, fail, or be inconclusive depending on the record and lookup.

SPF has important limits. It does not sign the message body, and normal forwarding can change the connecting server so that SPF no longer passes. DNS lookup limits also matter when many include mechanisms are used. A hostname should not publish multiple independent SPF records; authorised sources must be combined into one valid policy.

DKIM: a verifiable digital signature

DomainKeys Identified Mail uses a private key on the sending system to sign selected headers and a body hash. The matching public key is published in DNS under a selector, which allows a domain to rotate keys or support more than one sending platform.

The receiving server retrieves that public key and verifies the signature. A valid result provides evidence that signed content was not altered after signing and that the signer controlled the private key associated with the domain. DKIM does not encrypt the message and does not prove that its content is honest.

DMARC: alignment, policy, and reporting

Domain-based Message Authentication, Reporting, and Conformance connects authentication to the domain visible in the From header. A message passes DMARC when an aligned SPF or aligned DKIM result passes. Alignment means the authenticated domain is appropriately related to the visible From domain.

• p=none requests monitoring without asking receivers to quarantine or reject solely because of DMARC.
• p=quarantine asks receivers to treat failing mail as suspicious.
• p=reject asks receivers to reject failing mail.

Aggregate reports can reveal legitimate sending services and unauthorised activity. They may contain technical identifiers and should be handled appropriately. Moving directly to reject without inventory and monitoring can block valid senders.

How the three mechanisms work together

Suppose a company sends invoices from its mail platform and newsletters from a separate service. Both must be represented in the authentication design. SPF may authorise their sending infrastructure, each platform can sign with DKIM, and DMARC evaluates whether at least one passing method aligns with the visible domain.

Forwarding illustrates why more than one method is useful. The forwarding server may not be authorised by the original SPF policy, while a DKIM signature can survive if the message is not modified. Mailing lists and gateways may alter messages, so results must be assessed from real reports and traffic.

Common configuration mistakes

• Publishing two SPF records at the same hostname instead of one combined record.
• Copying an SPF include, DKIM key, or selector from another provider.
• Leaving an old sending service authorised after it is retired.
• Publishing DKIM in the wrong hostname or with a truncated key.
• Enforcing DMARC reject before identifying all legitimate senders.
• Assuming authentication fixes poor lists, unwanted content, compromised accounts, or a damaged reputation.

Values must come from the actual email provider and current sending architecture. A record that is correct for one account or vendor is not a universal template.

A safe implementation sequence

1. Inventory every legitimate source that sends using the domain.
2. Publish one valid SPF policy and enable DKIM for each supported sender.
3. Test real messages and inspect authentication results.
4. Publish DMARC in monitoring mode with suitable reporting.
5. Review reports, correct forgotten senders, and then increase enforcement gradually when evidence supports it.

For business context, see why organisations use professional email on their own domain. Authentication supports that identity; it does not replace mailbox security, user training, filtering, or careful sending practices.

Frequently asked questions

Do I need all three?

For a mature domain-email setup, they provide stronger coverage together than separately. Exact support and rollout steps depend on the real provider.

Will DMARC stop every phishing message?

No. It helps protect use of your domain, but attackers can use lookalike domains, compromised accounts, or content that does not impersonate your address directly.