What Are SPF, DKIM, and DMARC? Step-by-Step Setup for Stronger Email Security

SPF stands for Sender Policy Framework. It’s a DNS-based standard that lets a domain owner list the mail servers allowed to send email on behalf of that domain. 

When a message arrives, the receiving mail server checks the sending IP address against the SPF TXT record in DNS. The receiving server then returns an SPF result based on whether the IP is authorized by the published record. 

SPF has a few limits worth knowing. It checks the Return-Path address, not the visible From header that people see in their inbox. It can also break when messages are forwarded, because the forwarding server’s IP may not be in the original SPF record. And SPF records have a 10 DNS lookup limit, which can cause issues for organizations that use many third-party sending services.

DKIM stands for DomainKeys Identified Mail. It uses public-key cryptography to prove that a message was sent by an allowed domain and wasn’t changed in transit. 

When an email is sent, the sending server adds a digital signature to the message header using a private key. The matching public key is stored in a DNS TXT record under a DKIM selector. The receiving server looks up that public key and checks the signature. If the signature is valid, it confirms that the signed content was not altered and that the signing domain authorized the signature. 

DKIM often survives mail forwarding better than SPF because the signature stays with the message as long as signed content is not modified. That makes it a strong signal for DMARC alignment, which we will cover next.

DMARC stands for Domain-based Message Authentication, Reporting, and Conformance. It builds on SPF and DKIM by adding two things that—neither standard provides on its own: domain alignment and policy control. 

Domain alignment means DMARC checks whether the domain used by SPF or DKIM matches the visible From address that people see in their inbox. This step matters because SPF and DKIM can technically pass while using a different domain than the one shown to the reader. 

DMARC also lets domain owners publish a policy that tells receiving mail servers what to do when a message fails both SPF and DKIM alignment. The three policy options are p=none (monitor only, take no action), p=quarantine (send failures to spam), and p=reject (block failures). DMARC also provides reporting, so domain owners can see who is sending email using their domain and where checks are failing. 

Published in May 2026, DMARC RFC 9989 replaced RFC 7489 and moved DMARC from an Informational RFC to the Internet Standards Track. The core SPF and DKIM alignment model remains, but the updated standard clarifies how receivers discover organizational domains and apply policy.  

RFC 9989 also changes domain and policy discovery and introduces tags for organizational-domain boundaries, non-existent subdomains, and testing. See the technical guide to the new DMARC tags for implementation details. 

SPF, DKIM, and DMARC are not competing standards. They are meant to work as a set, with each one handling a different part of the problem.

SPF checks the sending server. DKIM verifies a message signature. DMARC evaluates alignment and tells receivers how to handle messages that fail.

When a message moves from sender to receiver, SPF, DKIM, and DMARC each play a role in the check. Here is how the process works:

1. The sender's mail server sends the message.
2. The receiving mail server checks the sending IP against the sender's SPF record in DNS.
3. The receiving server also checks the DKIM signature by looking up the public key stored under the DKIM selector in DNS.
4. DMARC then checks alignment: does the domain that passed SPF or DKIM match the visible From address?
5. Based on the DMARC policy (none, quarantine, or reject), the receiver handles the message.
6. The receiver sends aggregate reports back to the domain owner, showing which messages passed and which failed. 

DMARC passes when either SPF authentication and alignment or DKIM authentication and alignment passes. It does not require both. But organizations should configure both SPF and DKIM because SPF can fail on forwarded email, while DKIM may continue to validate.

Without properly configured SPF, DKIM, and DMARC, attackers can more easily send email that appears to come from your domain. Attackers use this weakness to run phishing campaigns, business email compromise (BEC) schemes, and domain spoofing attacks that damage customer trust and cost money. 

As a result, mailbox providers now expect stronger authentication from senders. Google and Yahoo began requiring SPF, DKIM, and DMARC for bulk senders in February 2024. Microsoft followed in May 2025. Requirements and enforcement practices continue to evolve, so senders should review current guidance from each mailbox provider. 

Beyond security, SPF, DKIM, and DMARC also help with email deliverability. Messages that pass all three checks are more likely to reach the inbox, while messages that fail are more likely to be filtered or blocked.

A careful, staged setup helps reduce the risk of disrupting legitimate mail. Keep in mind that moving too fast can block valid mail, but moving too slowly can leave the domain exposed. The goal is to gain visibility, fix gaps, and then move toward enforcement with confidence. 

1. Take stock of every sender

Before making any DNS changes, list every service that sends email on behalf of your domain. This includes your main mail platform (such as Microsoft 365 or Google Workspace), along with CRM tools, marketing platforms, HR systems, billing services, ticketing systems, and any third-party providers. Missing even one sender can cause DMARC failures for valid mail.

2. Publish or update your SPF record

Create a single SPF TXT record in DNS that lists all allowed sending services for your domain. Watch for the 10 DNS lookup limit. If you use many third-party senders, you can hit this cap quickly. Remove old or unused entries to keep the record clean.

3. Enable DKIM signing for each sender

For each service that sends on your behalf, set up DKIM signing. This means creating a key pair, publishing the public key as a DNS TXT record under a DKIM selector, and turning on signing in the sending service. Use a 2048-bit key where the sending service supports it.

4. Publish a DMARC record in monitoring mode 

Add a DMARC TXT record to DNS with a policy of p=none. This lets you monitor DMARC results without asking receiving mail servers to quarantine or reject messages that fail. Include a rua tag so aggregate reports are sent to an address you monitor.

5. Review reports and fix failures

Use the DMARC reports to find senders that fail SPF, DKIM, or alignment. Some of these may be services that you forgot to include in your SPF record or that need DKIM set up. Fix each gap before tightening the policy.

6. Move to quarantine, then reject

Once all valid senders pass SPF, DKIM, and DMARC, move the policy to p=quarantine. Monitor reports again to catch any remaining issues. When you are confident, move to p=reject. This asks receivers to reject messages that fail DMARC.

7. Consider BIMI after enforcement

Brand Indicators for Message Identification (BIMI) lets a domain publish a logo that supporting mailbox providers may display beside authenticated messages. BIMI builds on DMARC and generally requires an enforcement policy of p=quarantine or p=reject. Review the BIMI implementation requirements before publishing a BIMI record.

8. Maintain records over time

SPF, DKIM, and DMARC records require ongoing maintenance. Review them whenever you add or remove a vendor, launch a new email tool, change domains, or go through a merger. Stale records can lead to failed checks and blocked legitimate mail.

9. Consider hosted authentication services

Large organizations may use hosted authentication services to manage SPF, DKIM, and DMARC records, normalize reports, identify sending sources, and reduce the operational burden of ongoing changes. These services can be useful when many business units, domains, and third-party platforms send email on the organization’s behalf.

Even after setup, teams run into common issues. These include:

• Outdated SPF records with old vendors still listed
• Exceeding the SPF 10 DNS lookup limit
• Missing DKIM setup for third-party senders
• DKIM key rotation gaps that leave old keys in place too long
• Misaligned From domains that cause DMARC failures on valid mail
• Staying on p=none forever without moving toward enforcement 

There is also a key limit to keep in mind. DMARC protects your exact domain from spoofing, but it doesn’t cover every attack method. Lookalike domains (such as "yourc0mpany.com" instead of "yourcompany.com"), display-name spoofing, and email from compromised supplier accounts can all bypass DMARC. These threats require additional defenses beyond SPF, DKIM, and DMARC.

Stronger SPF, DKIM, and DMARC setup can reduce the risk of attackers using your domain to send fake messages. It can help protect the trust customers, partners, and employees place in your domains. It can also support deliverability by helping mailbox providers authenticate legitimate business messages. 

Just as important, authentication gives teams clearer data about who is sending email on behalf of the organization. That visibility can support governance conversations, risk reviews, audits, cyber insurance discussions, and board-level updates. Security leaders can show that the organization has active controls for sender identity, a path to enforcement, and reporting that supports ongoing management. 

None of these outcomes are guaranteed. But moving toward DMARC enforcement is an important step teams can take to strengthen trusted email communication.

SPF, DKIM, and DMARC are part of a larger email identity trust layer. They help verify that a sending domain authorized a message and that signed message content has not been altered. 

That’s why authentication is essential. It helps verify legitimate senders and reduce direct domain spoofing. But modern email fraud can also involve lookalike domains, supplier impersonation, compromised partner accounts, display-name spoofing, and reply-to pivots. 

Proofpoint Email Fraud Defense helps organizations streamline DMARC implementation, manage hosted authentication, see sources of email that use trusted domains and lookalikes, and understand supplier-related risk. This can give teams a more controlled path toward enforcement while helping legitimate mail continue to flow. 

Learn more about Proofpoint Email Fraud Defense.