DMARC Check: The Complete Email Authentication Guide

The email nobody in the company sent is the one that does the damage. It carries your domain in the From line, your logo, your finance manager’s name and signature, and it asks a customer to update the bank details on an invoice.

By the time anyone works out what happened, the money has moved and the customer is on the phone asking why you did this to them. It is the most reported category of crime the Internet Crime Complaint Center takes in, and business email compromise on its own accounts for billions of dollars in reported losses every year.

DMARC exists to make that email impossible. It is the layer that ties SPF and DKIM to the address a human actually sees, and it is the only one that lets you tell the receiving server to throw a forgery away.

Running a DMARC check is how you find out whether any of that is switched on. For most domains the honest answer is more embarrassing than they expect: a record exists, it parses cleanly, and it is stopping nothing at all.

What a DMARC check actually does

A DMARC check is a diagnostic pass over one domain’s email authentication. It looks up the DMARC record, confirms the syntax is valid, reads the policy, and works out whether SPF and DKIM are lined up behind it.

DMARC stands for Domain-based Message Authentication, Reporting and Conformance, which is a mouthful for a fairly small idea: publish a rule about who may send mail as you, and ask the world’s receiving servers to enforce it.

The reason it matters is that SPF and DKIM on their own do not protect the address your recipient reads. SPF checks the invisible envelope sender, the return path a bounce would go to. DKIM checks a cryptographic signature attached to the message.

Neither of them says anything about the visible From header, which is the only part a human looks at. A forger can pass SPF cleanly using a domain they genuinely control while writing your name in the From line. DMARC is the piece that closes that gap, by requiring the authenticated domain to align with the visible one.

That last cell is worth sitting with. DMARC protects your exact domain, nothing else. Someone registering a domain one character off yours will pass their own authentication without breaking a sweat, which is why a clean DMARC check is a foundation rather than a finish line.

What it does buy you is real: nobody can wear your actual name, and every receiving server on the internet starts mailing you a daily account of who tried.

Inside a DMARC record

A DMARC record is a single DNS TXT record published at the _dmarc subdomain, so _dmarc.example.com for example.com. It is one line of semicolon separated tags, and it has to start with v=DMARC1.

Everything after that is either a policy instruction, an alignment setting, or an address to send reports to. Publish two of these by accident and receivers discard both, which is a surprisingly common way to end up with no protection while believing you have some.

The p tag, and how enforcement actually happens

The p tag is the whole point of the record. It tells a receiving server what to do with a message that claims to be from your domain and fails authentication, and it takes one of three values.

• p=none monitors and does nothing else. Failing mail is delivered as usual; you simply start receiving reports. Useful as a listening period, dangerous as a destination.
• p=quarantine tells receivers to treat failing mail as suspicious, which in practice means the spam folder.
• p=reject tells receivers to refuse the message at the door. This is the only setting that actually stops someone sending as you.

The three values map to a rollout rather than a menu. You start at none to find out who is really sending on your behalf, and the answer is almost always longer than the list anyone can recite from memory: the help desk, the payroll system, the marketing platform, an events tool somebody signed up for two reorganizations ago.

You fix or authorize each one, then climb. The mistake is not starting at none. The mistake is still being there a year later.

The specification underneath all of this was revised, which is worth knowing if you learned DMARC a few years ago. The original document, RFC 7489, was informational rather than a standard. The current version, RFC 9989, obsoletes it and puts DMARC on the IETF standards track for the first time.

Two practical changes come with it. The pct tag, which used to apply a policy to a percentage of mail, is gone. And a new np tag covers subdomains that do not exist: set np=reject and you close off the invented subdomains attackers like, without touching anything that legitimately sends.

Alignment mode, and why relaxed is the safer default

Alignment is the rule that decides how closely the authenticated domain has to match the visible From address. The adkim tag governs DKIM alignment and aspf governs SPF, and each takes r for relaxed or s for strict.

Relaxed is the default and the safer choice: mail signed by news.example.com still aligns with a From address at example.com. Strict demands an exact match, which is both more secure and much easier to break, because one provider signing with their own subdomain is enough to fail your own newsletter. Confirm what your senders actually sign with using a DMARC tool before you tighten either one.

One detail catches people out constantly. DMARC passes if either SPF or DKIM passes and aligns, not both. That sounds generous until you remember what forwarding does.

A mailing list or a forwarding rule rewrites the envelope sender, so SPF fails at the far end while the DKIM signature survives untouched. Domains that rely on SPF alone tend to discover this the week they move to reject, when their own forwarded mail starts bouncing. Sign everything with DKIM and that failure mode disappears.

Aggregate and forensic reports, and which one you will actually read

Reporting is where DMARC pays for itself, and it comes in two kinds. The rua tag sets the address for aggregate reports: gzipped XML files that receiving providers send once a day summarising every message they saw claiming your domain, grouped by sending IP with pass and fail counts.

The ruf tag requests forensic reports on individual failures, which sounds better and delivers less: most large providers do not send them at all, for privacy reasons. An empty forensic mailbox is not evidence that nothing is failing.

Run a DMARC check yourself

You can pay for a dashboard that does all of this, and if you are managing more than a handful of domains you probably should.

But the check itself is four DNS lookups and one file you unzip, and doing it by hand once is the fastest way to understand what the dashboards are actually telling you.

Step 1: look up the record and check that it parses

Query the TXT record at _dmarc.yourdomain.com. A hosted checker such as EasyDMARC, dmarcian, MXToolbox or DMARC Inspector will do the lookup and validate the syntax in one pass, flagging missing semicolons, unknown tags and values that do not belong.

What you want back is exactly one record, starting with v=DMARC1, carrying a p value and an rua address.

Three results should stop you. No record at all means no protection and no visibility, and it is still the most common outcome across the wider internet. Two records means receivers ignore both, so a domain that looks protected is not. And a record that parses cleanly but reads p=none with no rua is the emptiest kind of pass: it satisfies a compliance checkbox and defends nothing.

Step 2: validate SPF and DKIM, then count your DNS lookups

DMARC is a verdict on two other protocols, so checking it without checking them is checking nothing. For SPF, look up the TXT record on the domain itself and confirm that every sending mail server you rely on is covered by an include or an IP range, and that the record ends in -all or ~all rather than trailing off.

Then count the lookups. SPF allows a maximum of ten DNS queries while evaluating a record, a limit written into the SPF specification (RFC 7208) to stop the protocol being used to amplify traffic.

The include, a, mx, ptr and exists mechanisms and the redirect modifier all count against it; ip4, ip6 and all do not. Go over ten and receivers return a permanent error, SPF stops passing, and any domain leaning on SPF alone starts failing DMARC.

It is the most common self-inflicted wound in this whole area, and it arrives quietly, on the day someone adds a fourth vendor to the record.

For DKIM you need the selector, the label your provider puts in front of ._domainkey. Providers publish theirs, but the reliable way to find it is to open any message you have already sent and read the s= value out of the DKIM-Signature header.

Then confirm the signing domain in d= is one that aligns with your From address, because a signature that validates against the wrong domain passes DKIM and fails DMARC.

Step 3: simulate the stricter policy before you enforce it

Before moving to quarantine or reject, simulate. Most checkers have a record testing mode that shows how a receiving server would treat your current traffic under a stricter policy, and it is a cheap way to catch the sender nobody remembered.

The gap between a record that validates and a record that is safe to enforce is entirely made of forgotten senders: the ticketing system, the invoicing tool, the conference platform that mails attendees on your behalf.

Step 4: keep reading the reports after the record goes live

A DMARC check is not a one time task, because the thing it measures keeps changing. Every new marketing tool, every migration, every vendor with an email feature moves the ground under your record.

Aggregate reports are how you notice, and they arrive daily whether or not anyone opens them. Read them yourself while the volume is small and route them into a parser when it is not, the same way you would feed any other operational signal into a SIEM you have already chosen.

Common DMARC errors and their fixes

Most failed DMARC checks are not exotic. They cluster into five shapes, and each has a fix that takes minutes once you know which one you are looking at.

Missing record, or syntax the parser will not accept

The symptom is no record at _dmarc.yourdomain.com, or one that will not parse: a missing semicolon, a tag that does not exist, a stray quote from a DNS panel that helpfully added its own.

The fix is to publish a minimal valid record and build up from there. v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com is a complete, legal record and a perfectly good starting point. Re-run the checker after the change and give DNS a few minutes to propagate before you conclude anything.

Policy tag mistakes, and enforcement that stalled at none

The symptom is a record that has sat at p=none since the day it was published, often because moving it felt risky and nothing forced the issue. Sometimes it is worse: a policy set to reject in a hurry, with a legitimate sender still failing, which is how a company ends up bouncing its own invoices.

The fix in both directions is the same, move in steps and let the reports decide when. Sit at none until the aggregate data is clean, move to quarantine, watch for a week, then reject.

If you inherited a domain already at reject with failures in the reports, drop back to quarantine while you fix the sender rather than leaving real mail on the floor.

Alignment conflicts, when SPF and DKIM pass but DMARC fails

The symptom is legitimate mail failing DMARC while both SPF and DKIM report a pass, which reads as nonsense until you check alignment. It usually means adkim=s or aspf=s is set while a provider signs or sends with a subdomain of their own.

The fix is to relax the mode back to r, or to reconfigure that provider to sign with your exact domain, which most business-tier email platforms support. Tighten to strict only once you have confirmed every sender can meet it.

Reporting address errors, and the mailbox that stays empty

The symptom is a valid looking record and an empty reporting mailbox. Sometimes the address in rua is simply wrong or unmonitored. More often the address sits on a different domain and the external authorization record described earlier was never published.

Check the address resolves, check the mailbox can absorb a daily flow of gzipped XML without a size limit rejecting it, and check the cross domain record if the report address is not on the domain you are protecting.

Subdomains, and the senders nobody remembered

The symptom is a parent domain that passes cleanly while mail from subdomains fails, or an attacker happily sending from a subdomain that was never created.

The fix has two halves. Set an explicit sp value for real subdomains and np=reject for ones that do not exist. Then audit the sender list properly and make sure SPF and DKIM cover every legitimate Email Service Providers and internal system that sends on your behalf, including the ones nobody thinks of as email: monitoring alerts, CI notifications, the ticketing system.

Compliance, deliverability, and upkeep

A DMARC check earns its place when it becomes routine rather than a project. The record is a live piece of infrastructure, and it decays the same way any other configuration decays, quietly, in the direction of whatever someone added last.

Why compliance stopped being optional for bulk senders

The mailbox providers settled this argument on everyone’s behalf. Google’s sender guidelines require bulk senders to authenticate with SPF, DKIM and DMARC, hold spam complaints below 0.30%, and offer one-click unsubscribe. Microsoft published a comparable bar for high-volume senders reaching Outlook.com, Hotmail and Live addresses, where non-compliant mail is filtered to Junk first and refused later.

Beyond the inbox, insurers, enterprise procurement teams and regulated sector auditors have started asking for evidence of email authentication directly, and a screenshot of a passing DMARC check is the cheapest evidence you will ever produce.

Finance, healthcare and education feel this first, because the consequences of a convincing forgery in those sectors are measured in regulatory exposure rather than embarrassment.

Deliverability, reputation, and the logo beside your name

There is a commercial argument here that is easy to lose behind the security one. Authenticated mail from a domain with a consistent sending reputation gets treated better by filters than mail from a domain that anyone can imitate.

Moving from none to quarantine to reject narrows the set of servers allowed to speak in your name, and that narrowing is what a reputation is built on. It is also the prerequisite for the newer trust signals: brand indicators in the inbox, the little logo beside your name, generally require an enforcing DMARC policy before a provider will display anything at all.

Spotting an attack in the aggregate reports

Aggregate reports are a threat feed that nobody has to sell you. A block of failures from an IP range in a country you do not operate in is somebody testing your domain. A sudden spike from a single host is usually a campaign in progress.

Neither shows up anywhere else, because the mail never touched your own servers; it was sent by someone else, in your name, and the only reason you can see it at all is that receivers are telling you. Domains without an rua address never find out any of this.

Keeping the record healthy after the rollout

Treat the record like any other production configuration. Re-run the check on a schedule, monthly is plenty for a stable domain. Re-run it immediately after anything that touches sending: a new marketing platform, a mail provider migration, a subdomain spun up for a campaign, an acquisition that brings someone else’s DNS with it.

Keep the SPF lookup count somewhere you can see it, because that is the number that creeps. And keep one person accountable for the reporting mailbox, since a report nobody reads is the same as no report.

None of this is difficult. It is just easy to leave half done, and a half done DMARC record is the one that produces a compliance tick and a spoofed invoice in the same week.

The check takes ten minutes. The thing it prevents takes considerably longer to explain to a customer.