SPF, DKIM and DMARC: How Email Authentication Works

SPF, DKIM and DMARC help receiving email systems check whether a message is authorized to use a domain. They address different parts of that check: the sending server, a digital signature and the relationship to the address a reader sees.

SPF identifies authorized sending sources. DKIM signs a message using a domain. DMARC connects the authentication result to the visible From domain and publishes a handling policy for failures. Together, they help reduce unauthorized use of your domain. They do not establish that a request, attachment or payment instruction is trustworthy.

What each standard checks

A business may send email through Microsoft 365, an invoicing application, a newsletter service and a booking system. Each sending route needs consideration. A setting that works for staff email does not automatically establish the correct identity for every other service.

Microsoft's email authentication overview explains how these checks fit together, including the distinction between a message's transport envelope and its visible contents.

SPF checks where the email came from

SPF stands for Sender Policy Framework. Email delivery uses an envelope-sender address during the conversation between mail servers. This is often called the MAIL FROM address. It can also appear as the Return-Path after delivery. The From address an employee sees in Outlook is a separate field.

An SPF record is published in DNS (the Domain Name System), which holds public records about domain names. It identifies the sources authorized to send using that envelope domain. The receiving system compares the sending server with those published permissions.

For example, an invoice service may display your business address while using its own domain for bounced messages. Its SPF check can pass for that service's domain. That pass alone does not prove it is authorized to use your domain in the visible From address.

Maintaining SPF involves keeping track of legitimate senders and removing obsolete permissions. Multiple competing SPF records for the same domain or excessive DNS lookups can cause errors. Adding a service's suggested record without reviewing what already exists can disrupt other mail. Microsoft's SPF guidance describes the record structure and sending-domain considerations.

DKIM adds a domain signature

DKIM stands for DomainKeys Identified Mail. The sending system uses a private key to sign selected headers and message content. The receiving system looks up the corresponding public key through DNS and checks that signature. A valid result associates the signed message with the signing domain and shows that the covered parts survived verification.

The signature contains a signing-domain value, commonly identified as d=. A service might sign using its own domain or a domain belonging to its customer. The distinction matters when DMARC checks whether that identity matches the visible sender.

DKIM does not encrypt the email. It also does not verify that a human reviewed the message, that the attachment is safe or that the sender's account has not been compromised. Changes to signed content during delivery can affect validation. Microsoft's DKIM documentation explains signature verification and custom-domain configuration.

DMARC asks whether the authenticated identity matches the sender

DMARC stands for Domain-based Message Authentication, Reporting and Conformance. Its key concept is alignment. The domain authenticated through SPF or DKIM must have the required relationship to the domain in the visible From address. Depending on the configured alignment mode, that can require an exact match or allow a relationship within the same organizational domain.

A message passes DMARC when at least one path succeeds: SPF passes and aligns, or DKIM passes and aligns. Both can pass, but both are not required. A successful SPF check for an unrelated service domain is insufficient by itself.

Forwarding helps explain why the two paths matter. Forwarding can cause SPF to fail because the final receiving system sees a different sending server. An intact, aligned DKIM signature may still provide a passing DMARC path. Other message changes can affect DKIM too. A failed check needs investigation rather than an assumption that every forwarded message is fraudulent. The DMARC standard, RFC 9989, defines alignment and the receiver's handling choices.

What none, quarantine and reject mean

A domain's DMARC policy states its requested treatment of messages that fail DMARC. The receiving organization also applies its own filtering and handling decisions.

• None: no DMARC-specific change in handling is requested. Other security filtering still applies.
• Quarantine: the domain requests that failures be treated with suspicion, such as placement in a junk or quarantine area.
• Reject: the domain requests rejection of messages that fail.

A domain can publish a policy and request reports about authentication results. Aggregate reports summarize sending sources and results from participating receivers. They can reveal both misconfigured business services and unauthorized use. Someone needs to review unfamiliar sources and determine whether a configuration change or further investigation is needed.

Monitoring with p=none can help identify legitimate senders before a stricter policy is introduced. It does not itself request that DMARC failures be blocked. Enforcement changes should follow a review of real sending routes and results, including services used only occasionally. See Microsoft's DMARC guidance for policy and reporting details.

Authentication and inbox delivery are different questions

A message can pass authentication and still land in junk. Receivers consider additional signals, including sending reputation and recipient complaints. Google's sender guidelines, for example, describe authentication alongside other requirements for mail sent to personal Gmail accounts. Passing one check does not satisfy the entire delivery process.

An attacker can also register a similar-looking domain and authenticate messages from that domain correctly. A compromised real mailbox can send authenticated fraudulent requests. Neither situation requires the attacker to forge your exact domain. Authentication therefore works alongside filtering, account protection and the way staff verify unusual requests. Our business email phishing reference covers those wider protections.

What a business should be able to confirm

A useful authentication record identifies every service sending on the business's behalf, the domains it uses and who maintains it. Evidence should include actual message results from each route, rather than only a screenshot showing that DNS records exist.

New software, website forms, marketing tools and billing systems can add sending routes. Changes of provider can leave old permissions behind. Keeping that record current makes later delivery problems easier to investigate and reduces the chance of enforcing a policy against a legitimate sender that nobody remembered.

For related background, read how account authentication differs from access policy. DreamMSP's cybersecurity services describe the separate work of configuring and maintaining business protections.