How to Add SPF, DKIM, and DMARC Records in Cloudflare

Adding email-authentication DNS records is a necessary first step before you send production email. This guide shows you how to add SPF DKIM DMARC records Cloudflare provides DNS management for, including the return-path records your email provider may require for bounce handling and SPF alignment.

The examples below use example.com as the domain you own. Replace every placeholder with the exact hostname and value generated in your Volanea sending-domain setup. Do not copy example provider targets into your live DNS zone: DKIM keys, CNAME targets, and return-path values are unique to the provider and, in some cases, to your account.

Before you edit DNS: confirm Cloudflare is authoritative

Buying a domain through Cloudflare Registrar and managing DNS through Cloudflare are often part of the same setup, but they are not identical concepts. Your registrar is where the domain is registered; authoritative DNS is where the internet looks up records such as SPF, DKIM, DMARC, MX, and CNAME.

Before adding email records, confirm that the domain is active in your Cloudflare account and that Cloudflare is the authoritative DNS provider for it. In a standard full Cloudflare setup, your domain uses the Cloudflare nameservers assigned to the zone. If the domain uses another DNS host, adding records in Cloudflare may have no effect because receiving mail servers will query the other provider instead.

There are a few cases where you should pause before making changes:

• Your DNS is managed by a web host, reseller, or another registrar rather than Cloudflare.
• Your company has a separate DNS team or infrastructure-as-code workflow that overwrites manual dashboard changes.
• You use a partial or CNAME-based Cloudflare setup, where another provider remains authoritative for much of the zone.
• Your domain was added to Cloudflare through a hosting partner, which can mean DNS records must be managed in the partner's interface.

For a domain bought through Cloudflare Registrar, Cloudflare DNS is commonly already available, but it is still worth checking. Authentication records must be published at the authoritative DNS provider, not merely in the account where the domain was purchased.

Navigate to DNS management in Cloudflare

Cloudflare periodically updates its dashboard navigation. As of writing, the reliable path is to open the domain's DNS Records page, then use the Records tab to create or edit records.

In the Cloudflare dashboard, use this path:

1. Sign in to the Cloudflare dashboard.
2. From the account home or Websites area, select the website/zone for the domain you will send from, such as example.com.
3. In the zone navigation, open DNS.
4. Open Records to reach the DNS Records page.
5. Select Add record.
6. Choose the record Type, complete the name and content fields, then select Save.

If you see multiple Cloudflare accounts, make sure you selected the account that owns the correct zone. A DNS record can look perfectly configured in the dashboard while doing nothing if it was created under a duplicate, inactive, or non-authoritative zone.

What Cloudflare calls the fields

Cloudflare's record editor uses names that are easy to confuse with email-provider terminology:

The most important translation is this: an email provider's Host field maps to Cloudflare's Name field, and the provider's Value field maps to Cloudflare's Content or Target field.

The SPF, DKIM, DMARC, and return-path record map

Your Volanea domain setup will provide the exact values to publish. The table below explains the shape of the records so you can recognize where each supplied value belongs in Cloudflare.

The word typical matters. DNS authentication formats are standardized, but providers do not all use the same record design. Some publish DKIM as one or more CNAME records. Others issue a long DKIM public key in a TXT record. Some configure a custom return-path with a CNAME, while others require an MX record and an SPF TXT record on a bounce subdomain.

Always prefer the exact generated record list in your sending-domain setup over a generic example. For implementation details and provider-generated values, use the email API setup documentation.

Add your SPF record without creating a duplicate

SPF, or Sender Policy Framework, tells receiving servers which systems are allowed to send mail using a domain or return-path domain. It is published as a TXT record.

A basic SPF record often looks like this:

v=spf1 include:spf.example-email-provider.net ~all

That line is only an example. Your actual record may contain a different include: domain, one or more IP addresses, an a or mx mechanism, or a hard-fail ending of -all. Use the value supplied by the services that actually send mail for the domain.

Create the SPF record in Cloudflare

To add SPF for example.com:

1. Go to DNS > Records for example.com.
2. Select Add record.
3. Choose TXT as the record type.
4. In Name, enter @ for the root domain if Cloudflare accepts that shorthand, or use the root-domain format shown by the editor.
5. In Content, paste the complete SPF string beginning with v=spf1.
6. Leave TTL at the default unless you have a specific operational reason to change it.
7. Select Save.

Do not wrap the SPF value in extra quotation marks unless Cloudflare adds the presentation quotes automatically. Do not add an extra TXT prefix. The content should begin directly with v=spf1.

You can have multiple TXT records, but not multiple SPF policies

A domain can have many TXT records. It might have one for a site-verification token, another for a Google Workspace setting, and another for an application integration. That is normal.

What is not normal is publishing two separate TXT values at the same hostname that both begin with v=spf1. SPF receivers are not expected to merge separate SPF policies. Multiple SPF records can produce a permanent error, causing legitimate email to fail SPF evaluation.

For example, this is wrong:

example.com TXT "v=spf1 include:spf.workspace.example ~all"
example.com TXT "v=spf1 include:spf.transactional.example ~all"

Instead, consolidate the authorized senders into one SPF record, if both services truly send using the same domain:

v=spf1 include:spf.workspace.example include:spf.transactional.example ~all

Do not merge blindly. First identify every system that sends with your domain: employee mailbox provider, customer-support system, billing tool, CRM, marketing platform, website host, and transactional email provider. Removing an include can break a legitimate mail stream; adding one indiscriminately can authorize a sender you no longer use.

Respect SPF's DNS lookup limit

SPF is not an unlimited list. Mechanisms such as include, a, mx, exists, and redirect can trigger DNS lookups, and the standard limit is ten DNS-triggering terms during evaluation. A record may look short while the services it includes lead to many nested lookups.

This matters most when a domain has accumulated years of SaaS tools. A single root-domain SPF record containing six includes can already be risky if some included providers themselves include other domains. If SPF gets too complex, audit unused senders, move separate mail streams to aligned subdomains when appropriate, or use a carefully managed SPF-flattening approach.

A custom return-path domain can also have its own SPF record. That SPF record is separate from the SPF record at your visible From-domain root. Do not assume that a record for bounce.example.com replaces the SPF record for example.com, or the other way around.

Add DKIM records exactly as generated

DKIM, or DomainKeys Identified Mail, signs an outgoing message cryptographically. The sending service adds a signature to each message, and the recipient retrieves the corresponding public key or delegation record through DNS.

A DKIM hostname contains a selector, which lets a domain publish more than one DKIM key and rotate keys without disrupting all senders. A typical hostname looks like this:

s1._domainkey.example.com

Here, s1 is the selector. Your provider may issue selectors such as v1, mail, resend, k1, a random-looking string, or multiple selectors. The selector is not interchangeable: copy it exactly.

DKIM as a CNAME record

Many transactional email platforms use CNAME-based DKIM delegation. The provider gives you a host such as:

s1._domainkey

and a target such as:

s1.example-domainkey.provider-mail.net

In Cloudflare, create the record as:

If the provider gives two or three DKIM CNAME records, add every one. Multiple selectors are common and may support signing-key rotation, regional infrastructure, or distinct message streams.

DKIM as a TXT record

Some providers give a DKIM TXT record rather than a CNAME. Its content can be long and commonly begins like this:

v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFA...

For that form, choose TXT, put the provider's selector host in Name, and paste the full value into Content. Do not insert manual line breaks into the key. Cloudflare can store a long TXT value correctly; the UI may display it in wrapped form after saving, but that display wrapping is not necessarily a DNS error.

Why DNS-only is essential for DKIM CNAME records

Cloudflare's proxy is designed for web traffic. DKIM validation depends on public DNS resolving the CNAME chain to the provider's DKIM endpoint. A DKIM CNAME should therefore be set to DNS only (the gray-cloud state), not proxied.

This is an easy mistake when a zone uses Cloudflare for website acceleration. The orange cloud can be useful for web hostnames such as www, but it is not appropriate for mail-authentication CNAMEs. If Cloudflare presents a proxy toggle for your DKIM CNAME, leave it off.

Add DMARC with a monitoring policy first

DMARC, or Domain-based Message Authentication, Reporting, and Conformance, connects your visible From domain to SPF and DKIM results. It lets you tell receiving servers how to handle mail that claims to come from your domain but fails authentication and alignment checks.

The DMARC record always lives at the _dmarc hostname for the domain it covers. For example.com, the fully qualified DNS name is:

_dmarc.example.com

In Cloudflare, the Name field is normally just:

_dmarc

A safe starting record is:

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

Create it as follows:

The rua tag requests aggregate reports. These reports are XML files, often compressed, sent by mailbox providers that choose to participate. Use a dedicated mailbox or a DMARC-report processing service rather than a person's primary inbox. Raw aggregate reports are valuable, but they are not designed to be pleasant to read manually at scale.

Understand the policy values

The three widely used DMARC policies are:

• p=none: Monitor authentication results without asking receivers to quarantine or reject failures.
• p=quarantine: Ask receivers to treat failing messages suspiciously, often by placing them in spam or quarantine.
• p=reject: Ask receivers to reject messages that fail DMARC.

Start at p=none unless you have already inventoried every legitimate sender and confirmed its authentication behavior. Moving immediately to p=reject can block legitimate invoices, support messages, password resets, internal application notices, or employee mail if an overlooked service is not aligned.

After monitoring reports and fixing legitimate failures, a cautious rollout can look like this:

1. Publish p=none and collect reports long enough to cover normal business cycles.
2. Fix unexpected sources, missing DKIM records, and misaligned return-path domains.
3. Move to p=quarantine; pct=25 if the traffic is understood.
4. Increase pct gradually as results remain clean.
5. Move to p=reject when you are confident that legitimate sources pass DMARC.

DMARC is about more than an SPF pass or a DKIM pass in isolation. To pass DMARC, a message needs at least one passing authentication method that is aligned with the domain shown in the visible From address. That is why correctly configuring DKIM and a custom return-path matters for deliverability as well as anti-spoofing.

Configure the return-path or custom MAIL FROM domain

The return-path is the address used for envelope-level mail handling, including bounces. It is also called the envelope sender, MAIL FROM domain, bounce domain, or return-path domain depending on the provider and interface.

It is different from the visible From address recipients see in their inbox. A message might show:

From: Acme <receipts@example.com>
Return-Path: bounces@bounce.example.com

A custom return-path lets your email infrastructure use a subdomain you control, such as bounce.example.com, instead of a shared provider-owned envelope domain. Under relaxed DMARC alignment, an organizationally aligned subdomain can help SPF contribute to DMARC authentication. DKIM should still be configured because it is resilient to forwarding scenarios that can break SPF.

Common return-path record patterns

Your provider will generally use one of these patterns.

Pattern 1: One CNAME delegation record

Pattern 2: MX plus SPF TXT on a bounce subdomain

Pattern 3: CNAME plus verification TXT record

Some systems use a CNAME to route the return-path subdomain and an additional TXT record to prove control of the sending domain. Add both records if they are listed in the provider setup screen.

Do not create a return-path record at the root (@) unless that is explicitly what your provider gives you. Most providers use a dedicated subdomain because it separates bounce processing from your primary web, mailbox, and corporate email configuration.

The Cloudflare mistake that breaks CNAME records

The most common Cloudflare-specific configuration mistake is entering a fully qualified hostname into the Name field when Cloudflare is already appending your zone name.

Suppose your domain is example.com and the provider tells you to create this DKIM record:

s1._domainkey.example.com

In Cloudflare, enter this in Name:

s1._domainkey

Do not enter:

s1._domainkey.example.com

If the dashboard appends the root domain, the incorrect input can become:

s1._domainkey.example.com.example.com

That record may save successfully, but the provider will never find the expected DKIM hostname. The same rule applies to _dmarc, return-path labels such as bounce, and verification hostnames.

Name fields and target fields behave differently

For email CNAME records, the left-hand name and the right-hand target are not treated the same way:

• In the Name field, use the short relative label when Cloudflare displays your zone as the suffix. Examples: _dmarc, s1._domainkey, or bounce.
• In the Target field, paste the provider's destination hostname exactly as supplied. That target is often outside your domain, so it should not be shortened.

For example:

Name:   s1._domainkey
Target: s1.domainkey.provider-mail.net

Do not turn the target into s1.domainkey.provider-mail.net.example.com. If a provider supplies a target ending with a trailing dot, Cloudflare may normalize it in the interface. The important part is that the saved DNS record resolves to the provider-specified destination.

Other Cloudflare DNS mistakes to avoid

Beyond duplicate-domain CNAME names, several errors recur during email-domain setup.

Proxying a mail CNAME

Any DKIM or return-path CNAME that Cloudflare allows you to proxy should normally stay DNS only. Authentication and mail-routing records need standard DNS resolution, not HTTP proxying.

Replacing rather than merging SPF

A provider may tell you to add an SPF include. That does not necessarily mean delete your existing root-domain SPF record. If Google Workspace, Microsoft 365, a support desk, or a CRM also sends using the root domain, removing their authorization can cause their messages to fail SPF.

Inspect the existing SPF record first. If one already exists, merge the new mechanism into the one valid policy only after confirming the provider's instructions and your complete sender inventory.

Publishing an SPF record at the wrong hostname

The SPF record for example.com belongs at the root domain. The SPF record for bounce.example.com belongs at bounce. They are different DNS names with different purposes.

A common failure is copying a return-path SPF value into the root record or putting the root-domain policy on the bounce subdomain. Match the host shown in your provider's record table exactly.

Editing a legacy DKIM key instead of adding the new selector

Do not overwrite an existing DKIM record merely because both records contain _domainkey. Selectors distinguish keys and senders. For example, google._domainkey, s1._domainkey, and mail._domainkey can coexist.

If your provider gives s1._domainkey, add or edit that exact name. Do not replace google._domainkey unless you intend to break an existing Google Workspace DKIM configuration.

Adding extra spaces, quotes, or line breaks

TXT values are sensitive to syntax. Copy values exactly, especially DKIM public keys and DMARC tags. Avoid adding smart quotes, a period after ~all, whitespace in the middle of a p= tag, or a pasted line break inside a key.

Cloudflare may visually quote or wrap TXT strings after saving. That is usually display formatting. Verify the resolved DNS value before assuming the record was malformed.

Verify the records before sending production traffic

DNS changes often appear quickly with Cloudflare DNS, but resolver caches and provider verification jobs can take longer. Give records time to propagate, then verify the exact hostnames and values.

Use three levels of validation.

1. Check the Cloudflare record list

In DNS > Records, confirm each entry has the expected type and name. Look closely for accidental doubled domains such as:

bounce.example.com.example.com

Also confirm that DKIM and return-path CNAME records are DNS only.

2. Query public DNS

Use a DNS lookup tool or command-line resolver to inspect what the public internet sees. Typical commands include:

dig TXT example.com +short
dig TXT _dmarc.example.com +short
dig CNAME s1._domainkey.example.com +short
dig CNAME bounce.example.com +short

For a provider that uses MX on the bounce subdomain, query that as well:

dig MX bounce.example.com +short
dig TXT bounce.example.com +short

You are checking the public answer, not merely the record you intended to save. If the output is empty, resolves to the wrong hostname, or shows the duplicated root domain, correct the Cloudflare record before attempting verification again.

3. Complete provider verification and send a test

Once public DNS returns the correct values, return to the sending-domain setup screen and use its verification or refresh action, if available. Then send a message to a mailbox you control and inspect the message headers.

Look for results similar to:

spf=pass
dkim=pass
dmarc=pass

The header format varies by mailbox provider. The essential result is that the message passes DKIM and DMARC, while SPF either passes with an aligned custom return-path or is understood as non-aligned by design. A DMARC pass can come from aligned DKIM even when forwarding or routing affects SPF.

Before sending a large campaign or moving an application to production, also validate recipient addresses. A free email address verification tool can help catch malformed, disposable, or risky addresses before they create unnecessary bounces.

A practical rollout checklist

Use this checklist when setting up a new sending domain in Cloudflare:

1. Confirm Cloudflare is authoritative for the domain's DNS.
2. Open the correct zone's DNS > Records page.
3. Review existing TXT records before adding SPF.
4. Maintain one SPF policy per hostname that begins with v=spf1.
5. Add every provider-issued DKIM selector, using the supplied type and value.
6. Keep DKIM and return-path CNAME records set to DNS only.
7. Add a DMARC TXT record at _dmarc, starting with p=none unless you have already completed enforcement planning.
8. Add the provider-issued return-path CNAME, or the required MX and SPF records, on the exact supplied subdomain.
9. Verify public DNS responses, not only dashboard entries.
10. Send test messages and inspect SPF, DKIM, and DMARC results before increasing traffic.

Treat DNS setup as configuration management, not a one-time checkbox. Whenever a team adds a new sender, changes mailbox providers, migrates transactional email infrastructure, or retires a SaaS platform, review SPF, DKIM, and DMARC again.

When to use a subdomain for transactional email

You can send transactional email from the root domain, such as notifications@example.com, or from a subdomain, such as notifications@mail.example.com. The right choice depends on brand requirements, existing mail systems, and how much separation you want between different types of email.

A dedicated sending subdomain can simplify operations. For example, you can publish SPF, DKIM, and DMARC specifically for mail.example.com without changing the root domain's policy for employee mail. It can also make reputation analysis clearer when transactional, marketing, and corporate mail are managed by different systems.

However, a subdomain is not a substitute for correct configuration. If your visible From address uses mail.example.com, the corresponding DKIM domain and DMARC policy must still be correctly aligned. Decide your From-domain strategy before publishing records so that the DNS layout matches the mail you will actually send.

FAQ

Where do I find DNS records for a Cloudflare-registered domain?

Open the Cloudflare dashboard, select the domain's zone, then go to DNS > Records. If the domain is registered with Cloudflare but DNS is delegated elsewhere, make the changes at the authoritative DNS provider instead.

Should I enter the full domain in Cloudflare's Name field?

Usually no. For a zone named example.com, enter relative host labels such as _dmarc, bounce, or s1._domainkey. Cloudflare appends the zone domain. Entering the full hostname can accidentally create example.com.example.com.

Can I have more than one SPF record?

You can have multiple TXT records at a hostname, but only one valid SPF policy beginning with v=spf1. Combine authorized senders into one SPF record and keep its DNS lookup count within SPF's limit.

Why is my DKIM record a CNAME instead of a TXT record?

Many email providers use CNAME delegation so they can manage DKIM keys and rotation on their own infrastructure. Add the CNAME exactly as supplied and set it to DNS only in Cloudflare.

Do I need DMARC if SPF and DKIM already pass?

Yes. SPF and DKIM authenticate pieces of a message; DMARC applies domain alignment and publishes your handling policy for failures. Start with p=none to monitor, then move toward quarantine or reject after confirming all legitimate senders are authenticated.