What Are SPF, DKIM, and DMARC?

If you have ever set up a custom email address on your own domain, you have probably encountered three acronyms that look technical but are not especially complicated once you understand what they are actually doing. SPF, DKIM, and DMARC are email authentication standards. They exist to solve one of the oldest problems on the internet: anyone can send an email claiming to be anyone else.

Together, these three standards form a system that tells receiving mail servers whether an email claiming to come from your domain was actually sent by you. Without them, spammers and phishers can send email that appears to come from your domain with no technical barrier stopping them. With them, those same emails get rejected, quarantined, or flagged before they reach anyone’s inbox.

This guide explains what each standard does, how they work together, and how to set them up for your own domain.

Why Email Authentication Exists

Email was designed in the 1970s with no built-in mechanism for verifying who sent a message. The “From” address in an email is just a piece of text. Nothing in the original email protocols prevents someone from typing any address they like into that field and sending the message. This is called email spoofing, and it has been used for decades to impersonate businesses, governments, and individuals.

The problem is significant enough that it affects legitimate email too. If someone sends phishing emails pretending to be your business, your customers may get tricked. Your domain’s reputation suffers. Future legitimate emails from your domain may start landing in spam folders even when you sent them properly.

SPF, DKIM, and DMARC were developed over several decades as progressively more complete solutions to this problem. SPF came first, in the early 2000s. DKIM followed in 2004. DMARC, which ties the other two together into an enforceable policy, arrived in 2012. Each one addresses a different aspect of the problem. Used together, they give receiving mail servers a reliable way to verify that your email is genuinely from you.

Understanding them properly also helps you diagnose delivery problems when legitimate emails end up in spam. Missing or misconfigured authentication records are among the most common causes of email deliverability issues for businesses using custom domains.

What Is SPF (Sender Policy Framework)?

SPF is the simplest of the three standards to understand. It answers one question: which mail servers are allowed to send email on behalf of your domain?

You publish the answer as a DNS record on your domain. The SPF record is a TXT record that lists the IP addresses or mail server hostnames that are authorised to send email from your domain. When a receiving mail server gets an email claiming to come from your domain, it checks your DNS records, finds your SPF record, and verifies whether the server that sent the email is on the approved list.

Here is what a typical SPF record looks like:

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

Breaking that down: v=spf1 identifies this as an SPF record. include:_spf.google.com says that Google’s mail servers are authorised (used if you send email through Google Workspace). include:sendgrid.net says SendGrid is also authorised (used if you send marketing email through SendGrid). The ~all at the end is a softfail: anything sent from a server not on the list should be treated with suspicion but not automatically rejected.

The alternative endings are: -all (hard fail: reject anything not on the list) and +all (pass everything, which defeats the purpose). Most configurations use ~all while setting up or -all once you are confident the record covers every legitimate sending source.

SPF Limitations

SPF has one significant limitation: it checks the envelope sender (the technical “from” address used during the mail transfer process), not the “From” header that you see in your email client. These can be different. Someone can craft an email where the envelope sender passes SPF but the visible “From” address still shows your domain. This is why SPF alone is not sufficient and why DKIM and DMARC exist alongside it.

SPF also has a 10-lookup limit. If your SPF record includes too many third-party services, each of which has its own nested includes, you can exceed this limit and cause legitimate email to fail SPF. This is a common misconfiguration for businesses using multiple email platforms simultaneously.

What Is DKIM (DomainKeys Identified Mail)?

DKIM uses cryptography to prove that an email was sent by someone who controls your domain and that the message content was not altered in transit. It works by adding a digital signature to every outgoing email.

Here is how it works. When you set up DKIM, your email provider generates a pair of cryptographic keys: a private key and a public key. The private key is stored on the mail server that sends your email. The public key is published in your DNS records as another TXT entry, typically at a subdomain like mail._domainkey.yourdomain.com.

When your mail server sends an email, it uses the private key to generate a unique signature from the email’s headers and body. That signature is added to the email as a header. When the receiving mail server gets the email, it looks up your public key in DNS, uses it to verify the signature, and checks that the email content matches what was signed. If the signature is valid and the content has not been altered, DKIM passes.

A typical DKIM public key record in DNS looks like this:

mail._domainkey.yourdomain.com TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkq..."

The mail prefix is the selector, which identifies which key to use (you can have multiple DKIM keys with different selectors for different sending services). The long string after p= is the public key itself.

What DKIM Proves and What It Does Not

DKIM proves two things: that the domain named in the DKIM signature has authorised the email, and that the email content has not been modified since it was signed. It does not prove that the visible “From” address matches the signing domain. That alignment check is what DMARC handles.

DKIM signatures survive email forwarding, which SPF does not. When an email is forwarded from one server to another, the originating IP address changes and SPF fails. The DKIM signature travels with the email and remains verifiable as long as the content has not been modified. This is one reason DKIM is considered more robust than SPF for proving authenticity.

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

DMARC is the policy layer that ties SPF and DKIM together into something actionable. It answers the question: what should receiving mail servers do when an email fails SPF or DKIM checks?

Before DMARC, even if SPF and DKIM were in place, mail servers had no standardised instruction for what to do with a failing message. Each server handled failures in its own way. DMARC gives domain owners the ability to publish a policy that tells receiving servers exactly what to do: monitor failures and report them, move failing messages to spam, or reject them outright.

DMARC also adds an alignment check. For DMARC to pass, either SPF or DKIM must pass, and the domain used by the passing check must align with the “From” header domain that the recipient sees. This closes the gap that SPF alone leaves open, where the envelope sender passes SPF but the visible From address is spoofed.

The Three DMARC Policy Levels

DMARC policies are published as a DNS TXT record at _dmarc.yourdomain.com. The policy tag (p=) has three possible values:

• p=none: Monitor mode. Failing messages are delivered as normal. DMARC reports are sent to the address you specify so you can see what is happening without affecting delivery. Use this first while you are setting up and verifying your configuration.
• p=quarantine: Failing messages are moved to the recipient’s spam or junk folder rather than being delivered to the inbox. A step up from monitoring, used once you are confident your legitimate email passes correctly.
• p=reject: Failing messages are rejected at the server level and never delivered at all. The strictest policy, used once your authentication setup is fully verified and stable.

A typical DMARC record looks like this:

_dmarc.yourdomain.com TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@yourdomain.com; pct=100"

Breaking that down: v=DMARC1 identifies this as a DMARC record. p=quarantine is the policy. rua=mailto: is the address where aggregate DMARC reports are sent. pct=100 applies the policy to 100% of failing messages (you can use a lower percentage while testing).

DMARC Reports

One of DMARC’s most useful features is the reporting it provides. Receiving mail servers send aggregate reports (RUA) to the address you specify, typically once per day. These reports show you every server that sent email claiming to come from your domain, whether it passed or failed SPF and DKIM, and how many messages were involved.

The reports are sent in XML format, which is not easy to read directly. Several free and paid tools exist to parse and visualise DMARC reports into readable dashboards. MxToolbox, Postmark’s DMARC Digests, and dmarcian are commonly used options. Reading these reports regularly is how you identify misconfigured services, legitimate senders you forgot to add to SPF, and active spoofing attempts against your domain.

How SPF, DKIM, and DMARC Work Together

The three standards address different parts of the same problem and are most effective when deployed together. Here is how a typical incoming email is evaluated:

1. The receiving mail server checks SPF: is the sending server’s IP address on the approved list for this domain?
2. The receiving mail server checks DKIM: is there a valid signature from an authorised key, and does the email content match what was signed?
3. The receiving mail server checks DMARC: does either the SPF result or the DKIM result pass, and does the domain in that result align with the “From” address the recipient will see?
4. If DMARC passes, the email is delivered normally. If DMARC fails, the receiving server applies your published policy: none, quarantine, or reject.

A spoofed email claiming to come from your domain will fail at step 3 because the attacker cannot forge a valid DKIM signature (they do not have your private key) and their sending server will not be on your SPF list. Even if they somehow pass one check, the alignment requirement means the “From” address the recipient sees must match the domain used in the passing check. A well-configured DMARC policy at p=reject means spoofed emails from your domain are rejected before reaching anyone’s inbox.

How to Set Up SPF, DKIM, and DMARC

The setup process varies depending on your email provider, but the general steps are the same regardless of which service you use.

Setting Up SPF

Log into the DNS management panel for your domain (either at your registrar or your hosting provider’s control panel) and add a TXT record at the root of your domain (@ or blank host field). Your email provider will give you the exact SPF record to use. If you send email through multiple services (for example, Google Workspace for regular email and Mailchimp for newsletters), you need a single SPF record that includes all of them. You cannot have two separate SPF records on the same domain. Combine all authorised senders into one record.

Setting Up DKIM

Your email provider will generate the DKIM key pair and give you the public key record to add to DNS. The exact subdomain and TXT value will be provided by the service. Add it as instructed. Some providers (like Google Workspace or Microsoft 365) let you generate the key inside their admin panel and then walk you through adding the DNS record. Once added, return to your provider’s admin panel to activate DKIM signing.

Setting Up DMARC

Once SPF and DKIM are in place and working, add your DMARC record. Start with p=none and a reporting address you actually monitor. After one to two weeks of reviewing reports and confirming all your legitimate email is passing, move to p=quarantine. Once you are satisfied nothing legitimate is being caught, move to p=reject. Rushing straight to p=reject without verifying your SPF and DKIM setup is a common mistake that can cause your own legitimate email to be rejected.

Verifying Your Setup

After adding all three records, verify them using a DNS lookup tool. Our DNS Lookup tool can retrieve TXT records for your domain so you can confirm the records are live and readable. You can also use MxToolbox’s email header analyser to send a test email and see exactly how receiving servers evaluated your SPF, DKIM, and DMARC.

Common Mistakes and How to Avoid Them

Multiple SPF records. You can only have one SPF TXT record per domain. Adding a second one does not combine them, it breaks both. If you need to add a new sending service, edit the existing record to include it.

Forgetting third-party senders. If you use any external service to send email on behalf of your domain (a newsletter tool, a CRM, a support ticket system, a transactional email service), each one needs to be included in your SPF record and set up with DKIM. DMARC reports will show you services you missed.

Setting p=reject before verifying. Moving to a reject policy before your SPF and DKIM setup is fully verified will cause legitimate email to be rejected. Always start with p=none, review reports, then progress to quarantine and finally reject.

Exceeding the SPF 10-lookup limit. SPF records with too many include statements can exceed the 10 DNS lookup limit and cause SPF to fail. If you use many sending services, look at SPF flattening tools that resolve include statements into direct IP addresses.

Expired or rotated DKIM keys not updated in DNS. Some email providers rotate DKIM keys periodically for security. If the private key changes but the DNS record is not updated, DKIM will fail. Check your provider’s admin panel after any major changes to your email configuration.

Why This Matters for Your Hosting Setup

If you host email on the same server as your website, your hosting provider’s mail server is the authorised sender and the SPF and DKIM setup is typically handled through your cPanel or Plesk panel. Most control panels include an email deliverability tool or authentication wizard that generates and applies SPF and DKIM records automatically.

If you use a separate email service (Google Workspace, Microsoft 365, Zoho, Fastmail) alongside a hosting provider, you need to ensure that both your hosting server and your external email service are included in your SPF record, and that DKIM is set up for whichever service sends your email.

Getting email authentication right is not just a security measure. It directly affects whether your emails reach inboxes. Major providers including Gmail and Yahoo have progressively tightened their requirements, and since 2024 bulk senders to Gmail are required to have SPF, DKIM, and DMARC in place. Sites without proper authentication see higher bounce rates, lower inbox placement, and in some cases, emails rejected entirely before delivery.

Common Questions About SPF, DKIM, and DMARC

Do I need all three, or will SPF alone do?

SPF alone is not sufficient for reliable email authentication. It does not check the visible “From” address and it fails when email is forwarded. DKIM adds cryptographic proof of origin and survives forwarding. DMARC ties the two together with an enforceable policy and alignment check. All three working together give you meaningful protection against spoofing and meaningful control over what happens to failing messages.

What happens if I set DMARC to p=reject without setting up DKIM first?

If DMARC is set to reject and DKIM is not configured, every email from your domain will rely entirely on SPF to pass the DMARC check. If SPF fails for any reason (forwarded email, a sending service you forgot to include, the 10-lookup limit being exceeded), those emails will be rejected. Always confirm SPF and DKIM are both working before moving to a reject policy.

Why is my email going to spam even with SPF and DKIM set up?

Authentication passes are a necessary condition for inbox delivery, not a guarantee of it. Spam filters also consider your domain’s sending reputation, the content of the email, the engagement history of recipients, and whether your IP address appears on blocklists. If SPF and DKIM pass but email still lands in spam, check your domain’s reputation using a tool like Google Postmaster Tools, review the content of the emails, and confirm your sending IP is not on a blocklist.

Where do I add SPF, DKIM, and DMARC records?

All three are DNS TXT records added at your domain’s DNS provider. That is usually your domain registrar (Namecheap, GoDaddy, Porkbun) or your hosting provider’s DNS management panel. If your domain uses Cloudflare for DNS (which is common when using Cloudflare as a CDN or proxy), you add the records in the Cloudflare dashboard instead.

How long does it take for changes to take effect?

DNS changes typically propagate within a few minutes to a few hours, though the technical maximum is up to 48 hours depending on TTL settings. You can check whether a record is live using our DNS Lookup tool or by checking with a service like MxToolbox. DMARC reports from the day after you make changes will show you whether the new configuration is being applied correctly by receiving servers.