How to Check Your DMARC Record

Before we talk about DMARC at all, you need a clear picture of the problem it was invented to solve. Email is one of the oldest things on the internet — older than the web itself — and it was built in a much more trusting era. The original specification, written in 1982, lets anyone type whatever they want in the "From:" line of an email. There is no automatic check that the sender is who they claim to be. None. If you have a mail server (or a script, or a free trial of a marketing tool), you can send a message that says "From: ceo@yourbank.com" and it will arrive in someone's inbox looking exactly like a real one.

This is called email spoofing, and it is the foundation of every phishing attack you have ever heard about. The fake password-reset link, the fraudulent invoice from your CFO, the urgent-looking gift card request — they all start with someone forging the From: address of a brand or a coworker the victim already trusts. Mailbox providers like Google, Microsoft, Yahoo, and Apple have spent more than two decades trying to solve this problem on the receiving end, and they have gotten very good at filtering obvious garbage. But the only way to truly stop spoofing is for the sender — the real owner of the domain — to publish a public set of rules that says "here is who is allowed to send email as me, and here is what you should do if you see anything else."

Those rules live in three rulebooks, all stored as text records in your DNS (Domain Name System):

• SPF (Sender Policy Framework) — a guest list of which servers are allowed to send email on behalf of your domain.

• DKIM (DomainKeys Identified Mail) — a digital signature that proves a message really came from you and was not tampered with in transit.

• DMARC — the policy on top of SPF and DKIM that tells receiving mail servers what to do when one of those checks fails. Reject the message? Send it to spam? Just record it for later analysis?

The three work together. SPF and DKIM produce the inputs ("did this message pass authentication or not?"); DMARC consumes those inputs and applies your policy. DMARC by itself does nothing. It is the rulebook that tells mailbox providers how to act on the data SPF and DKIM are already producing. That distinction is the single biggest source of confusion for people setting it up for the first time, so file it away.

One more bit of context that has become impossible to ignore: in February 2024, Gmail and Yahoo started requiring a DMARC record on any domain sending more than 5,000 emails per day. Microsoft Outlook followed a few months later. If you send any meaningful volume of email — newsletters, transactional receipts, customer support replies — DMARC has gone from "nice to have" to "do this or your email will not arrive." That is the world the rest of this guide lives in.

DMARC (Domain-based Message Authentication, Reporting and Conformance) is a small set of instructions you publish in your domain's DNS (Domain Name System) records. Those instructions tell every receiving mail server in the world: "hey, when you get an email claiming to be from my domain, here's how to check whether it's really from me — and here's what to do if it isn't." That's it. The rest of this guide is just unpacking that one sentence.

DMARC stands for Domain-based Message Authentication, Reporting and Conformance. Each word does a job:

Domain-based — the rules are tied to your domain name (like example.com), not to individual mailboxes.

Authentication — DMARC checks whether an email really came from your domain by piggybacking on SPF and DKIM. SPF asks "is this server allowed to send for example.com?" and DKIM asks "was the message digitally signed by example.com?"

Reporting — when you set DMARC up, mail providers like Google and Microsoft will send you reports listing every server in the world that tried to send email as your domain, and whether the messages passed authentication. This is incredibly useful for catching impostors.

Conformance — you tell the world what to do when a message fails the checks. The choices are: do nothing (just monitor), put it in spam, or block it entirely.

It's worth noting that since February 2024, Gmail and Yahoo have required a DMARC record for any domain sending more than 5,000 emails per day. Microsoft Outlook quickly followed. If you send any meaningful volume of email, DMARC has gone from "nice to have" to "or your email won't reach anyone."

Let's skip the marketing fluff and answer the only question that actually matters: why should you, a real human with a real to-do list, care about DMARC? Here's the plain-English version, written the way you'd hear it from a friend who happens to do this for a living.

The first reason is selfish: your real emails will reach more inboxes. Mail providers like Gmail, Microsoft 365, and Yahoo treat a properly configured DMARC record as one of the strongest possible signals that you are a legitimate sender. They use it to decide whether to put your monthly newsletter in the inbox, in the Promotions tab, or in the spam folder where nobody will ever read it. Without DMARC you are guessing; with DMARC you are playing by the rules everyone in the room expects.

The second reason is protective: scammers cannot impersonate you as easily. Without DMARC, anyone can send a phishing email that says "From: ceo@yourcompany.com" and there is nothing technically stopping it. With DMARC at `p=reject`, mailbox providers will refuse to deliver the impostor. Your customers, your employees, your investors, and your partners are protected from someone wearing your brand.

Picture this in real life. A founder of a 30-person startup notices that one of her customers responded to a phishing email pretending to be from her. The scammer asked for an updated invoice payment to a different bank account. The customer almost wired the money. After the scare, the founder spends a Saturday setting up DMARC for the first time. Six months later her CFO mentions in passing that the phishing complaints have dropped to almost zero — and that their cold-outreach reply rate has actually gone up because Gmail is now putting their messages in the inbox instead of Promotions. One Saturday's work, two compounding wins.

Three questions this tool answers in plain English. If any of these have ever crossed your mind, DMARC is built for you:

• Will the emails I send actually reach the inbox, or are they going to spam?

• Can someone else send phishing emails pretending to be my domain?

• Have I set up the three rulebooks (SPF, DKIM, DMARC) that mailbox providers now require?

You can either run the check yourself with the free EdgeDNS DMARC checker, or ask your AI assistant — connected through MCP (Model Context Protocol) — to ask the question for you and translate the answer into something you can paste into Slack.

Who gets the most out of this guide. Small-business owners worried about deliverability, marketing managers onboarding a new email service, IT admins prepping for a security audit, founders who just got their first customer-facing phishing complaint, and brand teams trying to protect against impersonation. If you see yourself in that list, this is one of the standards you should fully understand and have in place by the end of the week.

What happens if you skip this entirely. Your real emails risk landing in the spam folder, scammers find it easier to impersonate your brand, your security audit will flag a missing control, and — if you send more than 5,000 emails per day — Gmail and Yahoo will start refusing your bulk mail outright. That is why running this check, even once a month, is one of the cheapest forms of insurance you can give your domain.

If you're still on the fence about whether DMARC belongs in your toolbox, this section is for you. Below you'll meet three real people facing three real situations where setting up DMARC turns a stressful afternoon into a five-minute task. Read whichever story sounds closest to your week.

Story 1: The small-business owner whose newsletter stopped landing

Imagine you're a founder with a Shopify store and a monthly newsletter that goes out to about 12,000 customers. Last month's newsletter had a 22% open rate. This month's open rate is 4%. Customer support is getting messages saying "I never see your emails anymore." You log into Mailchimp and the bounce rate looks fine — Mailchimp says delivery is 99%. But Mailchimp can only see whether the message was accepted by the receiving server. It cannot see whether the message ended up in the inbox or in spam. The thing that quietly changed last month was Gmail's bulk-sender requirements going into effect on February 1, 2024. Without DMARC, Gmail is now dropping your newsletter into Promotions or spam by default. Setting up DMARC at `p=none` with a reporting address — about thirty minutes of work — gives you the data feed to confirm the diagnosis, and moving to `p=quarantine` over the next two weeks restores your inbox placement.

Why it matters: This is the single most common deliverability issue of 2024 and 2025. Senders who set up DMARC see inbox placement rates jump within 48 hours.

Story 2: The marketing manager onboarding HubSpot

Imagine you're a marketing manager at a 200-person SaaS company. Your team just bought HubSpot and is about to migrate the entire email program over from a legacy tool. The HubSpot onboarding doc has a checklist that includes "add HubSpot to your SPF record" and "add the DKIM CNAMEs HubSpot provides." Easy enough. But three weeks after the migration, the sales team reports that HubSpot sequence open rates are mysteriously low. You run a check on your DMARC record and discover it was set up six years ago by a former IT admin at `p=reject`, with a strict alignment policy that does not match how HubSpot signs messages. Every HubSpot email is being authenticated by SPF and DKIM but failing DMARC alignment, so Gmail is sending the lot to spam. The fix is a one-line change to add HubSpot's DKIM domain to the alignment policy, but you would not have known to look for it without the DMARC reports.

Why it matters: Almost every CRM and email-sending service migration silently breaks DMARC alignment in some subtle way. The reports tell you exactly which one and exactly how to fix it.

Story 3: The IT admin in a SOC 2 audit

Imagine you're the one IT person at a 50-person fintech. The company is going through its first SOC 2 Type 1 audit, and the auditor's questionnaire has a question that reads, in full: "Describe the email authentication controls in place across all customer-facing domains." You have eight domains. You vaguely remember setting up SPF on the main one a couple of years ago. You have no idea about DKIM or DMARC on any of them. You spend an hour running the EdgeDNS DMARC checker against each domain, then ask your AI assistant: "Run a complete email security audit on all eight of these domains and give me the results in a table I can paste into the audit response." Twenty minutes later you have a full report, including which domains need fixes, what the fixes are, and the language to put in the audit response.

Why it matters: Compliance and security audits are exactly the kind of work where a 20-minute AI conversation replaces a 4-hour spreadsheet exercise. The output is cleaner, the methodology is documented, and you can re-run the check the next quarter without starting from scratch.

Common situations across teams. Beyond the three stories above, here are the everyday workplace moments when people across the company reach for DMARC. If any of these are on your calendar this month, that's your sign:

• When setting up email on a brand-new domain.

• After signing up for a new email-sending service (Mailchimp, SendGrid, HubSpot, Klaviyo, etc.).

• When a customer reports that your emails are landing in their spam folder.

• Before a security audit, a SOC 2 review, or a major marketing campaign.

Still not sure? Open Claude, ChatGPT, Gemini, or any other AI assistant connected to the EdgeDNS MCP server and ask, in your own words: "Is DMARC something I should set up for my domain?" The assistant will look at your domain, ask you a couple of follow-up questions about how you send email, and give you a straight answer in plain English.

There are three ways to check if you have DMARC, from easiest to nerdiest:

Easiest (recommended for everyone): use the free EdgeDNS DMARC checker. You type in your domain, it tells you in plain language whether you have DMARC, what your current policy is, and what you should fix.

Easier still (if you're using AI): if you've connected the EdgeDNS MCP (Model Context Protocol) server to Claude, ChatGPT, or Gemini, you can just ask: "Check if example.com has a DMARC record set up correctly and explain anything that looks wrong." The AI will run the check, read the result, and explain it conversationally.

Nerdy way (if you like the command line): every DMARC record lives at a special subdomain called `_dmarc`. So you can ask DNS directly:

When you read a real DMARC record, it looks like a mess of letters and equal signs. Here's what you're looking at, one tag at a time:

v=DMARC1 — the version. There's only one version, so this is always the same. It just has to be there.

p= — the policy. This is the most important tag. It tells receiving servers what to do with messages that fail authentication. Your three choices are: - `p=none` — just watch and report. Don't actually block anything. - `p=quarantine` — mark failing messages as suspicious. They usually end up in the spam folder. - `p=reject` — refuse failing messages entirely. They never reach the recipient.

sp= — the subdomain policy. If you only set `p=`, your subdomains inherit the same rule. Sometimes you want different rules for them — that's what `sp=` is for.

rua=mailto:address — where to send the daily summary reports. These reports list every server that tried to send email as your domain in the last 24 hours. You really want this set up — it's how you find out who's really sending your email.

ruf=mailto:address — where to send detailed reports about individual failing messages. Useful for forensics, but not all providers send these.

adkim= and aspf= — "alignment mode" for DKIM and SPF. The default (`r` for relaxed) is almost always what you want. The strict mode (`s`) is for advanced cases.

pct=1-100 — what percentage of failing messages the policy applies to. Useful for rolling out changes gradually. Default is 100.

After helping thousands of people set up DMARC, these are the issues that come up over and over again:

1. You have two DMARC records. You're only allowed one. If somehow you ended up with two TXT records at `_dmarc.yourdomain.com`, neither one works — you get a permanent error and DMARC quietly stops working. Fix: log into your DNS provider, find the duplicates, and delete all but the one you actually want.

2. Your policy is `p=none` and you forgot about it. Monitoring mode is great for two weeks, terrible forever. With `p=none`, scammers can still successfully impersonate you. Fix: once you've confirmed all your real senders pass authentication, move to `p=quarantine`, then `p=reject`.

3. You have no `rua=` reporting address. Without reports, you have no idea who's sending email as your domain — including legitimate services you forgot about, like Mailchimp from three years ago. Fix: add `rua=mailto:dmarc-reports@yourdomain.com` (or use a hosted DMARC reporting service that aggregates the XML reports for you).

4. Alignment failures. Sometimes a service like a CRM sends an email that passes SPF and DKIM checks, but DMARC still rejects it because the authenticated domain doesn't match the visible "From" address. This is called an alignment failure. Fix: contact the service and ask them to set up custom DKIM signing with your domain.

5. Subdomain spoofing. Even with `p=reject`, an attacker can sometimes still spoof `mail.yourcompany.com` if you didn't also set `sp=reject`. Fix: add the `sp=` tag, or publish individual DMARC records for important subdomains.

Here's the safe rollout schedule we recommend. The whole thing takes about two months, and at no point are you risking your real email.

Weeks 1–2: Just watch. Publish a DMARC record with `p=none` and your reporting address. This affects nothing — it just turns on the data feed.

Weeks 3–4: Read the reports. You'll get daily XML reports from Google, Microsoft, Yahoo, and others. These tell you every server that sent email claiming to be from you, and whether each one passed or failed authentication. Make a list of every legitimate sender (your marketing tool, your CRM, your transactional email service) and confirm each one passes both SPF and DKIM.

Weeks 5–6: Quarantine, slowly. Switch to `p=quarantine; pct=10`. This tells receiving servers to put 10% of failing messages in spam. Watch the reports for any legitimate email you accidentally hit. If everything looks fine, raise the percentage to 25, then 50, then 100 over a couple of weeks.

Week 7+: Reject. Once 100% quarantine is stable, switch to `p=reject; sp=reject`. Now scammers can't impersonate you at all.

Here's what each phase looks like as an actual record:

DMARC is not a set-it-and-forget-it thing. Your email setup will change — someone will sign up for a new newsletter platform, marketing will adopt a new tool, you'll acquire another company. Each of those introduces a new sender that needs to be authorized.

The easiest way to stay on top of it is to subscribe your domain to monitoring. EdgeDNS will watch your DMARC record and your overall email security score and alert you if either one changes or drops.

Or — if you've connected the EdgeDNS MCP server to your AI assistant — you can just ask Claude or ChatGPT once a month: "Run a full email security check on example.com and tell me what changed since last month." The AI will run all the relevant tools and give you a friendly summary.

DMARC (Domain-based Message Authentication, Reporting and Conformance) — the email rulebook this whole guide is about.

SPF (Sender Policy Framework) — a list, published in DNS, of which servers are allowed to send email as your domain.

DKIM (DomainKeys Identified Mail) — a digital signature added to every message you send so receivers can verify it really came from you.

DNS (Domain Name System) — the internet's address book. DMARC, SPF, and DKIM are all stored as DNS records.

MCP (Model Context Protocol) — the open standard that lets AI assistants like Claude, ChatGPT, and Gemini call EdgeDNS tools directly.

TXT record — a type of DNS entry that holds plain text. DMARC, SPF, and DKIM all live in TXT records.

Phishing — fake emails that try to trick people into clicking malicious links or handing over passwords. DMARC's main job is to make these much harder.