Docs: System guides

Read Cloudflare into Maplith

Cloudflare is where many companies keep their DNS. With a read-only token Maplith reads who sends mail as your domain and whether it passes, and checks every morning that your email domain is protected (SPF, DKIM, DMARC). It never reads a message and never changes a DNS record.

DNS · Also known as Cloudflare DNS, Cloudflare DMARC Management, DMARC, DMARC aggregate reports, SPF, DKIM, email domain health, email domain · Checked 2026-10-14

On this page

Best path

Recommended: Maplith’s own integration reads it. Maplith's own Cloudflare integration reads the DMARC summary with a read-only token, and checks your email domain every morning, under Data sources › Systems in every workspace; without Cloudflare, share an export of the summary.

Try the paths in this order:

Maplith’s own integration. Available in every workspace, under Data sources › Systems. See Maplith’s integration below.
Your agent fetches it, with the access you already gave it. No named connector is confirmed: check the tools your agent already has. The agent looks up the DMARC record of each domain (the TXT record at _dmarc of the domain) and, where you have a DMARC service, reads its summary: per sending organisation, how many messages passed and failed DMARC, SPF and DKIM over the last weeks. It only reads; it never changes a DNS record.
Maplith reads an MCP server you already run. No official MCP server confirmed. Cloudflare runs MCP servers for other parts of its platform; none of them is confirmed to serve DMARC reports. Maplith reads a server that serves MCP resources and takes a token a person types under Data sources › Systems, such as one your IT runs for a database.
Export files, the fallback that always works. See the export steps below.

Datasets that make a good map

Dataset	One row is	Key columns	Joins to
DMARC records	One domain's published DMARC policy: the policy (none, quarantine or reject), the subdomain policy, and where reports go.	domain, p, sp, rua	The sending sources by policy domain.
Sending sources	Per policy domain and sending organisation (the network owner of the sending address) and day: how many messages, and how many passed DMARC, SPF and DKIM.	domain, sending organisation, date, messages	The known senders by organisation; the DMARC record by domain.
Known senders	The services allowed to send as the domain (a mail provider, a newsletter or billing service) and the forwarders that pass mail on.	organisation, role	The sending sources by organisation.

Columns are named, never their values. Maplith tries to mask personal data such as email addresses, but that is best effort: you decide what goes in.

The access to give

Who usually has the rights: Whoever administers the domain's DNS account, such as a Cloudflare account administrator.

Choose the narrowest access that covers the data:

Zone: Zone Read
Account: Account Analytics Read
Zone: DMARC Management Read

Where to click:

In Cloudflare, open My Profile, then API Tokens, and click Create Token
Choose Create Custom Token and add the three permissions above, all read. Then turn DMARC Management on for the zone
Under Zone Resources, include only the zone of the domain
Create the token; it is used in the next step and is never pasted into a chat

A key or token made here stays in the tool that reads the system, never in a chat. Maplith asks for one only under Data sources › Systems in the app.

Export steps

Format: CSV from the DMARC service, or the XML aggregate reports themselves Date range: The last 4 weeks

In Cloudflare, open the zone, then Email, then DMARC Management, and export the sources for the last 4 weeks; or collect the aggregate report files the reporting address received
Keep per sending organisation and day the message counts and the DMARC, SPF and DKIM pass counts
Add the DMARC record of each domain as it is published
Upload the files under Data sources › Scans

How much data

About 100–3,000 rows a month (an estimate). Estimate for a small company with one or two domains, not a measured figure: one row per sending organisation per domain per day.

An agent that reads rows through a chat reads every one of them, about one token per four characters. Above a few thousand rows a dataset, or for a daily refresh, an MCP server or an export is the better path.

Maplith’s integration

Status: Available in every workspace, under Data sources › Systems.

How to connect

Create the read-only Cloudflare token for the domain's zone, as under “The access to give” above
In Maplith, open Data sources › Systems and connect Cloudflare with the token and the zone ID
Maplith reads one day of DMARC sources to check the token, and says which permission is missing if it cannot
List the services allowed to send as the domain; Maplith suggests them from what the first read finds

The permissions it asks for

Permission	Why
Zone: Zone Read	finds the zone of the domain the token is limited to
Account: Account Analytics Read	reads the aggregated DMARC counts through Cloudflare's analytics API
Zone: DMARC Management Read	reads the DMARC sources: per sending organisation, how many messages passed and failed

What it reads

Per policy domain, sending organisation and day: message counts and how many passed DMARC, SPF and DKIM
The live DMARC record of each domain, from public DNS
What reaches the map: the domains and their policy, the known senders, and the drift Maplith finds; counts, never a message

What it never reads or does

A message, a subject, an address or a sending IP address
Changing a DNS record: the token is read-only, and a stricter policy is a proposal a person makes
Zones other than the one the token is limited to

Choosing what is read: The token is limited to one zone, and the domains to check are listed with their policy ladder. A person changes the domains, the ladder and the known senders under Data sources › Systems.

What Maplith sets up once it is connected

Maplith sets these up itself. You correct them; you never have to approve them first. If the system is disconnected, the playbooks Maplith set up and nobody changed are taken out of use, and put back when it is connected again.

Signals it raises:

Mail authentication (DMARC) needs a look (checked on a schedule): mail from a sender fails DMARC, an unknown organisation sends as the domain, the next stricter policy is overdue, or the live record no longer matches the ladder
Something Maplith relies on stopped working (checked on a schedule): the daily read is refused: the token expired or a permission is missing

Checks:

Email domain check (daily): reads the last 14 days of DMARC sources and the live records, and compares them with the known senders and the policy ladder

Suggested playbooks:

Tighten DMARC to quarantine. Starts when the domain has had 14 clean days at p=none and the next rung is overdue.
Handle an unknown sender. Starts when an organisation not on the known-sender list sent mail as the domain.
Handle a DMARC drift signal. Starts when any “Mail authentication (DMARC) needs a look” signal is raised: read its cause, then follow the steps for that cause.

Schedules:

Weekly DMARC review (weekly, Monday 09:00): the policy ladder moves in weeks, and a weekly look catches a rung that is ready before it waits too long

Always

Read-only, and never a credential sent to Maplith through a chat.
The same recent period, a few months, from every system.
You decide what goes in.

Sources

Written from public documentation, last checked 2026-10-14:

← All system guides · Markdown version