How to Use Claude to Diagnose and Fix SPF, DKIM and DMARC When Your Business Email Goes Missing

The short answer: When a helpdesk platform, invoicing tool or newsletter service sends mail as your domain without being authenticated and aligned, receiving servers may junk or reject it, and nobody inside your company sees an error. A DMARC aggregate report is the record of exactly who is sending as your domain and what passed. For DMARC report analysis with AI, paste that XML into Claude together with your current SPF and DMARC records and it can sort every sending source into "ours and passing", "ours and failing" and "not ours", then draft the DNS change list. Claude only sees what you paste, it can be wrong, and every record it proposes should be checked with a DNS lookup before you publish it.

Picture the office manager of an 80-person Hong Kong professional-services firm, who also looks after IT. The firm is on Microsoft 365 with Exchange Online, and its domain, which we will call example.com here, has been stable for years. Over the last quarter three things were added: a Zendesk helpdesk that replies as support@example.com, Xero invoices that go out under the finance team's names, and a Mailchimp newsletter run by the marketing coordinator.

Then the complaints start. A client says she never received the reply to her support ticket. Another says the invoice reminder is "in the spam folder, again". The helpdesk shows every message as sent, Xero shows the invoices as delivered, and Mailchimp shows a normal send. Nothing bounces, so nothing looks broken from the inside.

After the Microsoft 365 migration, a previous consultant published a DMARC record for example.com with a quarantine policy and a rua address that has been collecting daily XML reports in a shared mailbox ever since. Nobody has opened one, because they are unreadable in a text editor.

Why Legitimate Email Fails Authentication (and Why It Happens After You Add a New Sending Tool)

Receiving mail servers do not trust the From: address a message displays, because anyone can type anything there. They check whether the sending server is permitted to send for the domain, and whether the message carries a signature that proves it was not altered. A new tool that sends as your domain passes those checks only if somebody set it up to, and a vendor's default setup often authenticates the message as the vendor's domain rather than yours.

That default is the usual failure. The mail is real and the sender is yours, but to a receiver it looks the same as a stranger sending as example.com. If your DMARC policy tells receivers to quarantine or reject mail that fails, they do exactly that. The sender's dashboard says "sent" and the recipient never sees it.

SPF, DKIM and DMARC Alignment in Plain Terms

SPF says which servers may send. It is a DNS record listing the servers allowed to send for a domain, and it is checked against the envelope sender, also called the return-path or bounce address, not the From: address people see. It proves the sending server was permitted. It does not prove the content was untouched, and it often breaks when mail is forwarded.

DKIM says the message was signed. The sending system adds a cryptographic signature tied to a domain named in the d= tag, and the receiver checks it against a public key in that domain's DNS. It proves the message was not altered in transit, but the signing domain can be any domain the sender controls, including the vendor's own.

DMARC says the From: domain must match. A message passes DMARC if SPF or DKIM passes and the domain that passed aligns with the From: domain. A helpdesk that signs with d=vendor.com passes DKIM, but that domain is not yours, so it does not align and DMARC does not pass. DMARC also publishes your policy and the address that receives reports.

For the general primer on all three records in a Hong Kong context, see our guide to SPF, DKIM and DMARC for Hong Kong businesses.

Turning a DMARC Aggregate Report Into a Plain-English Diagnosis

An aggregate report is the receiver's daily tally of mail it saw claiming to be from your domain. It is machine-readable XML, first defined in RFC 7489 and, since the 2026 DMARC revision, in RFC 9990, which is why it sits unread.

What the XML Actually Contains

Each report names the organisation that sent it, such as a large mailbox provider, the date range it covers and the DMARC policy it saw published. Then comes one row per sending IP address: how many messages, what the receiver did with them, whether DKIM and SPF passed, and which domains those checks authenticated.

There are no message bodies and no subject lines. What you do get is sending IP addresses and your domain, which is operational data rather than correspondence, though you should still check how your own privacy policy treats IP addresses. Forensic reports, the separate ruf type, can contain parts of individual messages and are a different matter.

A Prompt That Groups Sources Into "Ours and Passing", "Ours and Failing" and "Not Ours"

In this workflow Claude does not query your live DNS or read your mailbox, so you supply everything. Paste the report XML or a spreadsheet export, plus your current SPF and DMARC TXT values, then ask: "These are DMARC aggregate reports for example.com and its current SPF and DMARC records. Group every sending IP into three lists: ours and passing DMARC, ours and failing DMARC, and not recognised. For each failing source, say whether SPF or DKIM failed, whether the passing domain was aligned with example.com, and the most likely fix. Mark anything you cannot tell from this data as unknown rather than guessing."

A Worked Example — A Helpdesk Platform Sending as Your Domain With No DKIM Key

1. Collect a week of reports and the two records. Pull the reports from the rua mailbox and look up the current TXT records for example.com and _dmarc.example.com with a tool such as nslookup -type=txt or Resolve-DnsName. Paste the values. Never paste registrar or DNS login details.

2. Run the grouping prompt. The synthetic result, using documentation-range IP addresses in place of real ones: 192.0.2.10 sent 1,140 messages, with aligned SPF and DKIM passing, which is Exchange Online and healthy. 198.51.100.61 sent 205 messages, with aligned DKIM passing, which is the Mailchimp newsletter, set up properly when marketing first sent.

3. Read the failing row. 198.51.100.24 sent 312 messages and failed DMARC. SPF passed, but for the vendor's bounce domain. DKIM passed, but with d=helpdesk-vendor.example.net. Both passed for a domain that is not example.com, so neither aligns, and the quarantine policy applied. This is the helpdesk, and it explains the missing replies.

4. Check the unknown source. 203.0.113.77 sent 38 messages and failed both checks. Claude marks it as unrecognised. Do not add it to SPF to make it pass. Ask who might send as the domain: a forgotten CRM, a copier's scan-to-email, or someone forging your domain. Decide that after you know.

5. Note what the report does not explain. The Xero invoice reminders do not appear as a failing source, so the "spam folder" complaint may have another cause, such as content, the recipient's own filtering, or a receiver that sends no reports.

6. Fix the helpdesk. Open the vendor's documentation for authenticating a custom sending domain. It will give you DKIM records, usually CNAMEs, and often a custom return-path or bounce domain, so SPF can align too. Publish them, confirm each with a lookup, then switch the verification on in the vendor's settings. Exchange Online is separate: its custom-domain DKIM is enabled in the Microsoft Defender portal by publishing two CNAME records, selector1 and selector2, so check Microsoft's current documentation for the exact path.

7. Re-run the prompt on the next reports. Reports usually arrive daily, so a change often shows up within a day or two, though receivers differ and nothing is guaranteed. The helpdesk source should move to "ours and passing". If it does not, paste the new row back and ask what is still misaligned.

Fixing It Without Breaking Everything Else

The 10-DNS-Lookup SPF Limit and How One More Vendor Silently Breaks the Record

RFC 7208 allows an SPF check at most 10 DNS lookups. Mechanisms that trigger lookups, namely include, a, mx, ptr, exists and redirect, count toward it, including lookups inside each included vendor's own record. ip4, ip6 and all do not. Go over 10 and receivers return a permanent error, which many treat as an SPF failure.

The Microsoft 365 include costs one lookup, but each vendor include costs at least one more, and some vendors nest further includes inside theirs, so a helpdesk and a newsletter service can add several between them. The record that worked yesterday can fail today with no visible change. Ask Claude to estimate the lookup count, but verify it with a dedicated SPF checker, because includes are nested and a language model can miscount.

Moving DMARC From p=none to Quarantine to Reject in Stages

Policy has three steps. p=none monitors only and acts on nothing. p=quarantine asks receivers to treat failures as suspect, usually the junk folder. Older guides phase it in with the pct tag, but the 2026 DMARC revision (RFC 9989) removed pct and added a t=y test flag, so check what your receivers and tools support before relying on either. p=reject asks them to refuse failures outright. Moving up is the goal, because only enforcement stops forged mail, but each step should follow clean reports.

At each step, watch whether any source you own is still failing, and whether the "not recognised" list is shrinking. Do not move to reject while a legitimate system fails alignment, because that is how invoices disappear permanently. In this example the firm is already at quarantine, so the first job is fixing the failing source, not tightening anything.

Claude-Assisted Diagnosis vs a Dedicated DMARC Monitoring Service vs Guessing at DNS

• Claude-assisted diagnosis. Good for a one-off investigation or a small number of reports: it turns the XML into a plain-language grouping and a change list in minutes, with no new subscription. It does not collect reports, does not see your live DNS, keeps no running history of your domain unless you paste the reports again, and can miscount SPF lookups. Correct use: a first diagnosis and an explainer for the person who owns the DNS.
• A dedicated DMARC monitoring service. Built for ongoing work: it receives the reports for you, merges many receivers into one dashboard, tracks sources over time and alerts you when something new starts sending. It is a recurring cost and still needs a person to decide what each source is. Correct use: a standing view once enforcement is on and the sender list keeps changing.
• Guessing at DNS. Fast, free and the way most outages in this area start: adding an include because a blog post said so, copying a record from another company, or jumping straight to reject. Correct use: none.

Getting This Right — Never Paste Registrar or DNS Credentials, and Who Owns the Records Next Year

Never give Claude credentials. It needs report XML and two TXT strings, nothing more. A registrar or DNS-host login, an API token or an admin password has no place in a chat. Make the DNS edit yourself, with a second person looking at it.

Verify before you publish. Claude can be confidently wrong about a vendor's record names, selector formats or lookup counts. Check every proposed record against the vendor's current documentation, then confirm what is live with a lookup after the change. Keep the old record in a note so you can revert in minutes.

Decide who owns the records next year. Authentication is never finished, because every new SaaS tool that sends as your domain adds a source, and the records drift. Name the person who reviews reports, who must be told before a team signs up for a new sending tool, and who holds DNS access when the office manager leaves. Admin accounts that can change DNS and mail settings also deserve MFA, because a compromised one lets an attacker publish records of their own.

Deciding how Claude should fit into your email diagnosis, and writing the prompts and review steps around it, is AI+ Support work. DMARC monitoring is included in every plan of our managed IT support, our managed email security service adds the defence against spoofed senders and impersonation that an enforced DMARC policy works alongside, and the hands-on DNS changes and mail-flow fixes are handled by our IT support team. For the other direction of the same problem, suspicious mail coming in, see flagging phishing emails with Claude; for more Claude work inside the same tenant, see Claude and Microsoft 365 email automation.

Frequently Asked Questions

Do Google and Microsoft now require DMARC for bulk senders?

For large senders, yes. Google and Yahoo's bulk-sender requirements began in February 2024; Google's threshold is 5,000 or more messages a day to personal Gmail accounts. They cover SPF, DKIM, a DMARC policy of at least p=none, alignment and one-click unsubscribe for marketing mail, and Google later moved to stricter enforcement including rejections. Microsoft applied similar rules to Outlook.com, Hotmail and Live for senders above that volume from May 2025. Check both companies' current pages for exact thresholds and dates. Many SMEs send below 5,000 a day, but authentication still affects where their mail lands.

Can I go straight to p=reject?

You can publish it, but it is risky without evidence. If any legitimate system, such as a helpdesk, an invoicing tool or a forgotten scanner, is not yet aligned, reject makes receivers discard its mail. Run at p=none or quarantine while reports show every source you own passing, and move to reject only after that has held for a while.

Do DMARC reports contain personal data?

Aggregate reports hold sending IP addresses, message counts, pass or fail results and your domain, with no message bodies or subject lines. That is largely operational data, but IP addresses can be personal data in some regimes, so treat them as you would other logs.

Why do emails still fail after I added the SPF include?

Usually because SPF was never the problem. DMARC passes if SPF or DKIM passes and aligns. An include only helps if the vendor's return-path domain is also yours, which often needs the vendor's custom bounce-domain setup. The other cause is exceeding the 10-lookup limit, which turns the whole record into an error, so recount after every addition.

How long does a DNS change take to show up in reports?

There is no fixed time. Receivers usually send aggregate reports daily, so a change often appears within a day or two, but they differ in schedule and some send none. Check the live record with a lookup straight away, then judge the result when new reports arrive.