DMARC, SPF, and DKIM Email Authentication Explained

Email authentication is the technical foundation for stopping one specific kind of phishing: mail that forges your organization’s exact domain in the From address. Three protocols work together. SPF and DKIM let receiving servers check whether a message was sent with the domain owner’s authorization, and DMARC ties those checks to the domain the reader actually sees and tells receivers what the owner wants done when the checks fail.

Mailbox providers now require it from large senders. Since February 2024, Google and Yahoo have required bulk senders (Google’s threshold is more than 5,000 messages a day to Gmail accounts) to authenticate with SPF and DKIM and publish a DMARC policy of at least p=none (Google; Yahoo). Microsoft added similar requirements for domains sending more than 5,000 messages a day to Outlook and, after an April 29, 2025 update, said non-compliant messages would be rejected from May 5, 2025 (Microsoft). Note that these rules require a DMARC record, not enforcement; protection against spoofing only begins at p=quarantine or p=reject.

The US government has pushed further. NIST SP 800-177 Rev. 1, Trustworthy Email (February 2019), recommends SPF, DKIM and DMARC for federal systems and notes the guidance is also useful for small and medium-sized organizations (NIST). CISA’s Binding Operational Directive 18-01 (October 2017) required federal civilian agencies to set DMARC to “reject” for all second-level domains and mail-sending hosts within one year (CISA), and a May 2024 FBI, State Department and NSA advisory urged organizations to move from p=none to p=quarantine or p=reject after North Korean actors exploited weak DMARC policies in spearphishing (joint advisory).

The DMARC standard itself was updated in May 2026: RFC 9989 is now a Standards Track specification and obsoletes the earlier informational RFC 7489, with reporting defined separately in RFC 9990 (aggregate reports) and RFC 9991 (failure reports).

How the Three Protocols Work Together

SPF (Sender Policy Framework)

SPF lets a domain owner publish a DNS record listing the servers authorized to send mail for the domain. When a receiving server gets a message, it checks the SPF record of the domain used in the SMTP envelope (the Return-Path, or MAIL FROM address). If the sending server’s IP address is authorized, SPF passes; if not, it fails.

Limitation: SPF checks the envelope sender, not the From header that people see. An attacker can pass SPF with their own domain while displaying yours in the From line. SPF also breaks when mail is forwarded, because the forwarding server is not in your record.

DKIM (DomainKeys Identified Mail)

DKIM adds a cryptographic signature to outgoing messages. The sending system signs the message with a private key, and the receiver verifies the signature with the public key published in the signing domain’s DNS.

A valid DKIM signature shows that the signing domain took responsibility for the message and that the signed parts were not altered in transit.

Limitation: the signing domain can differ from the From domain. An attacker can sign mail with their own domain while impersonating yours.

DMARC (Domain-based Message Authentication, Reporting, and Conformance)

DMARC closes that gap with alignment: it checks that the domain in the From header matches a domain that passed SPF or DKIM. The domain owner’s DMARC record then states how failing mail should be handled:

DMARC policy	Requested handling of failing mail	Typical use
`p=none`	No special handling; reports still sent	Monitoring
`p=quarantine`	Treat as suspicious, typically the spam or junk folder	Transition
`p=reject`	Reject the message	Full enforcement

The policy is a request: RFC 9989 describes it as information receivers “can use” when deciding how to handle mail, so outcomes depend on receivers honoring it.

DMARC aggregate reports, sent to the address in your rua tag, show which servers are sending mail using your domain, both your legitimate services and anyone spoofing you.

Implementation Roadmap

Step 1: Inventory Your Email Senders

Before setting any policy, list every system that sends mail using your domain: your mail platform, marketing tools, CRM, ticketing and billing systems, and third-party services. Any legitimate sender you miss will fail DMARC once you enforce.

Step 2: Implement SPF

Publish a TXT record such as:

v=spf1 include:_spf.google.com include:sendgrid.net ~all

This example authorizes Google Workspace and SendGrid. The final mechanism tells receivers what to do with other senders: ~all is a soft fail and -all a hard fail. RFC 9989 (Section 7.1) warns that some receivers apply SPF before DMARC, so a -all hard fail can get a message rejected before DMARC is evaluated, even if it would have passed DMARC through an aligned DKIM signature, and such rejections never appear in DMARC reports. If you use -all, do so knowingly; with DMARC at enforcement, ~all lets DMARC make the decision.

SPF allows at most 10 DNS lookups. Organizations with many sending services may need to consolidate includes or restructure their record.

Step 3: Implement DKIM

Turn on DKIM signing in every sending system. Each system generates a key pair, and you publish the public key as a DNS record under a selector the system gives you. Most email providers handle this through their admin consoles. Use RSA keys of at least 2048 bits where supported; RFC 8301 says signers “SHOULD use RSA keys of at least 2048 bits” and must not go below 1024.

Step 4: Publish DMARC at p=none

Start in monitoring mode to collect reports without affecting delivery:

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

Review reports for several weeks, long enough to cover monthly cycles such as invoicing and payroll. Fix any legitimate sender that fails alignment. Failure (ruf) reports are optional for receivers under the standard, so do not rely on them.

Step 5: Move to p=quarantine

Once legitimate senders pass, move to quarantine:

v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com

Watch for legitimate mail landing in spam and fix the causes. Under RFC 9989, the old pct tag for applying a policy to a percentage of mail has been removed; a new t=y test flag asks receivers to apply one level less than the stated policy while you test.

Step 6: Enforce p=reject

At full enforcement, receivers that honor DMARC reject unauthenticated mail claiming to be from your domain:

v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com

This is the policy BOD 18-01 required of federal agencies. It stops attackers from spoofing your exact domain to your customers, partners and employees.

Impact on Phishing Defense

What DMARC at reject prevents (at receivers that enforce it):

Spoofing of your exact domain in the From address
Brand impersonation and executive impersonation that rely on forging your exact domain

What DMARC does not prevent:

Lookalike domains such as examp1e.com, because the attacker controls authentication for their own domain
Display-name impersonation, where the attacker shows “CEO Name” from an unrelated address
Mail from compromised legitimate accounts, including your own or a supplier’s, which passes authentication
Spoofing of other organizations’ domains that have not published an enforcing policy

The 2024 advisory’s example shows both sides. The actor sent from a compromised university account, so SPF and DKIM passed for the university’s domain; DMARC failed because the From address used a think tank’s domain; and the message reached the inbox only because the think tank’s policy was p=none. An enforcing policy would have given receivers grounds to block it, but it would not have helped if the actor had used a lookalike domain or the think tank’s own compromised account. That is why DMARC alone does not stop business email compromise. Combine DMARC with email filtering, MFA, payment-verification procedures and security awareness training.

Analyzing DMARC Reports

Aggregate reports arrive as XML files that are hard to read raw. Options include:

Postmark DMARC, which offers a free weekly email digest
Google Postmaster Tools, whose dashboards show data on mail you send to personal Gmail accounts, including message authentication, spam rate and delivery errors
Commercial DMARC management services, which add alerting and help with sender inventory

To read authentication results in individual messages, see our email header analysis guide.

Common Implementation Mistakes

Staying at p=none indefinitely. Monitoring gives visibility but no protection against spoofing
Missing legitimate senders. Their mail fails once enforcement begins
Not reading reports. Reports reveal configuration problems and spoofing attempts
Weakening subdomains by accident. If sp is absent, subdomains inherit the p policy; setting sp=none leaves them open, and the new np tag covers non-existent subdomains
Exceeding the SPF lookup limit. Too many lookups cause SPF errors, which can make DMARC fail
Forgetting non-sending domains. Parked domains can be spoofed too; publish v=spf1 -all and a DMARC reject policy for them

Key Takeaways

SPF, DKIM and DMARC together let receivers detect mail that forges your exact domain
DMARC at p=reject is the target state; the provider rules for bulk senders only require p=none
RFC 9989 (May 2026) replaces RFC 7489, removes pct and adds a t test flag
Roll out in phases (none, quarantine, reject) and take as long as your sender inventory requires
DMARC does not stop lookalike domains, display-name tricks or compromised accounts, so it is one layer, not the whole defense
Aggregate reports show who is sending as your domain

For the complete phishing defense framework, see our phishing recognition and reporting guide.

Sources

This content is for educational purposes only. Email authentication implementation involves DNS changes that can affect email delivery. Test thoroughly in monitoring mode before enforcing policies.