Tutorial

Cloudflare Email DNS Setup: SPF, DKIM, and DMARC Made Simple

April 11, 2026

Back to Blog

Since February 2024, Gmail and Yahoo require SPF, DKIM, and DMARC for all bulk senders. Since 2025, even individual senders need proper alignment. If your email DNS isn't set up correctly in Cloudflare, your messages go straight to spam — or get rejected entirely.

This guide walks you through every DNS record you need, explains what each one does, and shows you the exact Cloudflare configuration. By the end, your emails will pass authentication checks from Gmail, Outlook, Yahoo, and every other major provider.

Gmail 2025+ Enforcement: Missing SPF or DKIM means instant rejection for domains sending 5,000+ emails per day. Even low-volume senders see deliverability drops without proper authentication. This isn't optional anymore — it's table stakes.

The Three Pillars of Email Authentication

Email authentication relies on three complementary systems. Each solves a different problem, and together they form a chain of trust that tells receiving servers your email is legitimate.

SPF (Sender Policy Framework)

"Who is allowed to send email for your domain?"

SPF is a TXT record on your root domain that lists every IP address and service authorized to send email on your behalf. When a receiving server gets an email from your domain, it checks this list. If the sending server's IP isn't on it, the email fails SPF.

Think of it as a guest list at a venue — if you're not on the list, you don't get in.

TXT Record Root Domain

DKIM (DomainKeys Identified Mail)

"Is this email really from who it claims?"

DKIM adds a cryptographic signature to every outgoing email. Your mail server signs the email with a private key, and the public key is published in DNS. The receiving server uses the public key to verify the signature hasn't been tampered with.

Think of it as a wax seal on a letter — it proves the letter came from you and hasn't been opened.

TXT Record Selector Subdomain

DMARC (Domain-based Message Authentication)

"What should happen to emails that fail SPF or DKIM?"

DMARC ties SPF and DKIM together with a policy. It tells receiving servers: "If an email claiming to be from my domain fails authentication, here's what to do with it." DMARC also provides reporting — you get daily XML reports showing who's sending email as your domain.

Think of it as the bouncer's instructions — reject them, quarantine them, or let them through but take notes.

TXT Record _dmarc Subdomain

Step 0: The MX Record (Don't Skip This)

Before any authentication record matters, your domain needs to tell the world where to deliver email. That's what the MX (Mail Exchange) record does. Surprisingly, this is what people forget most often.

0

Create the MX Record

The MX record tells other mail servers which hostname handles email for your domain. It must point to a hostname, not an IP address.

MX  example.com  →  mail.example.com  Priority: 10

Then create the A record for that hostname:

A  mail.example.com  →  YOUR_SERVER_IP  [Proxy: OFF]
Important: MX records must point to a hostname (mail.example.com), never directly to an IP address. This is defined in RFC 5321 and many mail servers will reject delivery to an IP-based MX.
Critical: The mail subdomain MUST have Cloudflare proxy OFF (grey cloud ). Email traffic uses SMTP (ports 25, 465, 587), not HTTP. Cloudflare's proxy only handles HTTP/HTTPS traffic. If you leave the orange cloud on, all email delivery will fail.

Step 1: SPF Record

1

Create Your SPF TXT Record

In Cloudflare, go to DNS → Records → Add Record. Choose type TXT, name @ (root domain), and enter your SPF value:

TXT  example.com  →  "v=spf1 ip4:YOUR_SERVER_IP -all"

Breaking this down:

  • v=spf1 — declares this is an SPF record (version 1)
  • ip4:YOUR_SERVER_IP — authorizes this specific IP to send email
  • -all — everything else is unauthorized (hard fail)

Common SPF Patterns

If you use external email services alongside your server, you need to include them:

Self-hosted only:  "v=spf1 ip4:203.0.113.10 -all"
+ Google Workspace:  "v=spf1 ip4:203.0.113.10 include:_spf.google.com -all"
+ Microsoft 365:  "v=spf1 ip4:203.0.113.10 include:spf.protection.outlook.com -all"
Multiple servers:  "v=spf1 ip4:203.0.113.10 ip4:198.51.100.20 -all"
One SPF Record Per Domain: You can only have a single SPF TXT record on your root domain. If you add a second one, both records become invalid and SPF checks fail for all email. Combine everything into one record.

Understanding the "all" Mechanism

MechanismMeaningRecommendation
-all Hard fail — reject unauthorized senders Recommended Best security, required by Gmail 2025+
~all Soft fail — mark as suspicious but accept Testing Only Use temporarily while setting up
?all Neutral — no policy, treat as if no SPF exists Avoid Provides no protection at all

Step 2: DKIM Record

2

How DKIM Works

DKIM uses public-key cryptography. Your mail server signs every outgoing email with a private key. The corresponding public key lives in your DNS. When a receiving server gets the email, it fetches the public key from DNS and verifies the signature.

Your Mail Server
Signs with private key
Email Sent
Signature in header
Receiver Checks DNS
Fetches public key
Signature Verified
Email is authentic

The DKIM DNS Record

DKIM records are published under a specific subdomain pattern: selector._domainkey.yourdomain.com. The "selector" is a label your mail server uses to identify which key to use (commonly "default", "google", "k1", etc.).

TXT  default._domainkey.example.com
→  "v=DKIM1; h=sha256; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."

Breaking this down:

  • v=DKIM1 — declares this is a DKIM record
  • h=sha256 — hash algorithm used for signing
  • k=rsa — key type (RSA is standard)
  • p=MIIBIj... — the actual public key (base64 encoded)

Generating DKIM Keys

If your mail server doesn't automatically generate DKIM keys, you can create them manually with OpenSSL:

# Generate a 2048-bit RSA key pair
openssl genrsa -out dkim_private.pem 2048

# Extract the public key
openssl rsa -in dkim_private.pem -pubout -out dkim_public.pem

# Format for DNS (remove headers, join lines)
grep -v "^-" dkim_public.pem | tr -d '\n'
Key Size: DKIM keys should be 2048-bit RSA at minimum. 1024-bit keys are considered weak and some providers flag them. The resulting DNS record will be long (about 400 characters), but that's expected and fine.

Understanding Selectors

The selector is simply a label that lets you have multiple DKIM keys for the same domain. Common selectors include:

  • default — general purpose, used by most self-hosted setups
  • google — used by Google Workspace
  • k1, k2 — used by Mailchimp and other ESPs
  • selector1, selector2 — used by Microsoft 365

Your mail server's DKIM configuration specifies which selector to use. The DNS record must match.

Step 3: DMARC Record

3

Create Your DMARC TXT Record

DMARC is always published at _dmarc.yourdomain.com. In Cloudflare, add a TXT record with name _dmarc:

TXT  _dmarc.example.com
→  "v=DMARC1; p=quarantine; rua=mailto:[email protected]; ruf=mailto:[email protected]; fo=1"

DMARC Tags Explained

  • v=DMARC1 — version (always DMARC1)
  • p= — the policy: what to do with failing emails
  • rua= — aggregate report URI: where to send daily summary reports
  • ruf= — forensic report URI: where to send individual failure reports
  • fo=1 — failure option: send a report if either SPF or DKIM fails (default is both)
  • pct= — percentage of messages to apply policy to (useful for gradual rollout)
  • adkim= — DKIM alignment mode: r (relaxed) or s (strict)
  • aspf= — SPF alignment mode: r (relaxed) or s (strict)

DMARC Policy Progression

PolicyActionWhen to Use
p=none Monitor only — no action on failing emails Start Here Collect reports, identify all legitimate senders
p=quarantine Send failing emails to spam/junk folder Phase 2 After confirming all senders pass auth
p=reject Completely reject failing emails — never delivered Goal Maximum protection against spoofing
Recommended Progression: Start with p=none for 2-4 weeks while monitoring reports. Move to p=quarantine once you've confirmed all legitimate email passes. Graduate to p=reject after another 2-4 weeks of clean reports. Rushing to p=reject without monitoring can block legitimate email.

Step 4: Verify Everything

4

Command-Line Verification

After creating all records, verify they're propagated correctly using dig:

# Check SPF
dig TXT example.com +short
# Expected: "v=spf1 ip4:YOUR_IP -all"

# Check DKIM
dig TXT default._domainkey.example.com +short
# Expected: "v=DKIM1; h=sha256; k=rsa; p=..."

# Check DMARC
dig TXT _dmarc.example.com +short
# Expected: "v=DMARC1; p=quarantine; ..."

# Check MX
dig MX example.com +short
# Expected: 10 mail.example.com.

Online Verification Tools

For a more thorough check, use these free tools:

  • MXToolbox (mxtoolbox.com) — checks MX, SPF, DKIM, DMARC, blacklists, and SMTP connectivity in one report
  • mail-tester.com — send a test email and get a score out of 10 with detailed feedback
  • Google Postmaster Tools — monitor your domain's reputation with Gmail specifically
  • DMARC Analyzer — parse and visualize your DMARC aggregate reports
  • dmarcian.com — free DMARC record checker and report analyzer

Common Cloudflare-Specific Mistakes

Cloudflare adds a layer of complexity because of its proxy feature. Here are the mistakes we see most often:

Mistake #1: Proxy ON for mail subdomain
The most common and most destructive mistake. If mail.yourdomain.com has the orange cloud enabled, Cloudflare proxies the traffic through its HTTP network. SMTP traffic on ports 25, 465, and 587 cannot pass through this proxy. Result: complete email failure — no sending, no receiving, no nothing. Always use the grey cloud for mail subdomains.
Mistake #2: SPF record on subdomain instead of root
SPF must be on your root domain (example.com), not on mail.example.com (unless you also send email from the mail subdomain itself). The "From" address in emails uses the root domain, so that's where SPF is checked. You can add a secondary SPF on the mail subdomain for HELO identity checks, but the root domain record is what matters most.
Mistake #3: DKIM record too long for a single DNS entry
2048-bit DKIM keys produce values longer than 255 characters, which is the limit for a single DNS TXT string. Cloudflare handles this automatically by splitting the value into multiple quoted strings. If you're entering the record manually, make sure your provider supports long TXT records or split them properly.
Mistake #4: Forgetting the mail A record
You create the MX record pointing to mail.example.com, but forget to create the A record for mail.example.com. Without the A record, the hostname doesn't resolve to an IP, and email delivery fails silently.
Mistake #5: Using Cloudflare Email Routing AND self-hosted mail
Cloudflare Email Routing creates its own MX records pointing to Cloudflare's infrastructure. If you're running your own mail server, these conflict with your custom MX records. You must disable Email Routing entirely before configuring self-hosted email DNS. They cannot coexist.

The PTR Record (Reverse DNS)

One record that's often overlooked because it's not configured in Cloudflare: the PTR record. PTR (reverse DNS) maps your server's IP address back to a hostname. Many mail servers check that the IP sending email has a PTR record that matches the mail server hostname.

Where to set PTR: PTR records are configured through your hosting provider or VPS control panel — not in Cloudflare. Contact your provider (Hetzner, DigitalOcean, AWS, etc.) to set the PTR for your server IP to mail.yourdomain.com. Without a matching PTR, Gmail responds with 5.7.25 - PTR record missing.

Complete DNS Record Checklist

Here's every DNS record you need for a fully authenticated email setup in Cloudflare:

PurposeTypeNameValueProxy
Mail Exchange MX @ mail.example.com (priority 10) N/A
Mail Server IP A mail YOUR_SERVER_IP OFF
SPF (Root) TXT @ v=spf1 ip4:YOUR_IP -all N/A
SPF (Mail HELO) TXT mail v=spf1 a -all N/A
DKIM TXT default._domainkey v=DKIM1; h=sha256; k=rsa; p=... N/A
DMARC TXT _dmarc v=DMARC1; p=quarantine; rua=...; fo=1 N/A
Why 6 records? Most guides mention only 4 (MX, SPF, DKIM, DMARC). The mail A record is essential but obvious. The Mail SPF record (on the mail subdomain) is the one most people miss entirely. It exists for the SMTP HELO/EHLO identity check — when your server introduces itself as mail.example.com, the receiving server checks SPF for that hostname specifically, not your root domain. Without it, you'll see "SPF HELO check failed" in authentication results.

Panelica: One-Click Email DNS

Skip the Manual Work: Panelica's Mail DNS Sync creates all 6 records in a single click. It detects your server IP automatically, generates 2048-bit DKIM keys, configures OpenDKIM, and pushes the complete record set to Cloudflare via API — MX, Mail A (proxy OFF), root SPF, mail SPF, DKIM, and DMARC. No manual DNS editing, no copy-paste errors, no forgotten records. Every record follows Gmail's 2025+ requirements out of the box.

Testing Your Setup

After configuring everything, send a test email to a Gmail address and click "Show Original" in Gmail. You should see:

SPF:  PASS  with IP YOUR_SERVER_IP
DKIM:  PASS  with domain example.com
DMARC:  PASS

If any of these show FAIL, go back through the relevant section. SPF failures usually mean the wrong IP. DKIM failures mean a key mismatch or DNS propagation delay (wait up to 48 hours). DMARC failures mean SPF and DKIM aren't aligned with the From domain.

DNS Propagation: After adding or changing DNS records in Cloudflare, changes typically propagate within minutes (Cloudflare is fast). However, some receiving servers cache DNS aggressively, so allow up to 24-48 hours before concluding something is broken. Use dig to verify the records are live from Cloudflare's side first.

Summary

Email authentication in 2025 is non-negotiable. Gmail, Yahoo, Outlook, and every major provider enforce SPF, DKIM, and DMARC. The setup takes 15 minutes in Cloudflare if you know what you're doing — or one click with Panelica. Either way, don't skip it. Your deliverability depends on it.

  • MX record pointing to mail.yourdomain.com
  • Mail A record with Cloudflare proxy OFF (grey cloud)
  • SPF record on root domain with hard fail (-all)
  • Mail SPF record for HELO identity
  • DKIM record with 2048-bit RSA key
  • DMARC record starting at quarantine or reject
  • PTR record set through your hosting provider
  • All records verified with dig and mail-tester.com
Share: