How email authentication works SPF, DKIM, and DMARC explained

The sender address is a claim that needs checking

Writing a company name on an envelope does not prove who posted it. Email has a similar problem: the name and address displayed in your inbox are not enough to establish where a message came from.

It helps to separate two addresses. From is the sender address shown by your mail app. MAIL FROM is used during the transfer between servers, including as the destination for delivery failure notices. In a received message, you can usually find it in the Return-Path header.

A difference does not automatically mean fraud. Your newsletter provider may use its own domain to handle bounced messages. The useful questions are which domain passed authentication, and how it relates to the From domain. Microsoft: email sender addresses ↗

What happens when an email reaches the receiving server?

The company first publishes its authentication information in DNS, the system used to look up information about a domain. This includes the servers allowed to send, the public keys used to check signatures, and a policy for messages that fail DMARC.

When a message arrives, the receiving server looks up those records. It checks SPF and DKIM, then uses DMARC to connect a passing result to the visible From domain.

The receiver then applies its own security rules as well as considering the domain owner's DMARC policy. Authentication can pass and the message can still go to spam. A DMARC failure can also receive different treatment where the receiver has a justified exception. How the DMARC standard describes this process ↗

SPF checks the server handing over the message

SPF is a list of servers authorized to send for a domain. If Google Workspace sends your company's email, your SPF record normally includes Google's published sending policy.

The distinction matters: SPF normally checks the MAIL FROM domain, not the From address the reader sees. Someone can configure SPF correctly for a domain they own, then put your address in the visible From field. SPF might pass, but it has authenticated their domain.

Forwarding can cause the opposite problem. The final receiver sees the forwarding server's IP instead of the original sender's. If the message keeps its original MAIL FROM and that new IP is not authorized, a legitimate message can fail SPF. The SPF standard ↗

DKIM checks a digital signature attached to the email

With DKIM, the sending system signs selected parts of a message using a private key. The receiving system checks that signature with a matching public key published in DNS.

In the signature, d=example.com identifies the signing domain. A selector such as s=google tells the receiver which public key to look up.

DKIM does not encrypt the message. It also does not establish that a particular employee wrote it or that its attachment is safe. It establishes which domain has a valid signature on the message. The DKIM standard ↗

DMARC connects authentication to the visible sender domain

SPF can authenticate a sending server and DKIM can authenticate a signature, but neither result helps establish your company's involvement if it belongs to an unrelated domain.

DMARC adds a comparison: does the domain that passed authentication align with the From domain? That relationship is called domain alignment.

The default, relaxed alignment (r), allows domains within the same organizational domain: for example, example.com and mail.example.com in a typical company setup. Strict alignment (s) requires an exact domain match. A separate domain with a similar spelling does not qualify under either mode.

Although one aligned path is enough for DMARC, configure both SPF and DKIM wherever your sending service supports them. Forwarding and other changes can affect them differently. Mailbox providers may also have sender requirements that go beyond the minimum DMARC pass condition. Microsoft: DMARC and alignment ↗

Compare four messages, not just four PASS labels

Choose a scenario below to see why the domain next to PASS matters as much as the result itself.

A newsletter can pass DMARC through a valid company-domain DKIM signature even when its SPF domain differs. In the impersonation example, both SPF and DKIM pass for an unrelated domain. Neither establishes a connection to the company shown in From, so DMARC fails.

Policies request a response; reports show what receivers observed

A DMARC record includes the domain owner's requested handling for messages that fail. The p= setting selects that policy.

The receiver makes the final handling decision. p=none does not guarantee acceptance, and p=reject cannot block every form of impersonation. Policy choice also depends on the domain's use: the current standard recommends against rejection for general-purpose email because legitimate indirect mail can lose authentication. DMARC policy values ↗ General-purpose email considerations ↗

For a domain that does use p=reject, the standard requires valid DKIM signatures and rules out relying solely on SPF. Receivers must also consider other evidence before rejecting; without that additional analysis, they must treat the failure as quarantine.

RUA reports help you find missing or misconfigured senders

The rua= setting supplies an address for aggregate reports. Participating receivers summarize the messages they observed, including source IPs, message counts, and authentication results.

Those 200 failures are not evidence of 200 spoofed emails. The newsletter may be legitimate mail with an incomplete setup. Compare the report with the services your business actually uses before assigning a cause.

RUA reports cover what reporting receivers observed. They are not a complete sending log, real-time alerts, copies of messages, or proof that mail reached an inbox. The DMARC aggregate reporting standard ↗

Start by listing everything that sends for your company

Employee mail is only part of the picture. Website replies, order notifications, password resets, newsletters, and support tools may all use your domain. Identify those services and the people responsible for them before tightening a policy.

1. Build a sender inventory

   Record employee email, marketing, CRM, support, billing, and automated notifications. Include each service owner and the From addresses it uses.

2. Configure SPF and DKIM for each service

   Use the DNS values issued by that service. Publishing a DKIM key may also require enabling signing in the provider's control panel.

3. Start DMARC monitoring and report review

   Check real messages for authentication and alignment. Compare report sources with your inventory to find gaps.

4. Choose a policy after resolving legitimate failures

   Include infrequent mail such as month-end invoices and the domain's indirect-mail needs. Rejection is not appropriate for every domain. Repeat the checks whenever a new service starts sending.

Name: _dmarc
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; adkim=r; aspf=r

A passing result still leaves some questions unanswered

Email authentication helps receivers identify unauthorized use of your domain. Other forms of fraud need other controls.

• A different domain with a similar nameAn attacker can authenticate a domain they own. Check the full address rather than relying on the display name.
• A compromised legitimate accountMail sent through your authorized service may pass authentication. Account security and login monitoring still matter.
• A fraudulent payment request or unsafe attachmentAuthentication does not approve a bank-account change or inspect a file for you. Verify sensitive requests through an established contact.