What Is DMARC, and Do You Need It to Send Marketing Email?

DMARC is a short instruction you publish in your domain's DNS telling receiving mail servers what to do with a message that claims to come from your domain but fails authentication: let it through, put it in spam, or refuse it outright. It also asks those servers to report back on who is sending as you. If you send marketing email from your own domain, you need one — increasingly, bulk mail without it is filtered before anyone sees it.

The name stands for Domain-based Message Authentication, Reporting and Conformance, which is why everyone uses the acronym. It is worth ten minutes of understanding rather than a copied-and-pasted DNS record, because the wrong setting can silently stop your own mail from arriving, and the right one is the difference between "we sent a campaign" and "a campaign was delivered."

What DMARC actually does

DMARC sits on top of two older checks and makes them mean something.

SPF (Sender Policy Framework) is a list, published in your DNS, of the servers allowed to send mail for your domain. A receiving server compares the sending server against that list. It answers: did this come from a machine we authorised?

DKIM (DomainKeys Identified Mail) attaches a cryptographic signature to each message, generated with a private key held by the sender and verified against a public key in your DNS. It answers: was this signed by someone holding our key, and did it arrive unmodified?

Either check can pass while the message still looks like it came from someone else, because the address a human sees — the visible From address — is not necessarily the domain being checked. That gap is what DMARC closes with alignment: it requires that the domain which passed SPF or DKIM matches the domain in the From address your recipient actually reads.

So the sequence at the receiving end is: run SPF, run DKIM, check whether either one passed and aligned with the visible From domain, then look up your DMARC record to see what you asked them to do if neither did. One published line decides the outcome.

What p=none, p=quarantine and p=reject mean

The p= value is the policy — your instruction to every receiving server in the world.

• p=none — take no special action, just send me reports. This is monitoring mode. Nothing changes for your mail; you simply start seeing who sends as your domain.
• p=quarantine — treat failing mail as suspicious, which in practice usually means the spam folder.
• p=reject — refuse failing mail outright. It never reaches the recipient and the sender gets a bounce.

The reason p=none exists is that almost every organisation discovers legitimate senders it had forgotten: the invoicing system, the helpdesk, the CRM, a form on the website, a colleague's mail-merge tool. Publishing p=reject before you have found all of them is how a business blocks its own invoices. The standard sequence is monitor, fix what fails, then tighten — and tightening is the point. A p=none record left in place forever protects nobody; it only watches.

SPF, DKIM and DMARC: what's the difference?

This is where most confusion sits, so plainly:

• SPF authorises servers.
• DKIM authenticates messages.
• DMARC ties either result to the address the reader sees, and states the consequence when neither holds.

You do not choose between them. DMARC is meaningless without at least one of the other two, and having both gives you redundancy — useful because SPF breaks when mail is forwarded (the forwarding server is not on your list), while a DKIM signature usually survives the trip. That single fact is why "SPF is set up, so we're fine" is not a finish line.

What DMARC does not do

Knowing the boundaries prevents expensive misunderstandings:

• It is not encryption. It says nothing about whether the message was private in transit, only about whether the sender was who they claimed.
• It does not stop spam arriving in your inbox. It governs mail claiming to be from your domain, sent to anyone.
• It does not protect lookalike domains. Someone registering a domain one character different from yours is not affected by your DMARC record at all, because they are authenticating their own domain honestly. That is a separate problem with separate defences.
• It does not guarantee the inbox. Authentication is a prerequisite, not a promise. Once you pass, placement still depends on your sending reputation, complaint rate, list hygiene and content.
• It does not fix a bought list. Nothing does.

Treat DMARC as the gate you must pass to be considered. The rest of deliverability decides what happens after.

Do I need DMARC if my email platform sends for me?

Yes, and this is the part that catches small businesses. When you send through a marketing platform, its servers do the sending. If you use the platform's default configuration, the message may be signed with the platform's domain rather than yours — the authentication passes, but it does not align with your From address, so DMARC still fails, and some clients display an unflattering "via" note next to your name.

The fix is the platform's own-domain authentication setup: you add DNS records it provides, usually a couple of CNAME entries, so that mail sent on your behalf is signed as your domain. Established platforms all offer this in some form. What varies is which plan it is available on, how clearly the instructions are written, and how much visibility you get when something fails.

What this means when you compare email platforms

Turn the above into criteria, in this order of importance:

1. Own-domain authentication on the tier you will actually buy. Not "supported" in the marketing copy — available on your plan. This is the criterion that decides whether your mail can pass DMARC at all, which is why it ranks first.
2. Clarity of the DNS setup. You are pasting records into a domain registrar, possibly once, possibly never again. Copy-paste values and a verification button beat a support article.
3. Visibility into failures. Does the platform tell you when authentication breaks, or do you find out from a customer? Deliverability problems are much cheaper to fix on the day they start.
4. Handling of subdomains and multiple senders. If transactional mail, invoices and campaigns leave from different systems, they all need to align with the same policy.
5. What happens to your domain when you leave. Authentication records tie your domain to a vendor's infrastructure; removing them is easy, but rebuilding sending reputation elsewhere is not. That is a switching cost worth pricing before you commit, in the sense described in the subscription value guide.

The rest of the platform decision — automation depth, list growth, pricing shape — is covered in the email marketing platform buyer's guide, and the general method for weighting criteria like these is in how to compare software.

How to check what you have right now

Three checks, none of which require buying anything:

• Look for the record. A DMARC record lives at the hostname _dmarc.yourdomain.com as a TXT entry beginning v=DMARC1. If nothing is published, you have no policy.
• Read the headers of a message you sent. Most mail clients can show original headers; the Authentication-Results line states plainly whether SPF, DKIM and DMARC passed.
• Turn on reporting and actually read it. The rua= address in your record receives aggregate reports as XML files. They are ugly but readable, and they show every source sending as your domain — which is frequently the moment a business discovers a system it forgot it owned.

FAQ

Do I need DMARC if I only send a few hundred emails a month?

Yes, and small senders benefit most. A small list means every message matters, and authentication is a one-time setup rather than an ongoing cost. Volume thresholds decide when providers enforce, not when you should bother.

Will publishing DMARC block my own email?

Only at p=quarantine or p=reject, and only for senders that fail authentication. That is exactly why you start at p=none, read reports until every legitimate source is accounted for, then tighten.

Do I need both SPF and DKIM, or is one enough?

DMARC passes if either one passes with alignment, so one is technically enough. Configure both anyway: SPF commonly breaks when mail is forwarded, and DKIM is what keeps you passing when it does.

Are DMARC reports readable without a tool?

The aggregate reports are XML, so they are legible with effort and tedious at volume. Reading a few by hand teaches you what your sending actually looks like; a report-processing service is a convenience purchase, not a requirement.

Does passing DMARC mean my campaigns will reach the inbox?

No. It means they will be considered rather than discarded at the door. Placement after that comes down to reputation, engagement and list quality — which is why authentication is the first deliverability criterion and never the only one.

Set the policy, read the reports, then tighten it. When you are ready to choose the platform that will send on your domain's behalf, see the criteria-scored comparison of email marketing tools at Top Fully.