SPF, DKIM and DMARC Explained

Editorial Team·22 days ago

019513 minutes read

Quick answer: SPF, DKIM, and DMARC are three DNS-based email authentication standards that work together to prevent email spoofing. SPF specifies which servers can send email for a domain; DKIM adds a cryptographic signature to verify message integrity; DMARC ties them together and defines what to do with messages that fail — and provides reporting so domain owners can monitor authentication results.

"Someone Is Sending Emails From My Domain" — Why Email Authentication Exists

A scenario that domain owners encounter with some regularity: a contact reports receiving a suspicious email that appears to come from the domain, but the domain owner never sent it. Or a business discovers that its domain is being used in phishing campaigns targeting its customers. The underlying problem is that the original email protocol (SMTP) has no built-in mechanism for verifying that a message actually comes from the domain it claims to come from — any server can send a message with any From address. SPF, DKIM, and DMARC were developed to address this gap. This guide explains what SPF, DKIM, and DMARC are, how each one works, how they interact with each other, and how to deploy them correctly. Email authentication standards and provider requirements evolve over time; the details here reflect current standards and requirements as of mid-2026, and verifying current requirements with the relevant providers before implementing is recommended.

How SPF, DKIM, and DMARC Work Together

The three standards address different aspects of email authentication and are designed to be used together. SPF answers the question: "Is this message coming from a server that is authorized to send email for this domain?" DKIM answers the question: "Has this message been signed by an authorized server, and has the content been altered since it was signed?" DMARC answers the question: "What should be done with messages that fail SPF or DKIM, and does the From header domain match the domain that passed authentication?" A message passes DMARC if it passes either SPF with alignment or DKIM with alignment. Alignment means that the domain in the From header (the address visible to the recipient) matches the domain that passed the authentication check — this is the key mechanism that prevents attackers from passing SPF on a different domain while spoofing the From header. DMARC without alignment would not prevent the most common spoofing attacks.

SPF, DKIM, and DMARC — 5 Key Concepts Explained

StandardDNS Record TypeWhat It VerifiesAlignment Required for DMARCSPFTXT (on the domain)Sending server IP is authorizedEnvelope sender domain matches From domainDKIMTXT (on selector subdomain)Message signed by authorized server; content unalteredd= tag domain matches From domainDMARCTXT (on _dmarc subdomain)SPF or DKIM passes with alignment; defines policyN/A (DMARC is the alignment enforcer)DMARC p=none—Monitor only — no action on failuresStarting point for deploymentDMARC p=reject—Block messages that fail authenticationEnd goal after validating all legitimate senders

1. SPF — Sender Policy Framework

SPF is a DNS TXT record published on a domain that lists the mail servers authorized to send email on behalf of that domain. The record is published at the root of the domain (e.g., example.com) and uses a specific syntax. A typical SPF record for a domain that sends email through Google Workspace looks like: v=spf1 include:_spf.google.com ~all. The include: mechanism delegates authorization to Google's SPF record, which lists Google's mail server IP ranges. The ~all at the end is a soft fail — messages from servers not listed in the SPF record should be treated with suspicion but not necessarily rejected. Using -all (hard fail) is more strict but can cause deliverability problems if any legitimate sending source is not included in the SPF record. A common SPF configuration mistake is having multiple SPF records on the same domain — only one SPF TXT record is permitted per domain. Multiple records cause an SPF permerror, which results in SPF failure. If email is sent through multiple services (e.g., Google Workspace for regular email, a marketing platform for bulk email, and a transactional email service), all authorized senders must be included in a single SPF record using multiple include: mechanisms. SPF also has a lookup limit of 10 DNS lookups — exceeding this limit causes an SPF permerror.

2. DKIM — DomainKeys Identified Mail

DKIM adds a cryptographic digital signature to outgoing email messages. The sending mail server signs the message using a private key; the corresponding public key is published as a DNS TXT record on the sending domain at a selector subdomain (e.g., google._domainkey.example.com). When a receiving mail server receives the message, it retrieves the public key from DNS and uses it to verify the signature in the DKIM-Signature header. A valid signature confirms that the message was sent by a server with access to the private key (i.e., an authorized server for that domain) and that the signed portions of the message have not been altered in transit. DKIM is configured on the sending mail server or email service — the process varies by provider. For Google Workspace, DKIM signing is enabled in the Google Admin console under Apps > Google Workspace > Gmail > Authenticate email. For Microsoft 365, DKIM is configured in the Microsoft 365 Defender portal under Email & Collaboration > Policies & Rules > Threat Policies > DKIM. Most email service providers (ESPs) for bulk and transactional email provide DKIM signing as part of their service and provide the DNS records to publish. The recommended key length is 2048-bit RSA; 1024-bit keys are considered weak by current standards.

3. DMARC — Domain-based Message Authentication, Reporting, and Conformance

DMARC is a DNS TXT record published at _dmarc.example.com that specifies a policy for messages that fail SPF and DKIM authentication, and provides a reporting mechanism. A basic DMARC record looks like: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com. The p= tag specifies the policy: none (monitor only), quarantine (send to spam), or reject (block). The rua= tag specifies where aggregate reports should be sent — these reports, sent daily by receiving mail servers, show authentication results for all messages claiming to be from the domain. DMARC alignment is the mechanism that makes DMARC effective against spoofing. For SPF alignment, the domain in the MAIL FROM (envelope sender) must match the domain in the From header. For DKIM alignment, the domain in the DKIM d= tag must match the domain in the From header. A message passes DMARC if it passes either SPF with alignment or DKIM with alignment — passing both is not required, but passing at least one with alignment is. This means that even if SPF fails (e.g., because the message was forwarded), DMARC can still pass if DKIM passes with alignment — which is one reason why DKIM is considered more robust than SPF alone for DMARC compliance.

4. The DMARC Deployment Path: p=none → p=quarantine → p=reject

Deploying DMARC directly at p=reject without first analyzing authentication results is a common mistake that can block legitimate email. The recommended deployment path is: start with p=none to collect aggregate reports without affecting mail flow; analyze the reports (using a DMARC report analysis tool or service) to identify all legitimate sending sources and confirm they are passing SPF and DKIM with alignment; move to p=quarantine once confident that legitimate mail is passing; and finally move to p=reject once the quarantine policy has been running without issues for a sufficient period. The time at each stage depends on the complexity of the email sending infrastructure — organizations with many sending services may need weeks or months at p=none to identify all legitimate senders.

5. DMARC Reporting — Aggregate and Forensic Reports

⚠️ DMARC reports are essential for deployment — but require careful handling: DMARC provides two types of reports. Aggregate reports (rua=) are XML files sent daily by receiving mail servers, summarizing authentication results for all messages claiming to be from the domain — they show which servers are sending email, whether SPF and DKIM are passing, and whether DMARC alignment is passing. Forensic reports (ruf=) are per-message failure reports that may include message headers and sometimes message content — many receiving mail servers have stopped sending forensic reports due to privacy concerns, so they are less reliable. Aggregate reports are the primary tool for monitoring DMARC deployment. Because aggregate reports are XML files that can be complex to parse, many organizations use a DMARC report analysis service (such as Postmark's free DMARC analyzer, dmarcian, or Valimail) to visualize the data. Note that DMARC reports sent to the rua= address may contain information about email senders — handle them appropriately.

Step-by-Step: How to Set Up SPF, DKIM, and DMARC

Step 1: Publish an SPF Record

Identify all services that send email on behalf of the domain — the primary mail server (Google Workspace, Microsoft 365, or a self-hosted server), any marketing email platforms, transactional email services, and any other services that send email using the domain. Obtain the SPF include mechanism or IP range for each service from the service's documentation. Combine them into a single SPF TXT record on the domain root. Example for a domain using Google Workspace and a transactional email service: v=spf1 include:_spf.google.com include:sendgrid.net ~all. Verify the record using an SPF lookup tool (mxtoolbox.com/spf.aspx or similar) and confirm it resolves correctly and does not exceed 10 DNS lookups.

Step 2: Enable DKIM Signing

Enable DKIM signing in the email service's admin console. For Google Workspace: Admin console > Apps > Google Workspace > Gmail > Authenticate email > Generate new record, then publish the provided TXT record in DNS. For Microsoft 365: Microsoft 365 Defender portal > Email & Collaboration > Policies & Rules > Threat Policies > DKIM, select the domain, and enable DKIM signing — Microsoft provides the CNAME records to publish in DNS. For other services, follow the provider's DKIM setup documentation. After publishing the DNS records, verify DKIM using a DKIM lookup tool and confirm the signature is valid. Allow up to 48 hours for DNS propagation before testing.

Step 3: Publish a DMARC Record at p=none

Publish a DMARC TXT record at _dmarc.example.com (replace example.com with the actual domain) with a p=none policy and an rua= address to receive aggregate reports: v=DMARC1; p=none; rua=mailto:dmarc@example.com. The rua= address should be a mailbox that can receive and store the reports — or use a DMARC report analysis service and use the address they provide. Verify the record using a DMARC lookup tool. At this stage, no mail is being blocked or quarantined — the record is monitoring only.

Step 4: Analyze DMARC Reports and Fix Authentication Issues

After publishing the DMARC record, aggregate reports will begin arriving within 24–48 hours from major receiving mail servers (Google, Microsoft, Yahoo, and others). Analyze the reports to identify: which servers are sending email for the domain, whether SPF is passing and aligned, whether DKIM is passing and aligned, and whether any legitimate sending sources are failing authentication. For any legitimate sending source that is failing, investigate the cause — missing SPF include, DKIM not configured for that service, or alignment mismatch — and fix it. Continue monitoring at p=none until aggregate reports show that all legitimate mail is passing DMARC.

Step 5: Move to p=quarantine, Then p=reject

Once aggregate reports consistently show that all legitimate mail is passing DMARC, update the DMARC record to p=quarantine. Monitor reports for any legitimate mail that begins going to spam — this may indicate a sending source that was not identified during the p=none phase. After a period of stable operation at p=quarantine (the appropriate duration depends on the organization's email sending complexity and risk tolerance), update the policy to p=reject. At p=reject, receiving mail servers will block messages that fail DMARC authentication — providing the strongest protection against domain spoofing. Continue monitoring aggregate reports after moving to p=reject to catch any new sending sources that need to be authenticated.

Frequently Asked Questions — SPF, DKIM, and DMARC

What are SPF, DKIM, and DMARC?

SPF, DKIM, and DMARC are three DNS-based email authentication standards that work together to prevent email spoofing. SPF specifies which servers can send email for a domain; DKIM adds a cryptographic signature to verify message integrity; DMARC ties them together, defines what to do with failing messages, and provides reporting.

What is an SPF record and how does it work?

An SPF record is a DNS TXT record that lists the mail servers authorized to send email for a domain. Receiving servers check whether the sending server's IP is listed. SPF checks the envelope sender (MAIL FROM), not the From header visible to the recipient. Only one SPF record is permitted per domain; multiple records cause an SPF permerror.

What is DKIM and why is it important?

DKIM adds a cryptographic signature to outgoing messages. The sending server signs with a private key; the public key is published in DNS. Receiving servers verify the signature, confirming the message came from an authorized server and has not been altered in transit. DKIM survives email forwarding better than SPF, making it more robust for DMARC compliance.

What does DMARC do and how do I set it up?

DMARC specifies what to do with messages that fail SPF and DKIM (none / quarantine / reject) and requires alignment between the From header domain and the domain that passed authentication. Deploy in stages: p=none first to collect reports, then p=quarantine, then p=reject after confirming all legitimate mail passes.

What happens if I don't have SPF, DKIM, and DMARC set up?

Without these records, the domain is vulnerable to spoofing — anyone can send email appearing to come from it. Since 2024, Google and Yahoo require bulk senders to have SPF, DKIM, and a DMARC record with at least p=none for reliable inbox delivery. Domains without these records may experience deliverability problems.

Conclusion & My Take

SPF, DKIM, and DMARC are the foundation of email authentication — and deploying all three correctly is one of the most impactful steps a domain owner can take to protect against spoofing and improve deliverability. The standards are complementary: SPF and DKIM each address different aspects of authentication, and DMARC ties them together with alignment enforcement and reporting. None of the three is sufficient on its own. The most common deployment mistake is rushing to p=reject without first analyzing DMARC aggregate reports. The reports reveal legitimate sending sources that may not be obvious — third-party services, legacy systems, or partner organizations that send email on behalf of the domain. Moving to p=reject before identifying and authenticating all legitimate senders can block legitimate mail. The staged deployment path — p=none → p=quarantine → p=reject — exists precisely to prevent this. For domain owners who are new to email authentication, the process can seem complex, but the core steps are straightforward: publish an SPF record, enable DKIM signing in the email service, publish a DMARC record at p=none, analyze the reports, fix any authentication issues, and then gradually tighten the policy. The investment in setup pays off in reduced spoofing risk and improved deliverability.