Domains

Implementing DMARC

Publish a DMARC TXT record to protect your domain from spoofing, then graduate the policy from none to quarantine to reject.

DMARC builds trust in your domain and protects it from spoofing — forged mail sent in your name. It is published as a TXT record at _dmarc on your domain and tells receiving mail servers what to do with messages from you that fail authentication.

Prerequisites

DMARC sits on top of SPF and DKIM, so your mail must already pass them:

DKIM cryptographically proves the message was not altered in transit.
SPF authorizes the IP addresses allowed to send for your domain.

If you have a verified domain in MailBlastr, you are already passing SPF and DKIM — so you are ready to add DMARC.

What is DMARC?

DMARC (Domain-based Message Authentication, Reporting, and Conformance) instructs mailbox providers how to handle a message that fails SPF and DKIM, and gives you reports on who is sending in your name. A message achieves DMARC compliance if it passes *either* SPF *or* DKIM (it need not pass both); it fails DMARC only when both fail.

Step 1 — Publish a starter record

Begin with a permissive p=none policy so you can observe without affecting delivery:

TXT record

Namehostoptional

_dmarc.example.com

Typerecordoptional

TXT

Valuestringoptional

v=DMARC1; p=none; rua=mailto:dmarcreports@example.com;

The key tags in that value are:

v — the DMARC version (always DMARC1).
p — the policy applied to failing mail: none, quarantine, or reject. Start at none.
rua — the aggregate report address. Provide a real mailbox (it can live on another domain); reports arrive as an email with an attached .xml summarizing your sources and whether they passed SPF/DKIM.

Step 2 — Confirm delivery and passing

Send from every application and service that mails as your domain, confirm those messages land in the inbox, and inspect the headers for dmarc=pass. Spend a few days here so you catch sources that send on an irregular cadence.

Tools like Google Postmaster Tools surface SPF/DKIM feedback, and DMARC monitoring services aggregate your rua reports — both help you discover every service sending on your behalf before you tighten the policy.

Step 3 — Upgrade the policy

Once every legitimate source is passing, raise the policy. The three options:

Policy	Effect
`p=none;`	Deliver everything; monitor failures only.
`p=quarantine;`	Route messages that fail DMARC to the spam folder.
`p=reject;`	Bounce messages that fail DMARC outright.

Only move to quarantine or reject after you have confirmed all of your real mail passes — otherwise you risk junking or bouncing your own legitimate email.

A policy of p=quarantine; or p=reject; is also the prerequisite for BIMI, which can display your brand logo as the sender avatar.

Tag reference

Tag	Purpose	Example
`v`	Protocol version	`v=DMARC1`
`p`	Policy for the organizational domain	`p=quarantine`
`sp`	Policy for subdomains	`sp=reject`
`rua`	Aggregate report address	`rua=mailto:aggrep@example.com`
`ruf`	Forensic report address	`ruf=mailto:authfail@example.com`
`pct`	Percentage of mail subjected to filtering	`pct=20`
`adkim`	DKIM alignment mode	`adkim=s`
`aspf`	SPF alignment mode	`aspf=r`

Mailbox providers honor pct and ruf inconsistently, so do not rely on them — treat p, rua, and the alignment tags as the parts that actually take effect.