AI Summary
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.
| SPF | DKIM | DMARC | |
|---|---|---|---|
| What it does | Lists servers allowed to send mail for your domain | Signs each email so receivers can confirm it wasn’t modified | Tells receivers what to do when SPF or DKIM fails |
| How it works | Receiver compares the sending IP to a list in your DNS | Receiver verifies a cryptographic signature against your public key | Receiver applies your policy (deliver, spam, or reject) to failing mail |
| What it doesn’t do | Doesn’t check the visible From: address; breaks on forwarding | Doesn’t say which servers can send; can break if relays modify mail | Doesn’t authenticate anything on its own, relies on SPF and DKIM |
| Where it lives in DNS | TXT record at your apex domain | TXT record at [selector]._domainkey.yourdomain.com | TXT record at _dmarc.yourdomain.com |
| Required in 2026? | Yes | Yes | Yes |
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.
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=spf1declares this is an SPF record.include:sendlayer.netauthorizes a sending service, in this case, SendLayer. Each sending tool gets its owninclude:directive.~allis the catch-all rule for anything that doesn’t match. The tilde means “soft fail” (allow but flag as suspicious). Use-allfor “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 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.
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:[email protected]; pct=100; aspf=r; adkim=r"
Each tag has a job:
v=DMARC1declares this is a DMARC record.p=is the policy:none,quarantine, orreject.rua=is where aggregate reports get sent.pct=is the percentage of mail the policy applies to (useful for gradual rollouts).aspf=andadkim=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.
- 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
550SMTP 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 theFrom:domain. - DKIM alignment: the
d=tag in the DKIM signature matches theFrom: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:[email protected];
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.
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:
| SPF | DKIM | DMARC | |
|---|---|---|---|
| What it prevents | Unauthorized servers sending as your domain | Email content being modified in transit | Attackers spoofing your From: address even when other checks pass |
| What it checks | Sending IP against your authorized list | Cryptographic signature against your public key | Alignment between authentication results and the From: domain |
| Common failure | Legitimate mail breaks on forwarding | Mailing-list relays modify the body and break the signature | Both SPF and DKIM fail alignment with the visible domain |
| If you skip it | Any server can claim to send as your domain | Anyone can modify your email in transit undetected | Failed authentications get no enforcement |
Run 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.
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.
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:
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
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 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.
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.
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.
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.
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 [email protected]? 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 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.
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.
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:[email protected];
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.
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.
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. If you’re a WordPress user specifically, our guide on why WordPress emails go 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 [email protected] 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., [email protected]). 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.comif 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. If you’re sending serious volume, you’ll also want to set up Google Postmaster Tools to monitor how Gmail sees your sender reputation.
Ready to fix your emails? Get started today 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 and Twitter for more WordPress tips and tutorials.
