How to Set Up SPF, DKIM and DMARC Records in Cloudflare Without Breaking Email Delivery

To set up SPF, DKIM and DMARC in Cloudflare without disrupting legitimate email, first inventory every system that sends mail for your domain, preserve existing MX records, publish one correctly merged SPF policy per sending hostname, enable your providers' DKIM signatures, and start DMARC in monitoring mode before moving to enforcement. Never replace existing DNS records with a generic template without checking how the domain is used.

Whether a Nigerian business sends invoices from Microsoft 365, staff mail from Google Workspace, newsletters through a mailing platform or password-reset messages from its website, the DNS records need to match all authorised sending paths. Cloudflare's email DNS guidance explains how authentication records protect against spoofing; Google's sender requirements explain why authentication problems can also lead to delivery trouble.

This is a practical 2026 setup and rollback guide, with illustrative example.com DNS records. Do not copy provider selectors, IP addresses or report destinations without replacing them with values from your own accounts. Information verified on 2 November 2026 against Cloudflare, Google, Microsoft and IETF documentation.

What SPF, DKIM and DMARC do—and what they do not

DMARC does not require both SPF and DKIM to pass for each message: one successful aligned mechanism can be enough. SPF can pass for a provider's bounce domain while failing to align with From: sales@example.com; an aligned DKIM signature may still allow DMARC to pass. The distinction is described in the DMARC specification and Microsoft's troubleshooting guidance .

Authentication reduces domain impersonation; it cannot guarantee inbox placement, stop every lookalike-domain scam or solve poor sender reputation. Content, consent, infrastructure, complaints and recipient policies remain relevant.

Step 1: Audit all mail flows before editing Cloudflare DNS

Export or record your current Cloudflare DNS entries, including TXT, MX and CNAME records, and note their values and TTLs. Create a sender inventory: staff mailbox provider, website contact forms, application notifications, ecommerce receipts, payment alerts, helpdesk systems, payroll software, newsletters and any outbound SMTP relay.

For each service, note the visible From: domain, the envelope or return-path domain, whether it signs DKIM and which DNS values the provider requires. Ask who owns each integration; an overlooked payroll or password-reset service is a common reason delivery breaks after an overly strict rollout. Keep a small record of baseline delivery results and current DMARC policy.

Safety rule: leave incoming MX records unchanged while setting up sender authentication. MX records determine where mail arrives. Replacing them just to add SPF or DKIM can stop receiving email. If Cloudflare Email Routing is enabled, check whether it manages your MX and authentication records before making changes. Cloudflare's troubleshooting guide flags conflicting Email Routing and external-mail-provider MX configurations.

Step 2: Add or repair a single SPF TXT record

In Cloudflare, select the correct zone, open DNS → Records, find existing TXT entries starting v=spf1, and edit the existing SPF policy rather than blindly creating another. At a given hostname, multiple separate SPF records cause a permanent SPF error; unrelated TXT records for site verification can coexist.

For an illustrative domain using only standard Microsoft 365 email, Microsoft's documented SPF value is:

Type: TXT
Name: @
Content: v=spf1 include:spf.protection.outlook.com -all
TTL: Auto

This is a provider-specific example, not the universal record for every domain. Google Workspace uses a different sending-authorisation include. If both providers and other mail services genuinely send with the same envelope domain, combine all relevant provider mechanisms into one SPF policy at that hostname, according to each provider's current instructions. The final ~all means an unauthorised source receives SPF softfail, while -all means SPF fail; neither choice by itself substitutes for DMARC policy planning.

The SPF standard, RFC 7208 , limits the number of DNS-querying mechanisms and modifiers—such as nested include, a, mx, exists and redirect—to 10 during evaluation. Exceeding the limit returns permerror. Do not count just the visible include statements; nested includes also matter. Direct ip4 and ip6 mechanisms do not consume that lookup budget. Audit old includes and use a tested provider-supported strategy instead of casual IP flattening that can become stale.

Step 3: Configure DKIM using the values from your mail provider

DKIM setup has two parts: your provider signs outgoing mail using a private key, and DNS exposes the corresponding public key or provider-managed key alias. The common TXT name pattern is selector._domainkey.example.com. Some providers supply a long v=DKIM1; k=rsa; p=... public-key TXT value. Others, notably Microsoft 365, supply two selector CNAME records.

For Microsoft 365, go to the provider's email authentication or DKIM settings, obtain the exact selector1._domainkey and selector2._domainkey targets, and add them as CNAMEs in Cloudflare. Use DNS only (grey cloud), not Proxied (orange cloud). Microsoft warns that targets are tenant-specific and include dynamically assigned components; constructing one from an old example can break verification. Enable signing in the provider dashboard after DNS resolves and retain both selectors for key rotation. Microsoft's Cloudflare-specific DKIM instructions explain the sequence.

For Google Workspace and other providers, generate or retrieve the signing record in the provider admin console; choose a 2048-bit key when supported and recommended, publish it exactly as instructed and enable signing. Do not copy another company's public key. Record DKIM selectors for every separate marketing or transactional sending platform. Two different selectors can legitimately coexist; a CNAME must not conflict with another record at the exact same hostname.

Step 4: Publish DMARC at _dmarc and begin with monitoring

Create a TXT record in DNS → Records with name _dmarc. A conservative initial example is:

Type: TXT
Name: _dmarc
Content: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com
TTL: Auto

Here example.com is a reserved illustrative domain. For your deployment, replace the report address with an actual monitored mailbox or correctly authorised external reporting service. An unconfigured report inbox means the monitoring plan will not work. Do not create a second independent DMARC policy at the same hostname; edit the existing one. Cloudflare also offers DMARC Management , which helps inspect sending sources and aggregate reports where supported.

p=none asks receivers not to change delivery handling because of that DMARC policy, while still allowing reporting. Receivers retain their own anti-spam controls. After identifying and fixing legitimate sources, progress carefully to p=quarantine and ultimately p=reject. A receiving server may treat a policy request according to its own capabilities. RFC 7489 describes these mechanisms and optional pct sampling for controlled rollout.

Step 5: Verify DNS and actual email authentication

From a terminal with dig, replace example.com with your domain:

dig +short MX example.com
dig +short TXT example.com
dig +short TXT _dmarc.example.com
dig +short TXT selector1._domainkey.example.com
dig +short CNAME selector1._domainkey.example.com

The selector name and query type depend on your provider. You should see one SPF policy at each relevant sending hostname, the intended DMARC record, and the exact DKIM public key or alias. A TXT lookup for a CNAME-backed selector may follow the chain depending on the resolver, so inspect the CNAME directly if necessary. Cloudflare DNS changes can spread quickly but caches can retain old records until their TTLs expire.

Then send real test messages from each approved service to test Gmail and Microsoft mailboxes. Inspect message headers, particularly Authentication-Results, spf=, dkim=, dmarc=, the DKIM d= domain and the visible From domain. In Gmail, “Show original” can display authentication results. Test replies, mailing-list paths and any forwarding workflows separately.

The ideal result is authenticated and aligned mail from every legitimate source. If SPF passes but DMARC fails, check the envelope domain versus From domain and DKIM alignment. Microsoft provides a practical authentication troubleshooting matrix for these cases.

Step 6: Keep mail DNS-only in Cloudflare

Cloudflare's HTTP proxy is designed for web traffic, not ordinary SMTP mail. MX and TXT are never orange-cloud proxied, but A, AAAA and CNAME records can be. If mail.example.com is the hostname your MX record points to or your mail client connects to, its A/AAAA record should be DNS only. Provider-managed DKIM CNAMEs should also be DNS only.

Do not unproxy an unrelated website record unnecessarily; use a separate DNS-only mail hostname where possible. Cloudflare documents the difference in its email proxy use cases . Cloudflare does not proxy SMTP port 25 by default without separately configured Spectrum functionality. Changing a live mail hostname to Proxied can interrupt delivery even if SPF, DKIM and DMARC themselves are correct.

Cloudflare Email Routing is a distinct feature from having DNS hosted at Cloudflare. If it forwards mail for your domain, it can add managed MX, SPF and DKIM records. Review its configuration and merge SPF appropriately if another service also sends from the relevant domain. Cloudflare's routing documentation includes an illustrative merged policy and warns about SPF lookup limits.

Sample Cloudflare DNS record checklist

These are configuration patterns, not a complete DNS zone file. Your provider may use different selectors, subdomains, envelope senders and mail gateways.

How to move safely from monitoring to quarantine and reject

A sensible rollout is to publish p=none, review DMARC aggregate reports over a representative mail cycle, verify every approved vendor, fix failures and then apply enforcement in measured stages. A business sending only daytime staff mail might need a shorter audit than one sending monthly invoices, renewal reminders and quarterly newsletters. Allow time to observe infrequent systems.

If reports consistently show healthy aligned DKIM or SPF for legitimate mail, test p=quarantine; use optional percentage controls where supported and correctly understood. Review complaints, bounce notices, support tickets and reports. Move towards p=reject only when unauthorised sources are distinguishable from authorised ones and the latter continue passing. This is a risk-based rollout recommendation, not a guaranteed timetable.

Gmail's sender guidelines require SPF or DKIM for ordinary senders, and SPF and DKIM plus DMARC for senders exceeding 5,000 messages per day to personal Gmail accounts. A DMARC policy of p=none meets its stated minimum policy requirement for those bulk senders, though compliant authentication, alignment and the applicable unsubscribe, TLS and spam-rate rules still matter. Stronger enforcement should follow successful validation, not precede it.

Common failures and what to fix first

Forwarders and mailing lists deserve special care: forwarding can change the connecting IP, breaking SPF; some systems modify signed content, breaking DKIM. Authenticated Received Chain (ARC) can help receivers assess authenticated mail through intermediaries, but it is not a universal bypass. Microsoft's ARC guidance explains the scenario.

Rollback plan if legitimate messages stop arriving

Before changes, export original DNS values. When you observe delivery failures: (1) identify the affected sender and exact bounce or authentication error; (2) restore mistakenly changed MX or DNS-only mail host records immediately; (3) where DMARC enforcement caused a confirmed legitimate-mail problem, temporarily revert the policy to p=none while fixing alignment; (4) correct missing SPF authorisations or DKIM signing using provider instructions; (5) retest and monitor.

Rollback does not mean disabling all protections indefinitely. Keep a change log, record the reason and date, and schedule a re-test of the repaired source. DNS caches and recipient policy choices may delay visible recovery. If mail is business-critical, coordinate changes with the email administrator and provider support before altering production records.

Before going live: ten-point safety checklist

1. Record the current DNS zone and verify which provider receives inbound mail.
2. List staff, website, CRM, newsletter and transactional senders.
3. Use exactly one SPF policy for each relevant sending hostname.
4. Audit all nested SPF DNS lookups and avoid exceeding ten.
5. Publish the correct provider-issued DKIM TXT or DNS-only CNAME selectors.
6. Enable actual DKIM signing in each provider, not just DNS records.
7. Keep MX and mail-server hostnames correct and outside the ordinary HTTP proxy.
8. Start DMARC in monitoring mode and verify the aggregate report destination.
9. Send real test emails from every legitimate system and inspect alignment.
10. Increase DMARC enforcement only after reports and delivery tests show the mail estate is healthy.

Frequently asked questions

Can I have two SPF records for Google Workspace and Microsoft 365?

Not at the same DNS hostname. Combine the authorised sending sources into one SPF TXT policy, after verifying the current provider instructions and the ten-lookup limit. A separate sending subdomain can have its own SPF record.

Does Cloudflare automatically create DKIM records?

Not for every external mail provider. Cloudflare Email Service or Email Routing can manage certain records, while Google Workspace, Microsoft 365 and third-party senders require their own provider-issued configurations.

Should DKIM CNAMEs be orange-cloud proxied?

No. Provider DKIM CNAMEs should be DNS only; otherwise DNS may not expose the required target.

Will p=reject guarantee that no forged email is delivered?

No. It requests rejection of mail failing DMARC and depends on receiver enforcement. Lookalike domains, compromised legitimate accounts and other phishing techniques require additional controls.

Why can SPF pass while DMARC fails?

SPF may authenticate a return-path domain that does not align with the visible From domain. An aligned DKIM signature can independently satisfy DMARC, but if neither aligned path passes, DMARC fails.

How long do Cloudflare DNS changes take?

Changes commonly appear quickly, but recursive DNS caches can retain previous answers until their TTLs expire. Confirm the current answers and allow for cache behaviour rather than assuming every receiving server sees the new policy immediately.

Conclusion

Reliable email authentication is a controlled change process, not three DNS strings to paste blindly. Inventory all authorised senders, retain incoming mail routing, publish one accurate SPF policy, enable provider-specific DKIM, begin DMARC monitoring and validate each mail flow before advancing enforcement. That approach helps protect your domain against spoofing while reducing the risk that genuine invoices, support replies and account notifications are rejected.