### [SPF, DKIM, and DMARC Explained: The Complete Email Authentication Guide [2026]](https://wpmailsmtp.com/dmarc-spf-dkim/)

**Published:** September 22, 2021
**Author:** Rachel Adnyana

**Excerpt:** Last year, fake emails cost businesses and people over $10 billion. Every three seconds, someone clicks on a phishing email. These attacks happen because email has a big problem: anyone can pretend to be anyone else.

When you send an email, there's no built-in way to prove it's really from you. Scammers use this weakness to send millions of fake emails every day. They pretend to be banks, companies, or even your boss. 

Without the right protection, email providers can't tell the difference between real emails and fake ones. SPF, DKIM, and DMARC fix this problem. Think of them as a three-part ID check for every email you send. 

In this article, I'll explain how DMARC, SPF, and DKIM work together to verify your outgoing mail and make sure your messages always get through.

**Content:**

Email has a trust problem. There’s no built-in way to prove a message actually came from the domain it claims to be from, which is why someone can send an email that looks like it’s from your boss, your bank, or your business with little more than a few minutes of setup.

SPF, DKIM, and DMARC are the three DNS records that fix this. Together, they tell receiving mail servers which servers are allowed to send for your domain, whether each message has been tampered with in transit, and what to do when one of those checks fails.

This guide breaks down how the three protocols work, where they fit together, how to set them up in the right order, and what to do when something breaks. As of 2026, all three are effectively mandatory for any business that sends email. Gmail, Yahoo, and Microsoft enforce it directly, and skipping any of them drops your inbox placement.

## SPF vs DKIM vs DMARC at a Glance

If you just need the fast version, this table covers the essentials. Each protocol does something the others can’t, which is why all three are needed together.

SPFDKIMDMARC**What it does**Lists servers allowed to send mail for your domainSigns each email so receivers can confirm it wasn’t modifiedTells receivers what to do when SPF or DKIM fails**How it works**Receiver compares the sending IP to a list in your DNSReceiver verifies a cryptographic signature against your public keyReceiver applies your policy (deliver, spam, or reject) to failing mail**What it doesn’t do**Doesn’t check the visible `From:` address; breaks on forwardingDoesn’t say which servers can send; can break if relays modify mailDoesn’t authenticate anything on its own, relies on SPF and DKIM**Where it lives in DNS**TXT record at your apex domainTXT record at `[selector]._domainkey.yourdomain.com`TXT record at `_dmarc.yourdomain.com`**Required in 2026?**YesYesYes[Fix Your WordPress Emails Now](https://wpmailsmtp.com/pricing/)

## The 30-Second Explanation

If someone asked you to explain email authentication at a party, here’s the version that fits in three sentences:

- **SPF** says which servers are allowed to send email for your domain.
- **DKIM** proves the email wasn’t changed by anyone in transit.
- **DMARC** tells the receiving server what to do when SPF or DKIM fails: deliver, send to spam, or reject.

You need all three because each one fixes what the others miss.

## How SPF, DKIM, and DMARC Work Together

When an email arrives at Gmail, Outlook, or any other inbox, three checks happen one after the other.

First, the receiving server takes the IP address the message came from and looks at your SPF record. The SPF record is a list of servers you’ve authorized to send mail for your domain. If the sending IP is on the list, SPF passes.

Second, the server checks the DKIM signature attached to the email. DKIM is a cryptographic signature applied at sending time, and your DNS holds the matching public key. If the signature verifies against the key, DKIM passes, and that proves the email content wasn’t modified between sender and receiver.

Third, the server looks at your DMARC record. DMARC says two things: which of those two checks must pass *and align* with your visible `From:` address, and what to do if neither does. The three options are deliver normally, send to spam (quarantine), or reject the message entirely.

The “alignment” part matters. Without it, an attacker could pass SPF for their own domain while spoofing yours in the visible `From:` line. DMARC closes that gap by requiring the authenticated domain to match the one the recipient sees.

![How SPF, DKIM, and DMARC work together](https://wpmailsmtp.com/wp-content/uploads/2021/09/how-spf-dkim-and-dmarc-work-togehter.png)## What Is SPF?

SPF (Sender Policy Framework) is a TXT record in your DNS that lists every server and service authorized to send email on behalf of your domain. It’s the first line of defense against domain spoofing.

A basic SPF record looks like this:

```
v=spf1 include:sendlayer.net ~all
```

Breaking it down:

- `v=spf1` declares this is an SPF record.
- `include:sendlayer.net` authorizes a sending service, in this case, SendLayer. Each sending tool gets its own `include:` directive.
- `~all` is the catch-all rule for anything that doesn’t match. The tilde means “soft fail” (allow but flag as suspicious). Use `-all` for “hard fail” (reject) once you’re confident your record covers every legitimate sender.

When an email arrives, the receiving server takes the IP it came from and checks if that IP is allowed by your SPF record. If yes, SPF passes. If not, SPF fails.

### What SPF can’t do

SPF has two well-known limitations. It **breaks on email forwarding**: when someone forwards your email, the forwarding server uses its own IP, which isn’t in your SPF record. SPF fails even though the original was legitimate. And it **only checks the return-path, not the visible `From:` address**. An attacker can pass SPF with a domain they control while making the `From:` line look like yours. That’s why DMARC alignment matters. See the DMARC section below.

### The 10-DNS-lookup limit

SPF records are limited to 10 DNS lookups total (RFC 7208). Every `include:`, `a`, `mx`, `ptr`, and `exists:` directive counts toward the limit. Add too many sending services and you’ll hit a `PERMERROR`, at which point every authentication fails silently.

Most domains hit this when they stack multiple marketing tools, CRMs, transactional services, and helpdesks. If you’re close to the limit, follow our guide on [how to merge multiple SPF records](https://wpmailsmtp.com/fix-multiple-spf-records/) into a single, flattened record.

And note: **you can only have one SPF record per domain**. If you try to add a second, RFC 7208 says receivers must treat the whole setup as invalid, the same effect as having no SPF at all.

## What Is DKIM?

DKIM (DomainKeys Identified Mail) adds a cryptographic signature to every email you send. The signature is generated using a private key held by your sending service, and your DNS holds the matching public key. Receiving servers compare the two to confirm the email actually came from your domain and that nothing in it was modified in transit.

A DKIM record in DNS looks like this:

```
selector1._domainkey.example.com.    IN    TXT    "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQ..."
```

The **selector** (“selector1” in this example) tells receiving servers which DKIM key to look up. Most providers rotate keys periodically and use different selectors for different sending streams, so the selector name is part of the record location.

Every email you send carries a `DKIM-Signature` header looking something like this:

```
DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=selector1; h=from:to:subject:date; bh=...; b=...
```

The `d=` tag is the domain claiming the signature. The `s=` tag is the selector. That’s the DNS record receivers will look up.

### What DKIM can’t do

DKIM is powerful but it has limits. It **doesn’t say which servers are allowed to send** for your domain. That’s SPF’s job. An attacker can spoof your domain without DKIM signing, and DKIM alone has no opinion about that. It can also **break if a relay server modifies the message body**. For example, a mailing list that adds a footer to outgoing mail. And DKIM **has no enforcement built in**. A receiving server can ignore a failed signature unless DMARC tells it not to.

### DKIM key length

Modern DKIM keys are 2048 bits, which produces a public key string longer than 255 characters, the maximum length of a single TXT record value. Most DNS providers handle this automatically by splitting the value across multiple quoted strings, but some don’t. If your DKIM record won’t save or won’t validate, see our guide on [how to split a DKIM record](https://wpmailsmtp.com/solved-how-to-split-a-dkim-record/).

## What Is DMARC?

DMARC (Domain-based Message Authentication, Reporting, and Conformance) ties SPF and DKIM together and tells receiving servers what to do when authentication fails. It’s the only one of the three that generates reports back to you.

A typical DMARC record looks like this:

```
_dmarc.example.com.    IN    TXT    "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; pct=100; aspf=r; adkim=r"
```

![Example of a valid DMARC record](https://wpmailsmtp.com/wp-content/uploads/2021/03/how-to-create-a-dmarc-record-example-google-e1613129178467.png)Each tag has a job:

- `v=DMARC1` declares this is a DMARC record.
- `p=` is the policy: `none`, `quarantine`, or `reject`.
- `rua=` is where aggregate reports get sent.
- `pct=` is the percentage of mail the policy applies to (useful for gradual rollouts).
- `aspf=` and `adkim=` control alignment mode, relaxed (`r`) or strict (`s`).

### Policy progression: p=none → p=quarantine → p=reject

DMARC enforcement is a journey, not a switch. The three policies are stages, and you progress through them as your confidence grows.

![DMARC Policy timeline](https://wpmailsmtp.com/wp-content/uploads/2021/09/dmarc-policy-timeline.png)- **p=none**: Monitor mode. Failing emails are delivered normally, but you receive reports about them. Always start here.
- **p=quarantine**: Failing emails are sent to the recipient’s spam folder. Move here after 2–4 weeks at p=none with no legitimate mail failing.
- **p=reject**: Failing emails are rejected outright (a `550` SMTP error). Move here after another 2–4 weeks at p=quarantine.

Jumping straight to `p=reject` is the most common cause of DMARC-related outages. You’ll discover legitimate sending sources you forgot about (your CRM, your marketing tool, your support desk) only after they get rejected. Always start at `p=none`, read the reports, then escalate.

### DMARC aggregate reports

When you set `rua=` in your DMARC record, you’ll start receiving daily XML reports from every mail provider that handles your domain’s email: Google, Microsoft, Yahoo, and others. These reports show every IP that sent mail under your domain and whether SPF and DKIM passed and aligned for each one.

The raw XML is noisy and machine-readable, so most teams plug their `rua=` address into a DMARC reporting service (Postmark, dmarcian, EasyDMARC, etc.) that parses the reports into a readable dashboard. It’s the only way to discover legitimate sending sources you might have missed before tightening your policy.

### DMARC alignment

DMARC introduces a concept the other protocols don’t have: **alignment**. SPF and DKIM each pass when their respective check is valid, but DMARC only counts that pass if the authenticated domain matches the visible `From:` address.

Two flavors:

- **SPF alignment**: the `smtp.mailfrom` (return-path) domain matches the `From:` domain.
- **DKIM alignment**: the `d=` tag in the DKIM signature matches the `From:` domain.

DMARC passes if *at least one* of these aligns *and* the underlying check passed.

Relaxed alignment (the default) allows subdomain matches, mail from `mail.example.com` aligns with a `From:` at `example.com`. Strict alignment requires an exact match. Most senders use relaxed unless they have a specific security reason for strict.

Alignment is the most common reason for DMARC failure even when SPF and DKIM both pass individually. Many sending services authenticate using *their own* domain (e.g., `sendgrid.net`), not yours, which means SPF and DKIM pass but DMARC fails because nothing aligns with `example.com`. Fixing alignment usually means switching to a custom return-path or branded DKIM signing offered by your provider.

### How to add a DMARC record

If your email provider gives you a specific DMARC record, add that. If not, this is a safe generic starter record at `_dmarc.yourdomain.com`:

```
v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com;
```

This puts you in monitor mode with reports coming to a mailbox you control. For full setup including report handling and policy progression, see our dedicated guide on [how to create a DMARC record](https://wpmailsmtp.com/how-to-create-dmarc-record/).

## Why You Need All Three (and What Happens If You Only Have One)

Each protocol fixes what the others can’t. Here’s the breakdown:

SPFDKIMDMARC**What it prevents**Unauthorized servers sending as your domainEmail content being modified in transitAttackers spoofing your `From:` address even when other checks pass**What it checks**Sending IP against your authorized listCryptographic signature against your public keyAlignment between authentication results and the `From:` domain**Common failure**Legitimate mail breaks on forwardingMailing-list relays modify the body and break the signatureBoth SPF and DKIM fail alignment with the visible domain**If you skip it**Any server can claim to send as your domainAnyone can modify your email in transit undetectedFailed authentications get no enforcementRun with only SPF, and you’re vulnerable to alignment-based spoofing: an attacker authenticates with their own domain while displaying yours. Run with only DKIM, and any server can still claim to be you. Run with only DMARC, and you have no underlying authentication for it to enforce. All three together is the only configuration that actually works.

## Are SPF, DKIM, and DMARC Required in 2026?

Email authentication moved from “best practice” to “non-negotiable” between 2024 and 2026. Here’s where things stand.

### Bulk senders (5,000+ emails per day to Gmail or Yahoo)

- **February 2024:** Gmail and Yahoo introduced bulk sender requirements. SPF, DKIM, and DMARC all required. One-click unsubscribe headers required. Spam complaint rate must stay below 0.3%.
- **May 2025:** Microsoft introduced equivalent requirements for Outlook.com, Hotmail, and Live.com.
- **November 2025:** Gmail moved from soft deferrals (temporary 421 errors) to **permanent rejection** (550 errors) for non-compliant messages. There’s no grace period anymore. Non-compliant mail is rejected outright.

### Lower-volume senders (under 5,000 per day)

You’re not technically subject to the bulk sender rules, but the underlying authentication checks apply to every connection. Missing SPF, DKIM, or DMARC drops inbox placement by up to 76% even at low volume. The rules nominally target bulk senders; the spam filters use the same signals for everyone.

### Compliance contexts

- **PCI DSS v4.0** includes email authentication requirements for organizations handling payment card data.
- **CISA Binding Operational Directive 18-01** requires all U.S. federal agencies to deploy SPF, DKIM, and DMARC with `p=reject`.
- Similar requirements exist in the UK (NCSC), Australia (ACSC), and Canada (CCCS) for government and critical infrastructure.

The takeaway: even if you’re sending 50 emails a month from your contact form, you still need all three records.

## The Setup Order That Matters (Most People Get This Wrong)

Add SPF first. Then DKIM. Then DMARC. With waits between each. This order is non-negotiable, and getting it wrong is the most common reason new deployments break delivery.

![SPF, DKIM, and DMARC setup order flow](https://wpmailsmtp.com/wp-content/uploads/2021/09/spf-dkim-dmarc-workflow.png)### Why this order?

DMARC checks the results of SPF and DKIM. If you add DMARC before those two are in place and validated, every email fails authentication. With a policy of `p=quarantine` or `p=reject`, that means your mail starts going to spam or getting rejected the moment DMARC propagates. Many providers won’t even let you add a DMARC record until SPF passes validation.

### Time until each one is active

- **SPF:** 5–30 minutes
- **DKIM:** 1–4 hours
- **DMARC:** 1–24 hours

After each record propagates, send a test email to a Gmail address you control and check the headers via “Show original.” Both SPF and DKIM should show `PASS` before you add DMARC.

## **Common setup mistakes that break everything**

- Having two SPF records on the same domain (combine into one)
- Wrong DKIM selector name, typos here are extremely common
- Starting DMARC at `p=reject` instead of `p=none`
- Adding records to the wrong subdomain
- Extra spaces or quotes in the record values
- Forgetting to save the change in your DNS provider’s interface (some require a second confirmation step)

## Where to Add SPF, DKIM, and DMARC Records

All three records are added as TXT records in your domain’s DNS settings, the same place you manage A records, MX records, and nameservers. Where exactly that lives depends on who’s managing your DNS.

### Shared hosts (Bluehost, SiteGround, HostGator)

Most shared hosts include a DNS Zone Editor in their control panel under “Domain” or “DNS Management.” Look for an option to add a TXT record.

### Domain registrars (GoDaddy, Namecheap, Google Domains)

If your hosting and domain are separate, your DNS usually lives with your registrar. Look for “DNS Settings” or “Manage DNS” in your domain dashboard.

### Cloudflare

Open the Cloudflare dashboard, select your domain, click **DNS** on the left menu, and add a new TXT record. Here’s the editor view:

![Adding a TXT record in Cloudflare DNS](https://wpmailsmtp.com/wp-content/uploads/2021/09/what-is-spf-dmarc-dkim.png)### Vercel

If Vercel hosts DNS for your domain, open the project, click **Settings → Domains → DNS Records**, and add a new TXT record. The Host field accepts `@` for the apex (used for SPF) and `_dmarc` for DMARC.

### Netlify

Netlify DNS lives under **Domains** in your team dashboard. Click the domain, then “Set up Netlify DNS” if you haven’t already, then add records under “DNS records.”

### Squarespace

Squarespace handles DNS through **Domains → \[domain name\] → DNS Settings → Custom Records**. Add TXT records with Host = `@` for the apex domain, or `_dmarc` for DMARC.

## How to Test SPF, DKIM, and DMARC

Three reliable ways to verify all three records are doing what you expect.

### Method 1: Gmail “Show original”

Send a test email from your domain to a Gmail address you control. Once it arrives, open the email, click the three-dot menu in the top right, and choose **Show original**. Look for these three lines near the top:

- **SPF:** PASS (with your domain)
- **DKIM:** PASS (with `header.d=` showing your domain)
- **DMARC:** PASS

![Gmail Show original view showing SPF, DKIM, and DMARC all passing](https://wpmailsmtp.com/wp-content/uploads/2021/09/spf-dkim-dmarc-gmail-test-1024x412.png)If any of these show `FAIL` or `NEUTRAL`, jump to the troubleshooting section below.

### Method 2: Online checkers

MxToolbox, dmarcian, and HostedScan all offer free SPF, DKIM, and DMARC lookups. Enter your domain and you’ll get a quick pass/fail status for each record, plus diagnostics for common errors like too many DNS lookups or syntax problems.

### Method 3: WP Mail SMTP’s Domain Checker

WP Mail SMTP’s [email test tool ](https://wpmailsmtp.com/docs/how-to-send-a-test-email-in-wp-mail-smtp/ "Sending a Test Email")validates all three records automatically every time you send a test email, no separate tool required. It flags missing records, multiple SPF records, DKIM signature problems, DMARC alignment failures, and PTR record issues, all from your WordPress admin.

![WP Mail SMTP Domain Checker results showing SPF, DKIM, and DMARC validation](https://wpmailsmtp.com/wp-content/uploads/2021/08/domain-check-results-1.png)## Troubleshooting SPF, DKIM, and DMARC Failures

If your records are set up but authentication is still failing, one of these scenarios is almost always the cause. Each one follows the same template: symptom → likely cause → diagnosis → fix.

### 1. DMARC fails despite SPF passing

**Symptom:** Gmail’s “Show original” shows `SPF: PASS` but `DMARC: FAIL`.

**Likely cause:** SPF alignment failure. Your return-path domain doesn’t match the visible `From:` domain.

**Diagnosis:** Look at the `smtp.mailfrom` value in headers, does it match the domain in `From:`?

**Fix:** Either change your sending service’s return-path to your domain (most providers offer a “custom return-path” or “bounce domain” setting), or rely on DKIM alignment instead, which is often easier to configure.

### 2. DKIM signature missing from received emails

**Symptom:** Headers show no `DKIM-Signature:` line at all.

**Likely cause:** DKIM isn’t actually configured on the sending side, or the wrong selector is being used.

**Diagnosis:** Send a test from another tool (Gmail directly, or another SMTP service) to compare. Check your SMTP provider’s dashboard for DKIM status, most show whether the selector is verified.

**Fix:** Re-verify the DKIM CNAME or TXT records exist exactly as your provider specified. The selector name in your DNS record must match what the provider is signing with, typos here are extremely common.

### 3. SPF “permerror: too many DNS lookups”

**Symptom:** Mail servers reject your messages with an SPF `PERMERROR`.

**Likely cause:** Your SPF record contains more than 10 DNS lookups (the RFC 7208 hard limit). Common when stacking `include:` directives for multiple services.

**Diagnosis:** Use an SPF flattener tool to count your lookups. Each `include:`, `a`, `mx`, `ptr`, and `exists:` counts.

**Fix:** Remove unnecessary includes, or use an SPF flattening service that resolves the includes into direct IP entries. Full walkthrough at [our SPF merge guide](https://wpmailsmtp.com/fix-multiple-spf-records/).

### 4. Multiple SPF records on the same domain

**Symptom:** SPF `PERMERROR` or `NEUTRAL` despite having a valid-looking record.

**Likely cause:** You have two or more SPF TXT records. RFC 7208 says this is invalid, receivers will treat it as if no SPF record exists.

**Diagnosis:** Run `dig TXT yourdomain.com`, or use MxToolbox’s SPF lookup. If you see two records starting with `v=spf1`. That’s the problem.

**Fix:** Combine the `include:` directives from both records into a single record. [Detailed walkthrough here](https://wpmailsmtp.com/fix-multiple-spf-records/).

### 5. DMARC alignment failure (the silent killer)

**Symptom:** `SPF: PASS` and `DKIM: PASS` but `DMARC: FAIL`.

**Likely cause:** Neither protocol is aligned with the `From:` domain even though both individually pass.

**Diagnosis:** Compare three values in headers, the `From:` domain, the `smtp.mailfrom` domain, and the DKIM `d=` tag. At least one of the last two must match the first.

**Fix:** Configure your sending service to use your domain in either the return-path (for SPF alignment) or the DKIM signature (for DKIM alignment). Most providers default to their own domain, you have to opt in to alignment.

### 6. DKIM record too long for DNS

**Symptom:** Your provider gave you a DKIM key, but DNS won’t accept it.

**Likely cause:** Single TXT records have a 255-character per-string limit. DKIM 2048-bit keys exceed this and must be split into multiple quoted strings within the same record.

**Diagnosis:** Count the characters in your key, over 255 means this is the issue.

**Fix:** Split the value into 255-character chunks, each in quotes: `"v=DKIM1; k=rsa; p=ABC..." "DEF..." "GHI..."`. Most modern DNS providers do this automatically; some don’t. Full guide at [how to split a DKIM record](https://wpmailsmtp.com/solved-how-to-split-a-dkim-record/).

### 7. SPF includes your provider, but emails still fail

**Symptom:** Your SPF record correctly includes your mailer (e.g., `include:sendlayer.net`), but emails still fail SPF.

**Likely cause:** You’re sending from a different IP than the one your include resolves to, usually because you have multiple services sending under the same domain (e.g., transactional through SendLayer, marketing through Mailchimp) but only included one.

**Diagnosis:** Check headers for the actual sending IP. Compare it to the IPs in your include’s SPF record.

**Fix:** Add includes for every service that sends from your domain, each marketing tool, transactional service, helpdesk, and CRM. If that pushes you over the 10-lookup limit, see issue #3.

### 8. DMARC p=reject blocking your own legitimate emails

**Symptom:** Customers stop getting your transactional emails (password resets, receipts), but your test sends work fine.

**Likely cause:** You moved to `p=reject` too quickly, before catching all the legitimate sending sources in your SPF.

**Diagnosis:** Check your DMARC aggregate reports, they show every sender that’s been failing under your domain. Legitimate ones will be obvious (your CRM, marketing tool, helpdesk).

**Fix:** Move back to `p=quarantine` or `p=none`. Use the DMARC reports to add the missing legitimate senders to SPF. Wait 2–4 weeks until reports show 0% failure of legitimate mail, then re-enforce.

### 9. Records added but not propagating

**Symptom:** You added the records, but tools still say they’re missing.

**Likely cause:** DNS caching at your registrar, your local resolver, or the receiving server. Common with low-TTL changes after high-TTL records were previously cached.

**Diagnosis:** Run `dig +trace TXT yourdomain.com` from a different network, or query Google DNS directly with `dig @8.8.8.8 TXT yourdomain.com`. If those show the record but your tester doesn’t, it’s caching.

**Fix:** Wait. Most propagation completes within an hour for SPF and up to 24 hours for DMARC. If after 48 hours you still see nothing, recheck that the record was saved correctly at your registrar, a common gotcha is interfaces that need a confirmation step you missed.

### 10. Test email passes, but real emails fail

**Symptom:** Your WP Mail SMTP test email shows all green, but real WordPress emails (form notifications, password resets) fail authentication.

**Likely cause:** Different sending paths. The plugin’s test sends through the configured mailer, but WordPress emails generated by some plugins or forms may bypass it.

**Diagnosis:** Check the `From:` address on the failing emails, is it your domain, or `wordpress@yoursite.com`? If it’s the latter, you have a from-address mismatch.

**Fix:** In WP Mail SMTP, enable “Force From Email” so every WordPress email uses your authenticated address, regardless of what the originating plugin sets.

## WordPress-Specific Notes

WordPress has a specific email problem: by default, it uses PHP’s `mail()` function, which sends messages without any authentication. Your SPF, DKIM, and DMARC records can be perfectly configured, but if WordPress is sending email through PHP `mail()` from your web host’s shared IP, and that IP isn’t in your SPF record, every authentication check fails.

The fix is to route all WordPress email through an authenticated SMTP service. [WP Mail SMTP](https://wpmailsmtp.com/) does this with one-click integrations for SendLayer, SMTP.com, Brevo, Gmail/Google Workspace, Microsoft 365, Amazon SES, Mailgun, SendGrid, Postmark, SparkPost, and others. Each integration is pre-configured to authenticate properly and align with your domain.

![WP Mail SMTP test email options](https://wpmailsmtp.com/wp-content/uploads/2020/11/wp-mail-smtp-test-email-options.png)If your WordPress emails are landing in spam, missing or misaligned authentication is usually the cause. The full diagnosis lives in our guide on [why WordPress emails go to spam](https://wpmailsmtp.com/wordpress-emails-going-to-spam/).

[Fix Your WordPress Emails Now](https://wpmailsmtp.com/pricing/)

### FAQs on SPF, DKIM, and DMARC

Common questions about email authentication, organized from the most-asked to the most technical.

#### What’s the difference between SPF, DKIM, and DMARC?

SPF says who can send, DKIM proves emails are real, and DMARC enforces the rules.

SPF (Sender Policy Framework) is a list of servers allowed to send email for your domain. It checks the sending server, not the visible `From:` address. DKIM (DomainKeys Identified Mail) is a cryptographic signature applied to each email that proves the message wasn’t modified in transit. DMARC (Domain-based Message Authentication, Reporting, and Conformance) is the policy that decides what to do when SPF or DKIM fails (deliver, send to spam, or reject) and requires the authenticated domain to match the visible `From:` address.

You need all three because each fixes what the others miss. SPF without DKIM breaks on forwarded mail. DKIM without SPF lets unauthorized servers claim your domain. Both without DMARC means receiving servers have no enforcement instruction when something fails.

#### Are SPF, DKIM, and DMARC required in 2026?

Yes, for any sender. The exact requirement depends on volume and context, but the practical answer is the same: deploy all three.

**Bulk senders** (5,000+ emails per day to Gmail or Yahoo) have been required to deploy all three since February 2024. As of November 2025, Gmail rejects non-compliant bulk mail outright with a `550` SMTP error, no more soft deferrals or grace period. Microsoft introduced equivalent enforcement for Outlook.com and Hotmail in May 2025.

**Lower-volume senders** aren’t legally required to deploy them, but emails increasingly land in spam without them, inbox placement drops up to 76% on unauthenticated mail even at low volume.

**Compliance contexts** add another layer: PCI DSS v4.0, CISA BOD 18-01 for U.S. federal agencies, and government requirements in the UK, Australia, and Canada all mandate SPF, DKIM, and DMARC for in-scope organizations.

#### What order should I set up SPF, DKIM, and DMARC?

SPF first, then DKIM, then DMARC, with a wait between each.

The order matters because DMARC checks the results of SPF and DKIM. If you add DMARC before those two are in place and validated, every email fails authentication. With a policy of `p=quarantine` or `p=reject`, your mail starts going to spam or getting rejected the moment DMARC propagates. Most providers won’t even let you add DMARC until SPF passes validation.

Specific timings: SPF activates in 5–30 minutes, DKIM in 1–4 hours, DMARC in 1–24 hours. After each record propagates, send a test email to Gmail and check the headers via “Show original.” Both SPF and DKIM should show `PASS` before you add DMARC. When you do add DMARC, start at `p=none` (monitor mode) for at least 2–4 weeks before moving to `p=quarantine`, and another 2–4 weeks before `p=reject`.

#### What does p=none, p=quarantine, and p=reject mean?

They’re the three DMARC enforcement levels, in order of strictness.

**p=none** is monitor mode. Failing emails are delivered normally, but you receive reports about which mail is failing and from where. Always start here, even though it does nothing on its own. It generates the data you need to discover legitimate sending sources before you start enforcing.

**p=quarantine** tells receiving servers to send failing emails to the recipient’s spam folder. Move here after 2–4 weeks at `p=none` when reports show no legitimate mail failing.

**p=reject** tells receiving servers to refuse failing emails outright with a `550` error. This is the strongest setting and provides maximum protection against domain spoofing, but going there too fast can block your own legitimate transactional mail. Move here only after another 2–4 weeks at `p=quarantine` with clean reports.

#### How do I test if SPF, DKIM, and DMARC are working correctly?

Three reliable methods, in order of ease:

**Gmail “Show original”.** Send a test email from your domain to a Gmail address you control. Open the email, click the three-dot menu, and choose **Show original**. Look for `SPF: PASS`, `DKIM: PASS`, and `DMARC: PASS` near the top. If any show `FAIL` or `NEUTRAL`, your records need work.

**Free online checkers.** MxToolbox, dmarcian, and HostedScan all offer free SPF, DKIM, and DMARC lookups. Enter your domain, get a pass/fail status for each plus diagnostics for common errors like too many DNS lookups.

**WP Mail SMTP’s Domain Checker.** If you’re on WordPress, WP Mail SMTP includes a built-in Domain Checker that validates all three records every time you send a test email. It flags missing records, multiple SPF records, DKIM problems, DMARC alignment failures, and PTR issues from your WordPress admin.

#### How do I create a DMARC record?

Add a TXT record at `_dmarc.yourdomain.com` with this value:

```
v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com;
```

Each tag has a job: `v=DMARC1` declares the record type, `p=none` sets the policy to monitor mode, and `rua=` is where aggregate reports get sent. Start at `p=none` for monitoring, then progress to `p=quarantine` and `p=reject` as your authentication coverage matures.

For full setup including report handling, alignment tuning, and policy progression, see our dedicated guide on [how to create a DMARC record](https://wpmailsmtp.com/how-to-create-dmarc-record/).

#### How do I add SPF records (and what if I have multiple senders)?

Find your DNS settings at your domain provider or registrar. Add a new TXT record with your domain as the host. For the value, start with `v=spf1` and add an `include:` for each sending service, ending with `~all` or `-all`.

Single sender example (using SendLayer):

```
v=spf1 include:sendlayer.net ~all
```

The mistake most people make is adding two separate SPF records. You can only have one per domain. If you need multiple services, combine them inside a single record:

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

Watch the 10-DNS-lookup limit, stack too many `include:` directives and SPF starts failing silently with a `PERMERROR`. If you’re already there, see [our guide on merging multiple SPF records](https://wpmailsmtp.com/fix-multiple-spf-records/).

#### Can I use DMARC without both SPF and DKIM?

Technically yes, DMARC passes when either SPF or DKIM passes and aligns. Practically no.

SPF breaks when emails get forwarded. DKIM can break when relay servers modify messages. When you only have one protocol and it fails, DMARC fails completely and your email gets rejected.

Real-world example: a company relies on SPF alone. Their invoice template works fine until a customer forwards an invoice to their accounting team, SPF fails on the forward, DMARC rejects, and the invoice never arrives. The customer doesn’t know it bounced. The fix is to add DKIM, which survives forwarding because the signature travels with the message.

Always set up both SPF and DKIM. Total setup time is about 20 minutes and it eliminates a whole category of preventable delivery failures.

#### What is DMARC alignment?

Alignment is the “are these the same domain?” check that makes DMARC actually meaningful.

**SPF alignment** requires the domain in the email’s return-path (`smtp.mailfrom`) to match the visible `From:` domain. **DKIM alignment** requires the `d=` tag in the DKIM signature to match the `From:` domain. DMARC passes when at least one of these aligns and the underlying check passed.

There are two modes: **relaxed** (the default) allows subdomain matches, `mail.example.com` aligns with `From: example.com`. **Strict** requires an exact match.

Alignment is the most common reason for DMARC failure even when SPF and DKIM individually pass. Many sending services authenticate using their own domain (e.g., `sendgrid.net`), not yours, SPF/DKIM pass for that domain, but DMARC fails because nothing aligns with your `From:`. The fix is usually a custom return-path or branded DKIM signing offered by your provider.

#### How long does it take for SPF, DKIM, and DMARC to start working?

Concrete timing: SPF activates in 5–30 minutes, DKIM in 1–4 hours, and DMARC in 1–24 hours.

The variation comes from DNS TTLs, registrar caching, and how aggressively receiving servers cache results. Once propagation completes, the records are *active*, but the full effect on inbox placement can take weeks as receivers build sender reputation around your authenticated domain.

The practical advice: don’t expect spam-folder rescues overnight. Add the records, verify they pass, then monitor delivery over the following weeks as reputation accrues.

#### Why are my emails still going to spam even though SPF, DKIM, and DMARC all pass?

Authentication is necessary, but not sufficient. Several other factors hurt inbox placement independent of SPF, DKIM, and DMARC.

- **Poor sender reputation**: new domain, low engagement, prior spam complaints
- **Content patterns**: excessive links, spammy phrases, image-heavy with little text
- **Missing list-unsubscribe header**: required by Gmail and Yahoo for bulk mail
- **Missing or generic PTR record**: reverse DNS that points to a cloud-provider default kills deliverability
- **No engagement signals**: no opens, no replies, recipients moving messages to spam
- **IP not warmed up**: sending high volume from a brand-new IP triggers volume-based filtering

For the full diagnostic, see our guide to [email deliverability](https://wpmailsmtp.com/email-deliverability/). If you’re a WordPress user specifically, our guide on [why WordPress emails go to spam](https://wpmailsmtp.com/wordpress-emails-going-to-spam/) walks through the WordPress-specific causes.

#### How do I fix DMARC failures in WordPress?

The most common cause is a `From:` address mismatch. WordPress defaults to `wordpress@yoursite.com` from the server, if your SPF and DKIM authenticate `yourdomain.com`, you have an alignment failure.

Fix it in WP Mail SMTP settings: set the **From Email** to an address at your own domain (e.g., `noreply@yourdomain.com`). Never use Gmail, Yahoo, or another free email address as the sender, those addresses can’t be DMARC-authenticated from your domain.

Also verify two more things:

- Your SPF record includes your actual mail server (e.g., `include:smtp.com` if you’re using SMTP.com).
- Your DKIM selector matches exactly what your provider expects, typos here are a leading cause of silent failures.

WP Mail SMTP’s Domain Checker will flag both of these issues automatically when you send a test email.

## Next, Check Your PTR Record

SPF, DKIM, and DMARC are three of the four DNS records that matter for email deliverability. The fourth is your PTR record, the reverse DNS entry that maps your sending IP back to your domain. Mailbox providers check it on every connection, and a missing or generic PTR will hurt your deliverability even when SPF, DKIM, and DMARC all pass.

For the full breakdown, see our guide to [PTR records and reverse DNS](https://wpmailsmtp.com/what-is-ptr-dns-record/). If you’re sending serious volume, you’ll also want to set up [Google Postmaster Tools](https://wpmailsmtp.com/how-to-set-up-google-postmaster-tools/) to monitor how Gmail sees your sender reputation.

Ready to fix your emails? [Get started today](https://wpmailsmtp.com/pricing) with the best WordPress SMTP plugin. If you don’t have the time to fix your emails, you can get full White Glove Setup assistance as an extra purchase, and there’s a 14-day money-back guarantee for all paid plans.

If this article helped you out, please follow us on [Facebook](https://facebook.com/wpmailsmtp) and [Twitter](https://twitter.com/wpmailsmtp) for more WordPress tips and tutorials.

**Categories:** Marketing

**Tags:** DMARC, DNS

---